Does not work with aws-okta or aws-vault

[tylerbrock]

Does not work with aws-okta or aws-vault

[TylerBrock]

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.

[argais]

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.

[TylerBrock]

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?

[argais]

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>.

[udondan]

aws-okta works fine for me together with saw. Lil wrapper in my .bashrc and instantly worked.

function saw {
        aws-okta exec "myprofile" -- saw "$@"
}

[arnuschky]

Works fine for me with aws-vault. Nothing special, just

aws-vault exec <profile> -- saw ...