During a recent upgrade of Terragrunt, I noticed the very useful addition of skip-able configuration updates that seem to be geared towards improving the security posture of state resources.
https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#remote_state
I'd like some clarification to the purpose of the root access policy added that can be skipped with skip_bucket_root_access.
From what I understand, and have discussed with AWS support, granting the root user of an account access to a bucket through an s3 policy does not alter the accessibility of the bucket to the root user. What it does do, however is grant open read permissions to all IAM principals within that account. Given that Terraform does consider remote state sensitive information, it might make more sense to have that data accessible on a least privilege basis. Please let me know if I'm misunderstanding this policy.
Furthermore, should these state configuration updates be yes-able prompts during normal TG operations? In CI we frequently use the --terragrunt-non-interactive flag to ensure that runs aren't blocked by user prompts. Running any command in the latest version of Terragrunt results in the CI attempting to make the policy update remotely, which it shouldn't have permission to do if the service user/role associated with that run is granted least privilege.
What might be preferred is to state a warning that the configurations aren't set, along with instructions on how to ignore the warnings int the remote_state configuration block or run an independent command (like terragrunt remote configure secure or something) to configure them as a standalone operation from an engineer.
During a recent upgrade of Terragrunt, I noticed the very useful addition of skip-able configuration updates that seem to be geared towards improving the security posture of state resources.
https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#remote_state
I'd like some clarification to the purpose of the root access policy added that can be skipped with
skip_bucket_root_access.From what I understand, and have discussed with AWS support, granting the root user of an account access to a bucket through an s3 policy does not alter the accessibility of the bucket to the root user. What it does do, however is grant open read permissions to all IAM principals within that account. Given that Terraform does consider remote state sensitive information, it might make more sense to have that data accessible on a least privilege basis. Please let me know if I'm misunderstanding this policy.
Furthermore, should these state configuration updates be
yes-able prompts during normal TG operations? In CI we frequently use the--terragrunt-non-interactiveflag to ensure that runs aren't blocked by user prompts. Running any command in the latest version of Terragrunt results in the CI attempting to make the policy update remotely, which it shouldn't have permission to do if the service user/role associated with that run is granted least privilege.What might be preferred is to state a warning that the configurations aren't set, along with instructions on how to ignore the warnings int the
remote_stateconfiguration block or run an independent command (liketerragrunt remote configure secureor something) to configure them as a standalone operation from an engineer.