-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
Does not work with aws-okta or aws-vault #7
Comments
Thanks for reporting this. I've never used aws-vault or okta so I apologize for it not working straight away. Shouldn't be too tough to figure out though. |
Cool. Lemme know if I can help testing.
Fernando Battistella
…Sent from my iPhone
On Jul 17, 2018, at 1:05 PM, Tyler Brock ***@***.***> wrote:
Thanks for reporting this. I've never used aws-vault or okta so I apologize for it not working straight away. Shouldn't be too tough to figure out though.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Was just reading about this a bit, can you describe your configuration a little bit more? In the In your case I'd expect an entry for |
Yes, its exactly like they have in the link
```
[profile auth_or_bastion_account]
region=us-east-1
[profile admin]
mfa_serial = arn:aws:iam::123456789012:mfa/jonsmith
source_profile = auth_or_bastion_account
role_arn = arn:aws:iam::123456789012:role/admin-access
```
while profile admin can be also assuming a role in another account.
like in a project i am working right now, there is a main authentication only account, with an mfa, and from there you assume roles on the secondary accounts.
most of the projects I'm working lately use something similar to this, as this implementation is now recommended by aws under their "landing zone" setup.
functionality wise, the only difference from a regular aws cli setup is that instead of saving the key/secret key in a text file, it saves on your macos keychain (or linux/windows similar).
and when you call the profile it exposes the credentials it gets as env vars.
e.g.
➜ env | rg AWS
AWS_HOME=/Users/fernando/.aws
➜ aws-vault exec company-sandbox -- env | rg AWS
AWS_HOME=/Users/fernando/.aws
AWS_VAULT=company-sandbox
AWS_DEFAULT_REGION=ca-central-1
AWS_REGION=ca-central-1
AWS_ACCESS_KEY_ID=AAAAAAAAAAAAredactedofcourse
AWS_SECRET_ACCESS_KEY= AAAAAAAAAAAAredactedofcourse
AWS_SESSION_TOKEN=longassstring
AWS_SECURITY_TOKEN=anotherlongassstring
hope this helps a bit :)
Cheers,
Fernando Battistella
… On Jul 22, 2018, at 1:48 PM, Tyler Brock ***@***.***> wrote:
Was just reading about this a bit, can you describe your configuration a little bit more?
In the aws-vault docs it says for you profile to assume a role your ~/.aws/config should look something like what they have here <https://github.com/99designs/aws-vault#assuming-roles> where read-only is the source profile and admin is the one having elevated privileges.
In your case I'd expect an entry for myprofile and one for secondary-role that references myprofile as the source. I'm new to aws-vault so forgive me if this is not on target but do you have something like that in your config?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIkdlNUIav_nl-kT_tRxL7ttrJPunjcSks5uJLrggaJpZM4VQZyU>.
|
aws-okta works fine for me together with saw. Lil wrapper in my function saw {
aws-okta exec "myprofile" -- saw "$@"
} |
Works fine for me with aws-vault. Nothing special, just
|
These two tools allow you to save your credentials in the keychain instead of the plain text file in .aws/credentials, and they work just fine with other apps that use the aws go sdk.
But whenever I try to use saw with them I get:
Lemme know if I can provide any other info.
The text was updated successfully, but these errors were encountered: