terraform-provider-aws: aws_security_group_rule doesn't seem to support security groups from multiple aws accounts.
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
terraform --version
Terraform v0.6.15
Affected Resource(s)
Please list the resources as a list, for example:
- aws_security_group_rule
- aws_security_group
Terraform Configuration Files
resource "aws_security_group" "default" {
name = "default-group"
vpc_id = "${aws_vpc.vpc.id}"
}
resource "aws_security_group" "internal" {
name = "internal-access"
vpc_id = "${aws_vpc.vpc.id}"
}
resource "aws_security_group_rule" "port443" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
security_group_id = "${aws_security_group.internal.id}"
source_security_group_id = "${aws_security_group.default.id}"
}
resource "aws_security_group_rule" "peer_access" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
security_group_id = "${aws_security_group.internal.id}"
source_security_group_id = "123456789012/sg-12345678"
}
Expected Behavior
After running terraform apply, and it successfully ran, there should be no more infrastructure changes when running terraform plan
Actual Behavior
Running terraform plan keeps showing aws_security_group_rule.peer_access needs to be added.
output is:
-/+ module.network.aws_security_group_rule.peer_access
from_port: "443" => "443"
protocol: "tcp" => "tcp"
security_group_id: "sg-12345678" => "sg-12345678"
self: "false" => "0"
source_security_group_id: "sg-12345678" => "123456789012/sg-12345678" (forces new resource)
to_port: "443" => "443"
type: "ingress" => "ingress"
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applyterraform plan
Important 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.tfstate file, I see it stores it without the other aws account number and just the security group id.
"aws_security_group_rule.peer_access": {
"type": "aws_security_group_rule",
"depends_on": [
"aws_security_group.internal"
],
"primary": {
"id": "sgrule-261220255",
"attributes": {
"cidr_blocks.#": "0",
"from_port": "443",
"id": "sgrule-261220255",
"protocol": "tcp",
"security_group_id": "sg-12345678",
"self": "false",
"source_security_group_id": "sg-12345678",
"to_port": "443",
"type": "ingress"
},
"meta": {
"schema_version": "2"
}
}
},
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 24
- Comments: 18 (8 by maintainers)
Commits related to this issue
- Merge branch 'master' of github.com:terraform-providers/terraform-provider-aws into gh-159 — committed to ktham/terraform-provider-aws by ktham 4 years ago
- Merge pull request #11809 from ktham/gh-159 resource/aws_security_group_rule: Prevent sg rule recreation when source_security_group_id has accountId prefix — committed to hashicorp/terraform-provider-aws by anGie44 4 years ago
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. I think for some people this is not a problem because maybe their security group was created after the AWS changes how they created unique id of security group, so all of their security group have 19 characters unique id. But for us, we have lots of security group where security group id still use the old implementation (unique id with 11 characters). We actually consider use AWS console when we need to create the cross account security group, as if we are using terraform security_group_rule for cross account security group id, it will created and destroy the resource, and disrupt the connection.
Here is my code and plan to reproduce my testing scenario.
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
After running terraform apply, and it successfully ran, there should be no more infrastructure changes when running terraform plan
Actual Behavior
Running terraform plan keeps showing aws_security_group_rule.peer_access needs to be added. output is:
Steps to Reproduce
terraform applyterraform planActually 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!
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
aws_security_groupand the CLI.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: