_This issue was originally opened by @sanjay-varanasi as hashicorp/terraform#12222. It was migrated here as part of the provider split. The original body of the issue is below._
Version:
terraform -v
Terraform v0.8.7
Affects:
aws_elastic_beanstalk_environment
Terraform Elasticbeanstalk environment option that seems to trigger a re-apply:
In other words, I've only been seeing this behaviour after adding this option.
We have to add this because the default SSH sec_grp behaviour is to open 22 to the world (0.0.0.0/0)
setting {
namespace = "aws:autoscaling:launchconfiguration"
name = "SSHSourceRestriction"
value = "tcp, 22, 22, 10.0.0.0/16"
}
Expected Behaviour:
Detect and "apply" the SSH port change the first time the configuration is applied.
Make no changes on subsequent applies.
Actual Behaviour:
Change show with every "plan".
Change applied with every "apply".
"terraform plan" will keep outputting this on every plan:
```
setting.786963625.name: "" => "SSHSourceRestriction"
setting.786963625.namespace: "" => "aws:autoscaling:launchconfiguration"
setting.786963625.resource: "" => ""
setting.786963625.value: "" => "tcp, 22, 22, 10.0.0.0/16"
and "terraform apply" will always modify the Beanstalk env
setting.786963625.name: "" => "SSHSourceRestriction"
setting.786963625.namespace: "" => "aws:autoscaling:launchconfiguration"
setting.786963625.resource: "" => ""
setting.786963625.value: "" => "tcp, 22, 22, 10.0.0.0/16"
aws_elastic_beanstalk_environment.eb_env: Still modifying... (10s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (20s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (30s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (40s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (50s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (1m0s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (1m10s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (1m20s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (1m30s elapsed)
aws_elastic_beanstalk_environment.eb_env: Still modifying... (1m40s elapsed)
aws_elastic_beanstalk_environment.eb_env: Modifications complete
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
I can definitely see the option in tfstate:
"setting.3461474930.name": "SSHSourceRestriction",
"setting.3461474930.namespace": "aws:autoscaling:launchconfiguration",
"setting.3461474930.resource": "",
"setting.3461474930.value": "tcp,22,22,10.0.0.0/16",
.
.
.
"all_settings.3461474930.name": "SSHSourceRestriction",
"all_settings.3461474930.namespace": "aws:autoscaling:launchconfiguration",
"all_settings.3461474930.resource": "",
"all_settings.3461474930.value": "tcp,22,22,10.0.0.0/16",
```
Is this a bug or am I not doing this the right way? Let me know if you need specific information.
I think this may affect my stuff too
Any updates on this? This specifically happens when using a security group instead of a CIDR. The plan output always looks like this despite nothing actually changing:
setting.1224657411.name: "SSHSourceRestriction" => ""
setting.1224657411.namespace: "aws:autoscaling:launchconfiguration" => ""
setting.1224657411.resource: "" => ""
setting.1224657411.value: "tcp,22,22,null" => ""
setting.2392760962.name: "" => "SSHSourceRestriction"
setting.2392760962.namespace: "" => "aws:autoscaling:launchconfiguration"
setting.2392760962.resource: "" => ""
setting.2392760962.value: "" => "tcp,22,22,sg-1234abcd"
I am experiencing the same problem (changes always applied on every run), using security group id instead of CIDR.
Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.
If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!
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!
Most helpful comment
Any updates on this? This specifically happens when using a security group instead of a CIDR. The plan output always looks like this despite nothing actually changing: