Closed argais closed 3 years ago
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 notifications@github.com 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 aws-vault
docs it says for you profile to assume a role your ~/.aws/config should look something like what they have here 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?
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 notifications@github.com 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 https://github.com/TylerBrock/saw/issues/7#issuecomment-406884498, 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 .bashrc
and instantly worked.
function saw {
aws-okta exec "myprofile" -- saw "$@"
}
Works fine for me with aws-vault. Nothing special, just
aws-vault exec <profile> -- saw ...
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.