Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow aws profile setting from metadata to be overridden. #1659

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

martelli
Copy link

When decrypting, sops uses the AWS profile setting stored in the encrypted file metadata. This is a problem as the profile can change from user to user.

This change will allow the AWS profile metadata setting to be overridden by the '--aws-profile' flag and the AWS_PROFILE environment variable, in that order of precedence. The metadata value is used as a last resort only.

When decrypting, sops uses the AWS profile setting stored
in the encrypted file metadata. This is a problem as the
profile can change from user to user.

This change will allow the AWS profile setting to be overridden
by the '--aws-profile' flag and the AWS_PROFILE environment
variable, in that order of precedence. The metadata value is
used as a last resort only.

Signed-off-by: Leandro Martelli <[email protected]>
Copy link
Contributor

@felixfontein felixfontein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution! I'm not familiar with AWS' KMS, so I cannot comment on whether this makes sense, but I have some general things.

One is that this looks like a potential breaking change to me, since a lot of AWS users might have AWS_PROFILE already set (it's an official AWS environment variable), and for them SOPS might suddenly behave differently and stop decrypting files that it was able to decrypt before. Or is this not possible for some reason? (I really don't know.)

@@ -251,6 +252,22 @@ func LoadEncryptedFileWithBugFixes(opts GenericDecryptOpts) (*sops.Tree, error)
}
}

awsProfile := os.Getenv("AWS_PROFILE")
if opts.UseAwsProfile != "" {
awsProfile = opts.UseAwsProfile
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the right place to look at environment variables. This is a library function deep down the call tree.

Maybe adding EnvVar: "AWS_PROFILE", to the CLI option would be a better place to handle this? This might have other unintended consequences, though.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I can move this logic up in the stack.

@@ -796,6 +800,7 @@ func main() {
KeyServices: svcs,
DecryptionOrder: order,
IgnoreMAC: c.Bool("ignore-mac"),
UseAwsProfile: c.String("aws-profile"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are four instances of decryptOpts creations in this file. You need to change all of them, not just one.

@martelli
Copy link
Author

martelli commented Oct 28, 2024

One is that this looks like a potential breaking change to me, since a lot of AWS users might have AWS_PROFILE already set (it's an official AWS environment variable), and for them SOPS might suddenly behave differently and stop decrypting files that it was able to decrypt before. Or is this not possible for some reason? (I really don't know.)

First, thanks for the comments and the time to review it. :)

Yeah, I'm also no sure how people usually go about it, but it was unexpected for me to have a profile be determined by the encrypted file.
My decryption was failing and it took me a while to figure out why AWS_PROFILE was not being honored. Turned out I don't have any profile named like in the metadata.

Since AWS_PROFILE is quite standard for AWS tooling, this felt like the natural fix. But I get it might break for some people.

I believe we could split this into a few steps:

  1. Have sops honor the --aws-profile flag (which doesn't happen right now). This should be low impact, as it's a new flag.

If we decide to move towards having AWS_PROFILE be authoritative:

  1. Have a grace period where sops warns users whenever AWS_PROFILE and the metadata value disagree (indicating a future break) and announce a deprecation period.

  2. After the deprecation period, switch to use AWS_PROFILE as default, but still warn users about conflicts with the metadata. Maybe even add to the message an instruction to try using the embedded profile name via --aws-profile.

I'd expect people to support this, as it might make life easier by not having to sync profile names across environments, specially around ci/cd pipelines.

How does it sound?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants