Suggestion: Write env output to aws credentials file

[jbialy]

AWS-okta support the env command which prints the export commands that can be used to set AWS environment vars. I think that it would also be useful to have an option that appends the access, secret and token values to ~/.aws/credentials under a given [profile]?

Perhaps something like:

$ aws-okta env --save my-aws

$ cat ~/.aws/credentials
[my-aws]
aws_access_key_id = ...
aws_secret_access_key = ...
aws_session_token = ...

What are your thought about this?

[nickatsegment]

I think a different command to env would be better, maybe export or something.

That said, I feel like this can be accomplished with a pretty simple shell script:

aws-okta exec profile -- sh -c 'printf "[my-aws]
aws_access_key_id = \"$AWS_ACCESS_KEY_ID\"
aws_secret_access_key = \"$AWS_SECRET_ACCESS_KEY\"
aws_session_token = \"$AWS_SESSION_TOKEN\""' >> ~/.aws/credentials

Maybe with a few more thumbs up I'd feel better about it

[fpmoles]

I feel a more appropriate use of time, especially consider the perceived use case, would be an example of how to use this within another program.

[bazimov]

Yeah if we could write it into a credentials file as a profile would be awesome!

[jbialy]

@nickatsegment The bash script is a good suggestion. I'm going to make use of it in a form of an alias that takes care of the logic 😄

In addition to just writing out the AWS env info to the credentials file, it would really be ideal if the [profile] information is kept up to date on consecutive runs of the command instead of just being piped to the file.

[jbialy]

I feel a more appropriate use of time, especially consider the perceived use case, would be an example of how to use this within another program.

@fpmoles Lots of cli utilities can use AWS_PROFILE in order to determine where to get the AWS credentials. Having the option of storing multiple profiles in the credentials file at the same time provides flexibility when working with multiple AWS accounts. Also, having to prefix commands with aws-okta exec profile -- command in order to provide an environment is great but also a bit limiting since you lose that environment once the command exits. Saving credentials allows you to use your shell freely with the ability to access the various AWS_PROFILEs that you have authorized to!

[fpmoles]

I feel a more appropriate use of time, especially consider the perceived use case, would be an example of how to use this within another program.

@fpmoles Lots of cli utilities can use AWS_PROFILE in order to determine where to get the AWS credentials. Having the option of storing multiple profiles in the credentials file at the same time provides flexibility when working with multiple AWS accounts. Also, having to prefix commands with aws-okta exec profile -- command in order to provide an environment is great but also a bit limiting since you lose that environment once the command exits. Saving credentials allows you to use your shell freely with the ability to access the various AWS_PROFILEs that you have authorized to!

I don't want users to have access to aws outside of okta, so the profile pattern doesn't work in that use case. When writing ops scripts, especially in languages like go, having a way to integrate easily is critical, hence my comment. Today we end up using bash scripts so we can leverage this wonderful tool, but having the ability to use the guts of this tool easily with scripts written in golang would be amazing, and it really is just digging through the code and figuring it out. That being said, someone who knows the tool could probably shoot that out much faster.

[jbialy]

I don't want users to have access to aws outside of okta, so the profile pattern doesn't work in that use case.

Already users can use eval $(aws-okta env profile) and have shell wide access to the AWS credentials. I think that adding an option to export these credentials doesn't circumvent much...

When writing ops scripts, especially in languages like go, having a way to integrate easily is critical, hence my comment. Today we end up using bash scripts so we can leverage this wonderful tool, but having the ability to use the guts of this tool easily with scripts written in golang would be amazing, and it really is just digging through the code and figuring it out. That being said, someone who knows the tool could probably shoot that out much faster.

I don't think that having an export command would prevent any of these use cases.

[bazimov]

Yeah as large environment we use multiple accounts. Having aws profile gives us flexibility on running terraform per account simultaneously.

[nickatsegment]

Considering this functionality is totally doable with various scripting approaches, I would probably not include it in aws-okta. I personally don't see the utility in writing temporary creds to a file, but I'm happy that the script will scratch your itch. I'm gonna close this issue, but I have more to say :)

[nickatsegment]

In addition to just writing out the AWS env info to the credentials file, it would really be ideal if the [profile] information is kept up to date on consecutive runs of the command instead of just being piped to the file.

Yep, I see this limitation. Updating the INI with bash and friends reliably would probably be tough, but I bet this would be a python one-liner.

also a bit limiting since you lose that environment once the command exits

As jbialy mentioned, you can use env to add creds to your current shell. I often do aws-okta exec profile -- bash just because I like to be explicit.

Having aws profile gives us flexibility on running terraform per account simultaneously.

Not really clear on how this is different to something like aws-okta exec p1 -- terraform apply && aws-okta exec p2 -- terraform apply. While TF runs are generally not hours (hopefully!), I wonder how you'd handle the temporary nature of the creds if you're reusing them; you can't tell if they're expired until the API calls start failing, whereas if you're using exec, you know that the creds are good for as long as the TTL that you set (modulo #179).

[jbialy]

While TF runs are generally not hours (hopefully!), I wonder how you'd handle the temporary nature of the creds if you're reusing them; you can't tell if they're expired until the API calls start failing, whereas if you're using exec, you know that the creds are good for as long as the TTL that you set (modulo #179).

We have ran into these situations in our environment. This is a good point! Using exec definitely makes dealing with token expiry a non issue 😄

BTW, thanks for creating this utility, it's really awesome!

[bazimov]

@jbialy I have written quick wrapper gist for this if you would like to try out: https://gist.github.com/bazimov/834d7457c4653bea24458586216c4e75

[jbialy]

@jbialy I have written quick wrapper gist for this if you would like to try out: https://gist.github.com/bazimov/834d7457c4653bea24458586216c4e75

Thanks for putting this together. I will give it a try! 👍

[mike-zorn]

Would you consider accepting a PR for this feature? I've unfortunately got a use case that doesn't seem to be handled by any of the work-arounds.

We have some ansible scripts that use multiple AWS profiles (artifacts are stored in a different aws account, so we need to use two accounts simultaneously to deploy). As a result, we can't just call aws-okta exec with different profiles for two different commands: we just have a single command that uses two profiles.

Moreover, the bash script to append to the credentials file doesn't work very well because it only works once. Once your token expires and you append to the file again, the file is invalid because there are two entries for a single profile in the credentials file.