-
Notifications
You must be signed in to change notification settings - Fork 821
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
Feature: aws-vault export --credentials
#1181
Comments
aws-vault export --stored-credentials
aws-vault export --credentials
hmmm actually not sure that works |
May be the old command "aws-vault exec --json" could be modified to ignore credential_process - so the backward compatibility would be restored? I understand that it's deprecated, but it will give us a time to adopt our configs, upgrade aws-vault, etc |
In my case I do want aws-vault to ask for mfa and create temporary credentials Or another way could be to add environment variables to the new credential process like AWS_VAULT_CONFIG_FILE, AWS_VAULT_PROFILE_NAME, AWS_VAULT_CREDENTIAL_PROCESS and then avoid going into infinite credential_process loop based on those variables |
Yeah it's a decent idea |
That sounds good, but that's also what I thought |
--no-session specifically disables STS GetSessionToken which aws-vault normally utilises to share MFA creds between profiles. So that's a bit different. The use-case here is using aws-vault as a cache, which requires aws-vault to ignore the credential_process, but use the rest of the profile config when creating the credentials. So I'm thinking 2 new flags for
Any feedback on that? |
For me it seems enough to have only one flag The |
But please, consider changing This will restore backward compatibility and will give us a time to upgrade |
I'm not sure I followed your idea. But I'll try to explain my scenario: This is my
The profile was configured via I used to run I'm running macOS 13.1, and this is the
|
I don't see the difference: skipping the STS calls means the original AWS credentials are used. And for MFA creds, I think this means the actual AWS credentials that may be protected with MFA? I think that matches what you proposed in the original post. edit: I read the code and now it's clear to me what you meant. I still think, whatever solution you decide on, that edit: thinking about it more, this would break @jmczerk's use-case. I guess there needs to be a option that can be passed to
This is the new behaviour from #1087? I feel like I want |
Apologies for introducing this issue. Given my use case seems to be less common than those impacted, would it make sense to take the approach of #1117 where the the |
The core problem here is that there are a few different modes aws-vault is used in. And unfortunately many configs have been set up ambiguously by specifying multiple credential sources. I have collected the use-cases that I understand aws-vault is being used in. Use-case 1: aws-vault is the executor and provides the environmentOne group of people (myself and my team included) uses aws-vault exclusively as a runner, where aws-vault provides the environment and runs a command. [profile my_profile_master]
# master credentials stored in aws-vault
[profile my_profile_role]
source_profile=my_profile_master
role_arn=xxx aws-vault exec my_profile_master ./my-command # success, uses sts session generated by aws-vault
aws-vault exec my_profile_role ./my-command # success, uses role creds generated by aws-vault
AWS_PROFILE=my_profile_master ./my-command # Not expected to be functional
AWS_PROFILE=my_profile_role ./my-command # Not expected to be functional In this scenario, the profile name and aws config is used exclusively by aws-vault, which provides the environment for the command to run in. This is a very unix-y and 12-factor approach. It's the original (and I consider the primary) use-case of aws-vault - it's why its Use-case 2: aws-vault is a "master credentials vault" for AWS SDKA second group of people use aws-vault in [profile my_profile_master]
credential_process = aws-vault6 exec --json --no-session my_profile_master # aws-vault7 export --format=json --no-session my_profile_master
[profile my_profile_role]
source_profile=my_profile_master
role_arn=xxx aws-vault exec my_profile_master ./my-command # Not expected to be functional
aws-vault exec my_profile_role ./my-command # Not expected to be functional
AWS_PROFILE=my_profile_master ./my-command # v6: success (uses aws-vault master creds)
# v7: broken
AWS_PROFILE==my_profile_role ./my-command # v6: success (uses aws-vault master creds + SDK role)
# v7: broken The problem here is that
Use-case 3: aws-vault is a "MFA session cache" for AWS SDKVery similar to Use-case 2, another group of people want aws-vault to cache STS MFA credentials between profiles. This means they are not forced to re-authenticate with MFA every time they switch profiles. [profile my_profile_master]
mfa_serial=mmm
credential_process = aws-vault6 exec --json my_profile_master # aws-vault7 export --format=json my_profile_master
[profile my_profile_role]
source_profile=my_profile_master
mfa_serial=mmm
role_arn=xxx1
[profile my_profile_role2]
source_profile=my_profile_master
mfa_serial=mmm
role_arn=xxx2 aws-vault exec my_profile_master ./my-command # Not expected to be functional
aws-vault exec my_profile_role ./my-command # Not expected to be functional
AWS_PROFILE=my_profile_master ./my-command # v6: success (uses aws-vault session)
# v7: broken
AWS_PROFILE=my_profile_role ./my-command # v6: success (uses aws-vault session + SDK role)
# v7: broken This config has the same problem as Use-case 2, but there is also an additional point of confusion. The confusion here is that the user has set master creds via Use-case 4: aws-vault caches alternative credential sources like sso_start_url, etcaws-vault caches credentials from alternative credential sources like [profile my_profile_using_sso]
sso_start_url = https://mycompany.awsapps.com/start
[profile my_profile_using_process]
credential_process = my-custom-creds-cmd aws-vault exec my_profile_using_sso ./my-command # success, uses aws-vault caching
aws-vault exec my_profile_using_process ./my-command # success, uses aws-vault caching
AWS_PROFILE=my_profile_using_sso ./my-command # success, no caching
AWS_PROFILE=my_profile_using_process ./my-command # success, no caching SolutionsThere are a few possible solutions to the problems identified in use-case 2 and 3. Solution 1. Use a separate profile name for the master credsUse-case 2: [profile my_profile_vault]
# master credentials stored via 'aws-vault add my_profile_vault'
[profile my_profile_master]
# get master credentials
credential_process = aws-vault7 export --format=json --no-session my_profile_vault
[profile my_profile_role]
# master creds sourced, role assumed
source_profile=my_profile_master
role_arn=xxx
mfa_serial=mmm Use-case 3: [profile my_profile_vault]
# master credentials stored via 'aws-vault add my_profile_vault'
mfa_serial=mmm
[profile my_profile_session]
# get STS session
credential_process = aws-vault7 export --format=json my_profile_vault
mfa_serial=mmm
[profile my_profile_role]
# session sourced, role assumed
source_profile=my_profile_session
role_arn=xxx
mfa_serial=mmm Pros:
Cons:
Solution 2. Tell aws-vault to output master credentials only with
|
I'm using aws-vault similar to case 3 (mfa session cache) and actually v6 works for both I vote for solution 4 (--ignore-credential-process) - it fixes problem, will allow to use aws-vault exec or mycmd directly and no need to add extra profiles I prefer it more than solution 7 (aws_vault_ignore_credential_process=true) because command line flag is more flexible – I can add it to credential_process or use it while running aws-vault export directly from my shell or some other script |
Regardless of the future chose solution, please note that this new flag should be documented in (https://github.com/99designs/aws-vault/blob/master/USAGE.md#using-credential_process)[the USAGE documentation]. I've stumbled upon the "initial bug" by actually following it and others may fall into the same trap as I did. |
@mtibben thanks for gathering these use cases. I actually have another use case: combined 1 & 2 & 3:
which worked fine in v6, and means I get prompted once for my MFA token while the session is still active, regardless of which tool I use. My proposal for a solution is: don't call |
Sorry @dgholz I don't exactly understand what that means. Can you provide a simple-as-possible example of the config, commands, and expected behaviour?
🤔 Simple and effective. It might just work. Great idea @dgholz. I'll add it to the list |
A pre-release fix has been released v7.0.2-beta2 release with the Solution 9 fix (#1183) suggested by @dgholz. Please test it and provide any feedback to ensure that this is doing the right thing |
Fixed in #1183 |
I wonder if we should create a
aws-vault export --stored-credentials PROFILE
, a new flag that will only output the master credentials in the vault and never attempt to create temporary credentials.This seems to be the use-case of #1176 and #1180 which have been raised after the introduction of
credential_process
as a way to source credentials in v7.Would this help avoid creating extra profiles just for credentials?
Thoughts @ArjunDandagi @dgholz @Ketouem @jweyrich @olfway
The text was updated successfully, but these errors were encountered: