Terragrunt: sops_decrypt_file function not using TERRAGRUNT_IAM_ROLE

Created on 10 Sep 2020  路  12Comments  路  Source: gruntwork-io/terragrunt

sops_decrypt_file function may be getting invoked without assuming the role defined in TERRAGRUNT_IAM_ROLE, as inferred from the following scenario:

Two AWS account, management, prod. AWS KMS keys in each account.

SOPS files per account

aws/mgmt/mgmt-secrets.yaml # values encrypted with mgmt KMS key, or data key off that CMK may be more accurate
aws/prod/prod-secrets.yaml # values encrypted with prod KMS key, or data key off that CMK.. 

ECS task running from management account, provided a task role which can assume the role assigned to TERRAGRUNT_IAM_ROLE

Container running something like

git clone blah
cd aws/prod/somedir
terragrunt plan

tl;dr

In this instance I would expect TERRAGRUNT_IAM_ROLE to be assumed so that the sops_decrypt_file function can use the KMS keys from the meta-data of the sops file in the relevant parent dir (aws/prod/prod-secrets.yaml). Maybe more accurate to refer to SOPS under the hood rather than the abstraction here, but hopefully you're getting the idea.

I can see this being argued the other way, I'm sure there is a valid use case. Perhaps, to play pedant, naming for TERRAGRUNT_IAM_ROLE v TERRAFORM_IAM_ROLE is not consistent with the above. Although I don't know whether there is other stuff within the terragrunt wrapper, before terraform invocation, which does use the assumed role.

Getting ahead of myself: I've had a quick scout around the source, but don't really have much go experience, shot in the dark

Adding this aws_helper.AssumeRoleAndUpdateEnvIfNecessary(targetTGOptions) or this assumeRoleIfNecessary

Probably too low level in the sops_decrypt function itself

https://github.com/gruntwork-io/terragrunt/blob/938cf8c1c288b1b14919e48cbfce7801a3778dcd/config/config_helpers.go#L526

Maybe prior to read config

https://github.com/gruntwork-io/terragrunt/blob/938cf8c1c288b1b14919e48cbfce7801a3778dcd/cli/cli_app.go#L282

bug help wanted

All 12 comments

You are correct. We are running SOPS and _not_ passing it the TERRAGRUNT_IAM_ROLE information in any way. A PR to fix this is welcome!

@bob-rohan We are doing the following to encrypt with SOPS using AWS KMS, for multiple AWS accounts say a Management and a Production like your case.

sops --kms "<KMS_ARN>+<ROLE_ARN>" -e -i secrets.yaml

So, instead of providing your role ARN on the TERRAGRUNT_IAM_ROLE, you could instead pass this Role ARN on your sops encrypt command.

The sops decrypt command doesn't require those ARNs, since they are provided in the SOPS encrypted file attributes.

I don't know if this helps you at all.

Yes, that's neater than my workaround. Thanks @Dragotic

Glad it helped you.

This problem bit us too. Tried the workaround from @Dragotic but didn't work for us because we use different role ARNs in CI vs. locally, so we can't encrypt it with a given role ARN and then decrypt it with a different one.

@jessebye I haven't tried this, but if I'm not mistaken you can encrypt it the regular way and then manually add in the SOPS encrypted yaml file, the role ARN that you want to decrypt it with.

sops:
       kms:
       -      arn: <ARN> should be already populated
               role: <ROLE_ARN> you manually add the role_arn which shouldn't exist
.
.
.

Should probably work.

@Dragotic our problem is we need to be able to decrypt with two roles. We use one locally and another in CI. Do you know if multiple roles are supported?

@Dragotic our problem is we need to be able to decrypt with two roles. We use one locally and another in CI. Do you know if multiple roles are supported?

Sorry, I don't have a lot of experience with SOPS.

No worries. I tested this out and found that I could use two roles, so problem solved!

No worries. I tested this out and found that I could use two roles, so problem solved!

That's awesome! Thanks for letting me know.

No worries. I tested this out and found that I could use two roles, so problem solved!

@jessebye How did you solve this problem? We have a similar issue. For local encrypt/decrypt we use one role and for CI decrypt we use another.

@ryan-dyer-sp we edited the files after SOPS encrypting them, duplicating an entry in the KMS block and adjusting it to the second role. Like so:

kms:
    -   arn: arn:aws:kms:us-east-2:<redacted>:key/<redacted>
        role: arn:aws:iam::<redacted>:role/allow-ci-access-from-shared-services
        created_at: '2020-09-16T21:46:58Z'
        enc: AQI...==
        aws_profile: ""
    -   arn: arn:aws:kms:us-east-2:<redacted>:key/<redacted>
        role: arn:aws:iam::<redacted>:role/allow-full-access-from-other-accounts
        created_at: '2020-09-16T21:46:58Z'
        enc: AQI...==
        aws_profile: ""
Was this page helpful?
0 / 5 - 0 ratings