aws_security_group_rule doesn't seem to support security groups from multiple aws accounts. #159
Comments
|
+1 Unlike the previous report I do actually see the AWS Acount number making it to the Terraform State: "aws_security_group_rule.sg_rule": {
"type": "aws_security_group_rule",
"depends_on": [
"aws_security_group.security_group"
],
"primary": {
"id": "sgrule-2562427353",
"attributes": {
"from_port": "8080",
"id": "sgrule-2562427353",
"protocol": "tcp",
"security_group_id": "sg-12345678",
"self": "false",
"source_security_group_id": "123456789012/sg-12345678",
"to_port": "8080",
"type": "ingress"
},
"meta": {
"schema_version": "2"
},
"tainted": false
},
"deposed": [ ],
"provider": ""
},Terraform State commands shows the same: terraform state show ...aws_security_group_rule.sg_rule
id = sgrule-2562427353
from_port = 8080
protocol = tcp
security_group_id = sg-12345678
self = false
source_security_group_id = 123456789012/sg-12345678
to_port = 8080
type = ingressBut Terraform Plan seems to think that the terraform plan
-/+ ....aws_security_group_rule.sg_rule (new resource required)
id: "sgrule-2562427353" => <computed>
from_port: "8080" => "8080"
protocol: "tcp" => "tcp"
security_group_id: "sg-12345678" => "sg-12345678"
self: "false" => "false"
source_security_group_id: "sg-12345678" => "123456789012/sg-12345678"
to_port: "8080" => "8080"
type: "ingress" => "ingress"I have validated that the created Security Group Rule is created properly with the AWS Account Number in the source field. |
|
I'm also seeing the same thing on v0.10.7. It's in the state file, just not able to be completed by Terraform. |
|
Seeing the same issue with terraform v0.11.2 and aws provider v1.6.0_x4 |
|
Hi folks, are these cross-account rules successfully created with correct permissions (and its just the diff that's the issue now) or can someone please provide any relevant error output? |
|
In my use case, it's VPC peering, everything is created fine but, the rules are recreated every subsequent apply even with no changes. Example resource config The state Running terraform apply: |
|
An actual problem that is generated by this behavior is that when a |
|
We are also having this problem. Every subsequent run of terraform recreates the security group rules which is disruptive and unnecessary. It looks like this should hopefully be a pretty easy fix since the necessary data to determine no actual change is requires is being returned by the AWS API call. It looks like perhaps this: Terraform version v0.11.3 |
|
From my testing I was able to reference another account's peered VPC security group just using the security group ID with no OwnerId - AWS did the right thing on the backend. This may be fixable with a documentation update indicating that, or if we want to be more explicit about it I would add a source_security_group_owner_id field so we're not dealing with adding/detecting delimiters like in resource "aws_security_group" "test" {
vpc_id = "vpc-03c3cdREDACTED"
name = "xaccount_test"
description = "xaccount test"
}
resource "aws_security_group_rule" "test" {
security_group_id = "${aws_security_group.test.id}"
type = "ingress"
source_security_group_id = "sg-02c3REDACTED"
protocol = -1
from_port = 0
to_port = 0
} |
|
This is still an open issue, I even raised this to aws support team but they are not covering this. It's strange that such a bug exists for 3 years and is being completely ignored. |
|
Same issue here, constantly re-creating: |
|
We are running into this as well, @devonbleak's workaround seems to work for us as well, although we would like to be able to specify the account ID if possible. |
|
@mwarkentin confused, which workaround? Not putting the owner ID is breaking for us. I'll give it another try 😅 |
|
Not putting owner ID works for me. It makes sense because sg IDs are globally unique right? So AWS would know which account owns that. So this is still open because terraform doesn't support (or update state at least) with the string as seen in the web console right? which looks like 123456/sg-abc123 whats funny is specifying an inline rule in the aws_security_group resource with the 123456/sg-abc123 does work and update state correctly. so aws_security_group already does support this |
|
From my testing, i found interesting fact, when referencing security group from another account where the security group id length is 19 characters (this is a new unique id convention for security group) is working fine, but when referencing the security group where the security group id is 11 characters (old implementation, which i assume only unique to an account) we need to specify the account id owner of that security group. Here is my code and plan to reproduce my testing scenario. Terraform VersionAffected Resource(s)
Terraform Configuration Filesresource "aws_security_group" "cross_account_rules" {
name = "cross_account_sg"
vpc_id = "vpc-1a2b3c4d"
description = "security group for testing cross account security group rule"
}
resource "aws_security_group_rule" "short_sg_id_rule" {
type = "ingress"
from_port = "443"
to_port = "443"
protocol = "tcp"
security_group_id = "${aws_security_group.cross_account_rules.id}"
source_security_group_id = "123456789876/sg-1a2b3c4d"
}
resource "aws_security_group_rule" "long_sg_id_rule" {
type = "ingress"
from_port = "443"
to_port = "443"
protocol = "tcp"
security_group_id = "${aws_security_group.cross_account_rules.id}"
source_security_group_id = "sg-1a2b3c4d5e6f7g8h"
}
Expected BehaviorAfter running terraform apply, and it successfully ran, there should be no more infrastructure changes when running terraform plan Actual BehaviorRunning terraform plan keeps showing aws_security_group_rule.peer_access needs to be added. ------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
-/+ aws_security_group_rule.short_sg_id_rule (new resource required)
id: "sgrule-4096904641" => <computed> (forces new resource)
from_port: "443" => "443"
protocol: "tcp" => "tcp"
security_group_id: "sg-h8g76f5e4d3c2b1a" => "sg-h8g76f5e4d3c2b1a"
self: "false" => "false"
source_security_group_id: "sg-1a2b3c4d" => "123456789876/sg-1a2b3c4d" (forces new resource)
to_port: "443" => "443"
type: "ingress" => "ingress"
Plan: 1 to add, 0 to change, 1 to destroy.
------------------------------------------------------------------------Steps to Reproduce
Actually we can create the new security group to replace the old security group to handle this issue, but i think this cost so much effort to do, we need to create new security group, ensure all rules from old security group exist on new security group, ensure all security group that reference old security group also reference to this new security group, attach new security group to ec2 instances, and detach old security group. |
|
Help, this is still present in the current release of the AWS provider! |
|
@bflad I can verify that Terraform successfully creates the cross-account rules, but the problem is that the rule keeps getting deleted and re-created on every subsequent apply, resulting in a slight downtime when this happens. The problem is that on state refresh, the account ID prefix is removed from tf state. I resolved the issue here if you can take a look at it: #11809 |
resource/aws_security_group_rule: Prevent sg rule recreation when source_security_group_id has accountId prefix
|
Note: The fix for this has been merged and will release with version |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
This issue was originally opened by @rayzorinc as hashicorp/terraform#6571. It was migrated here as part of the provider split. The original body of the issue is below.
Terraform Version
Affected Resource(s)
Please list the resources as a list, for example:
Terraform Configuration Files
Expected Behavior
After running
terraform apply, and it successfully ran, there should be no more infrastructure changes when runningterraform planActual Behavior
Running
terraform plankeeps showingaws_security_group_rule.peer_accessneeds to be added.output is:
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applyterraform planImportant Factoids
This errors only when we're trying to allow access from different aws accounts that are vpc peered to each other.
In the
terraform.tfstatefile, I see it stores it without the other aws account number and just the security group id.The text was updated successfully, but these errors were encountered: