Open sherifabdlnaby opened 3 years ago
I'd prefer to leave these as separate tools, but is there a place in the documentation that you think this would be appropriate to mention?
@benkehoe I dunno, I feel like having aws-export-credentials
also bundled with aws-sso-utils
has a very good use-case which is containers.
We can add a place in documentation to explain how to use your SSO Credentials in your development container.
I've been thinking more about this. What I don't want is people constantly exporting environment variables as a substitute for actually using profiles. I don't have a problem telling people that if they really need to bridge credential providing, they should install aws-export-credentials
alongside aws-sso-util
(it's not that hard).
But I do see the use case of "tell someone to run a command as a particular account and role". I am thinking about something like this:
aws-sso-util run-as --sso-start-url https://example.awsapps.com/start --sso-region us-east-2 --account-id 123456789012 --role-name Developer --region us-west-2 aws s3 cp s3://some-bucket/some-key ./my-file
Note that the start URL and SSO region would be determined using the usual logic, so they wouldn't necessarily need to be set. Potentially the same with region, it could have a special environment variable to set a default value.
For multiple commands, I think I'd recommend this pattern:
export AWS_CONFIG_FILE=$(mktemp --suffix .aws-config)
aws-sso-util configure profile default --sso-start-url https://example.awsapps.com/start --sso-region us-east-2 --account-id 123456789012 --role-name Developer --region us-west-2
aws sts get-caller-identity
aws s3 cp s3://some-bucket/some-key ./my-file
rm -f $AWS_CONFIG_FILE
AWS_CONFIG_FILE=
export -n AWS_CONFIG_FILE
FYI. I hit an issue today where this would have been very helpful.
For a bunch of reasons which make for a boring story, I needed to use ~/.aws/credentials
to proceed. Using a 3rd party tool which uses Terraform and AWS JS SDK v2 behind the scenes and does not support credential_process
(yet. I raised a bug, but it's blocking my progress).
While I agree it shouldn't be a default or recommended approach, it would have been great for aws_sso_util
to provide the functionality to unblock me. Could easily be with a ⚠️ warning ⚠️ and link to a discussion on better approaches?
I don't have a problem telling people that if they really need to bridge credential providing, they should install aws-export-credentials alongside aws-sso-util (it's not that hard).
That would also be fine, if for instance, the command was listed in the CLI help page but aws-sso-util update-credentials-file
merely gave me more info saying it's a deprecated approach, that would have been better than not mentioning it (IMHO)
Note that I installed aws-sso-util
via brew
and aws-export-credentials
doesn't seem to be there so I found that too hard.
In the end I used aws-sso-util credential-process
to export the JSON values, and manually crafted the ~/.aws/credentials
file myself.
... which is fine ...
... but then I downloaded an AWS SSO command-line util to avoid manual edits :)
Your idea of including a command that doesn't work, but recommends another tool is interesting, I'll think about it.
There is aws-sso-util run-as
that covers some of this use case. In general, I'm supportive of harm reduction, but for AWS SSO in particular it's an opportunity to break people out of their old ways, and I'm willing to risk some people dropping out in order to educate others. It's a tricky balance for sure.
Thanks!
I looked at aws-sso-util run-as
but the usage didn't quite seem to match my needs, but with some alterations, it might be a good path forward. I've raised a separate issue/feature request for that: https://github.com/benkehoe/aws-sso-util/issues/52
for AWS SSO in particular it's an opportunity to break people out of their old ways, and I'm willing to risk some people dropping out in order to educate others. It's a tricky balance for sure
Intuitively & in principle I agree. After reflecting on this, this feels like a "type II (FN) > type I (FP)" scenario with the position that "I would rather harm an innocent person than allow a guilty person to continue" or "we don't have sharp knifes in this kitchen because some people might cut themselves".
It feels quite a hard line to take but if that's the design decision then I'm happy to accept it.
in order to educate others.
This little comment on it's own is probably worthy of it's own discussion thread :)
btw, for the OP in this thread, there is an outstanding question of how best to pass credentials to docker in the format it expects:
Could be something like:
docker $(aws-sso-utils credentials-process --profile foo --out docker) ...
I also realized I hadn't covered something in here: aws-sso-util credential-process
can be used with direct AWS SSO configuration—it does not need to reference a profile (that's for convenience when using it within a profile that includes AWS SSO configuration).
$ aws-sso-util credential-process --help
Usage: aws-sso-util credential-process [OPTIONS]
Helper for AWS SDKs that don't yet support AWS SSO.
This is not a command you use directly. In a ~/.aws/config profile set up
for AWS SSO, you can add the line
credential_process = aws-sso-util credential-process --profile NAME
with the profile name set to the profile the line is in.
This line is automatically added by aws-sso-util configure commands.
Options:
--profile TEXT Extract settings from the given profile
--sso-start-url, --start-url TEXT
--sso-region, --region TEXT
--account-id TEXT
--role-name TEXT
--force-refresh Do not reuse cached AWS SSO token
-v, --verbose, --debug Write to the debugging log file
--help Show this message and exit.
So you can use aws-sso-util credential-process --sso-start-url https://example.com/start --sso-region us-east-2 --account-id 123456789012 --role-name MyRole
to place in a credentials file (either ~/.aws/credentials
or in a file you've created and pointed to using the AWS_SHARED_CREDENTIALS_FILE
environment variable, similar to what's covered in the run-as
documentation for multiple commands). Or, if you really have to ;-) to output those credentials in JSON so you can use them directly.
Thanks, interesting to know.
I'm against the idea of putting creds in a file (whether temporary or not) so would be reluctant to take the multiple commands
temp file approach.
I fixed my original issue by contributing to the tool, and it's good to know that aws-export-util exec
is there for next time in a pinch.
Thanks for all your help and advice!
Hello,
I'd like to suggest adding
aws-export-credentials
to aws-sso-util for the sake of this use-case:crediental_process
won't work unless you have aws-sso-util inside your container (which would be undesirable).