Open dhess opened 4 years ago
This is correct saml2aws doesn't currently use keychain, this is mainly because a lot of the standard aws tooling doesn't.
I am open to a PR which enables it either globally or at a profile level as I personally would :100: use that for some of my work.
@wolfeidau got any examples of anything that doesn't support env vars?
Been using aws-vault for many years (before moving to Azure AD) and not once had to have creds in .aws/credentials
@wolfeidau Got it, thanks.
In case you haven't tried them, the workflow in aws-okta
and aws-vault
is, you authenticate with the IdP and they store the temporary AWS credentials in whichever keychain you've selected. Then you wrap your aws-cli
(or equivalent) commands with aws-okta exec -- <cmd> <args>
or aws-vault exec -- <cmd> <args>
, which sets the appropriate AWS SDK environment variables in the subshell in which the child commands run, having pulled the values from the keychain. They'll also check the values recovered from the keychain for expiration and automatically re-run the authentication step, if needed.
Personally, I think the added safety of never storing even temporary AWS credentials on the filesystem in plaintext is worth the inconvenience of wrapping everything with aws-okta exec
, but I can imagine scenarios where that might not be feasible.
When configured via #120 the commands no longer need wrapping, as the AWS CLI can query the subprocess to ask for credentials directly.
Hi, I'm an
aws-okta
refugee and I'm evaluatingsaml2aws
as a possible replacement. One thing I like aboutaws-okta
andaws-vault
is that they store your temporary AWS credentials in the configured keychain (system keychain, pass, etc.), rather than in~/.aws/credentials
.It's possible I'm being dense, but as far as I can tell, the keychain support in
saml2aws
is limited to storing your IdP credentials, and there's no way to tell it to store the granted AWS creds in the keychain. Is that correct?