Package: aws-export-credentials
aws-export-credentialsGet AWS credentials from a profile to inject into other programs:warning: The AWS CLI now includes a commandaws configure export-credentialsthat covers the--json,--env, and--env-exportoptions ofaws-export-credentials, as well as providing env options for Windows.If you want to inject refreshable credentials into a locally-run container,imds-credential-serveris a more focused solution for that.There are a number of other projects that extract AWS credentials and/or inject them into programs, but all the ones I've seen use the CLI's cache files directly, rather than leveraging boto3's ability to retrieve and refresh credentials.
So I wrote this to do that.boto3 (the AWS Python SDK)has added support for loading credentials cached byaws sso loginas ofbotocore version 1.17.0.aws-export-credentialsnow requires boto3 >= 1.14.0, and so supports AWS SSO credentials as well.
If all you want is AWS SSO support for an SDK other than Python, Go, or JavaScript (v3), take a look ataws-sso-util, which can help you configure your profiles with acredential processthat doesn't require the credential injection process thataws-export-credentialsdoes.QuickstartI recommend you installpipx, which installs the tool in an isolated virtualenv while linking the script you need.# with pipxpipxinstallaws-export-credentials# without pipxpython3-mpipinstall--useraws-export-credentials# run itaws-export-credentials{"Version":1,"AccessKeyId":"<your access key here>","SecretAccessKey":"<shhh it's your secret key>","SessionToken":"<do you ever wonder what's inside the session token?>"}You can also download the Python file directlyhere.UsageProfileProfiles work like in the AWS CLI (since it uses boto3); it will pick up theAWS_PROFILEorAWS_DEFAULT_PROFILEenv vars, but the--profileargument takes precedence.JSONaws-export-credentials --profile my-profile --json [--pretty]Print the credentials to stdout as a JSON object compatible with thecredential_processspec. If--prettyis added, it'll be pretty-printed.Env varsaws-export-credentials --profile my-profile --env
export $(aws-export-credentials --profile my-profile --env)
eval $(aws-export-credentials --profile my-profile --env-export)Print the credentials as environment variables. With--env-export, the lines are prefixed
by "export".Exec wrapperaws-export-credentials --profile my-profile --exec echo 'my access key id is $AWS_ACCESS_KEY_ID'Execute the arguments after--execusingos.system(), injecting the credentials through
environment variables.~/.aws/credentialsaws-export-credentials --profile my-profile --credentials-file-profile my-exported-profile
aws-export-credentials --profile my-profile -c my-exported-profilePut the credentials in the given profile in yourshared credentials file, which is typically~/.aws/credentialsbut can be controlled using the environment variableAWS_SHARED_CREDENTIALS_FILE.Credential-serving optionsThere are two credential-serving options,--imdsfor a server presenting the EC2 IMDSv2 interface, and--containerfor a server presenting the ECS container metadata credentials interface.:warning: If you want to inject refreshable credentials into a locally-run container,imds-credential-serveris a more focused solution for that.IMDSYou can use--imdsto start a server, compliant withthe EC2 IMDSv2 endpoint, that exports your credentials, and this can be used with containers.You provide--imdswith a port (you can optionally provide the host part as well).If you're using docker, map the port from the host to the container, and set the environment variableAWS_EC2_METADATA_SERVICE_ENDPOINTtohttp://host.docker.internal:MAPPED_PORT/with the approporiate port andremember to include the trailing slash.AWS SDKs run inside the container should just work.# in one terminal$aws-export-credentials--imds8081# in a separate terminal$dockerrun--rm-p8081:8081-eAWS_EC2_METADATA_SERVICE_ENDPOINT=http://host.docker.internal:8081/
amazon/aws-clistsget-caller-identity{"UserId":"AROAXXXXXXXXXXXXXXXXX:SessionName","Account":"123456789012","Arn":"arn:aws:sts::123456789012:assumed-role/SomeRole/SessionName"}ECS:warning: This method of providing credentials to containers doesn't work well. It only works on Linux using--network host.On MacandWindows,--network hostis not available, the docker network is always separate. On all three, without--network hostthe host cannot be referenced aslocalhost, only ashost.docker.internal, which isnot an allowed host the AWS SDKs.You can use--containerto start a server, compliant with the ECS metadata server, that exports your credentials, suitable for use with containers.You provide--containerwith a port (you can optionally provide the host part as well) and an authorization token.
On your container, map the port from the server, set theAWS_CONTAINER_CREDENTIALS_FULL_URIenvironment variable to the URL as accessed inside the container, and set theAWS_CONTAINER_AUTHORIZATION_TOKENenvironment variable to the same value you provided the server.You can use any value for the authorization, but it's best use a random value.# Generate token. For example, on Linux:AWS_CONTAINER_AUTHORIZATION_TOKEN=$(/proc/sys/kernel/random/uuid)# start the server in the backgroundaws-export-credentials--profilemy-profile--container8081$AWS_CONTAINER_AUTHORIZATION_TOKEN&# run your containerdockerrun--networkhost-eAWS_CONTAINER_CREDENTIALS_FULL_URI=http://localhost:8081-eAWS_CONTAINER_AUTHORIZATION_TOKEN=$AWS_CONTAINER_AUTHORIZATION_TOKENamazon/aws-clistsget-caller-identityCachingTo avoid retrieving credentials every time when usingaws-export-credentialswith the same identity, you can cache the credentials in a file using the--cache-fileargument.Noteaws-export-credentialsdoes not distinguish in the cache between different identities. Different identities should use different cache files.If you do not account for this, credentials may be loaded from the cache and exported that do not correspond to the credentials that would be exported without the cache.
An example of a way to address this would be using a cache file named after the config profile you are exporting.Cache loading and saving fails silently, to ensure caching does not interrupt usage.
If caching is not working, you can see the details with--debug.By default, cached credentials are considered expired if their expiration is less than 10 minutes in the future.
You can change this value using the--cache-expiration-bufferargument, which takes a number of minutes.You can force the cache to refresh using--refresh.Temporary credentialsIAM Users and the account root have long-term credentials, which carry higher risk than temporary credentials.
TheSTS.GetSessionTokenAPI call exists to provide temporary credentials based on these long-term credentials.
If you pass the--ensure-temporaryflag, it will use this API to get temporary credentials to export for an IAM User or account root.
This process is always used for--imdsand--container.Role assumptionIn general, it's better to do role assumption by using profiles in~/.aws/configlike this:# this is a pre-existing profile you already have[profile profile-to-call-assume-role-with]# maybe it's IAM User credentials# or AWS SSO config# or whatever else you may have[profile my-assumed-role]role_arn=arn:aws:iam::123456789012:role/MyRole# optional: role_session_name = MyRoleSessionNamesource_profile=profile-to-call-assume-role-with# or instead of source_profile, you can tell it to# use external credentials. one of:# credential_source = Environment# credential_source = Ec2InstanceMetadata# credential_source = EcsContainerYou can then usemy-assumed-rolelike any other profile.
It uses the AWS SDKs' built-in support for role assumption, rather than relying on third party code.
It also gets you credential refreshing from the SDKs, where getting the credentials in the manner below cannot refresh them when they expire.You can then, if needed, export the assumed role credentials withaws-export-credentials --profile my-assumed-role.But if you absolutely must have ad hoc role assumption on the command line, you can accomplish that throughaws-assume-role-lib.