Aws-cli: Feature Request: print current temporary session credentials

Created on 9 Nov 2018  路  11Comments  路  Source: aws/aws-cli

Whenever I assume a role using a role profile, the AWS CLI fetches temporary session tokens and saves them in ~/.aws/cli/cache/${random}.json. Is there any way to print the currently used credentials? I would like to pass them as env variables to another program.
Parsing all json files and filtering the right one myself is a rather tedious and error-prone process.

assume-role feature-request

Most helpful comment

UP VOTE!!

over a year has passed and this is still an issue. I think it is necessary in vastly common instances to view the cached credential and to use it in another context outside of the cli (eg: a client). Its not like this is a security concern because if you look in the ~/aws/cli/cache/ you can still view these credentials.

As mentioned above, parsing all the cache files to find the right one is a bit tedious and expensive which is a common work around now :P

At least as a minimum expose a command to view the cached temp credentials via aws configure. Because it is kind of already partly being done. ie if you do a aws configure list --profile some_role_profile --debug you can see its actually retrieving the cached credential but only displays the last few characters. We are just saying give us an easy way to view these credentials (key, secret and token).

Peace 馃憤

All 11 comments

@hubertgrzeskowiak - Thanks for reaching out. This would be a good feature for the CLI so I'm labeling it as such pending further review and 馃憤.

@hubertgrzeskowiak - After a second look, I'm curious if you have already tried working with AWS Security Token Service (AWS STS) commands like assume-role or get-session-token ?

When using assume-role, the following command will extract the access key ID, secret access key, and session token to a specific. This can be done manually or via a script. The values can then be assigned as environment variables.:

$ aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt

The session token can also be added to an HTTP header or to a query string using a parameter named X-Amz-Security-Token to use Temporary Security Credentials with API Operations.

The temporary security credentials created by get-session-role can be used to make API calls to any AWS service with the following exceptions:

  • You cannot call any IAM APIs unless MFA authentication information is included in the request.
  • You cannot call any STS API except AssumeRole or GetCallerIdentity .

Please advise if this meets your requirement and use case.

if you have already tried working with AWS Security Token Service (AWS STS) commands like assume-role or get-session-token ?

assume-role is what the AWS CLI does internally, I believe. I can assume the same role again from within the role, but that also comes with limitations, e.g. you need to set the right permissions, the duration is capped at 1h etc. get-session-token cannot be called from within a role session - it's only available for account users and IAM users I believe.

When using assume-role, the following command will extract the access key ID, secret access key, and session token to a specific. This can be done manually or via a script. The values can then be assigned as environment variables.:

What you describe is using an IAM user profile to assume the role manually. This works, but you need to know the IAM role and which profile to use to assume it. The beauty of the AWS config is that it hides these implementation details in the credentials and config files. I only need to know the profile that holds the IAM role. This comes especially handy if you want to use a script that has expectations on the AWS profiles, but not the particular users and their roles.

I guess we could use aws --profile target configure get source_profile followed by aws --profile ${result_of_previous_call} sts assume-role target_role. This comes at the price of increased complexity though.

@hubertgrzeskowiak - Thanks for the feedback. Relabeling as a Feature Request pending more investigating.

Similar situation as @hubertgrzeskowiak. One way of solving this would be to support --target-profile parameter for sts assume-role command.

As an example the command will become,

aws sts assume-role --target-profile target

given a config,

[target]
source_profile=source
role_arn=arn:aws:iam::xxx:role/RandomRole
mfa_serial=arn:aws:iam::xxx:mfa/RandomUser

[source]
aws_access_key_id=xxx
aws_secret_access_key=xxx

Adding my vote for this feature request. It'd be great to get the temporary credentials easily to be able to use in other contexts.

UP VOTE!!

over a year has passed and this is still an issue. I think it is necessary in vastly common instances to view the cached credential and to use it in another context outside of the cli (eg: a client). Its not like this is a security concern because if you look in the ~/aws/cli/cache/ you can still view these credentials.

As mentioned above, parsing all the cache files to find the right one is a bit tedious and expensive which is a common work around now :P

At least as a minimum expose a command to view the cached temp credentials via aws configure. Because it is kind of already partly being done. ie if you do a aws configure list --profile some_role_profile --debug you can see its actually retrieving the cached credential but only displays the last few characters. We are just saying give us an easy way to view these credentials (key, secret and token).

Peace 馃憤

I think this is actually a bug more than a feature request.
This feature is needed in order to achieve functional parity with the aws configure command of AWS CLI.

Example below:

# ~/.aws/config
[profile saml]
# aws credentials for this profile are in ~/.aws/credentials
region = us-east-1
output = json

[profile admin]
output = json
role_arn = arn:aws:iam::1234567890:role/SAML-Admin
source_profile = saml
$ aws configure --profile saml list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                     saml           manual    --profile
access_key     ****************ABCD shared-credentials-file
secret_key     ****************WXYZ shared-credentials-file
    region                <not set>             None    None

$ aws configure get profile.saml.aws_access_key_id
ABCDEFGHIJKLMNOP

$ aws configure --profile admin list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                admin           manual    --profile
access_key     ****************EFGH      assume-role
secret_key     ****************RSUV      assume-role
    region                <not set>             None    None

$ aws configure get profile.admin.aws_access_key_id
$

Note that AWS CLI will display a preview of both credentials' values, but it can only output one of them.
Thus, some profiles are essentially broken in terms of their CLI functionality.

I think getting feature parity here would be easy code-wise, and provide more uniform functionality.

Thank you

@justnance based on above comment, could this be reclassified as a bug and its priority bumped up? if it required considerable new development i would understand the feature request aspect, but it seems all it's missing is a couple lines of code to display the values already being loaded by the configure function.

thanks

Ideally, it should also work for SSO credentials: after aws sso login --profile myProfile I would like to be able to get the associated credentials. They are partially visible using:

aws configure --profile myProfile list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                myProfile           manual    --profile
access_key     ****************XXXX              sso
secret_key     ****************YYYY              sso
    region                <not set>             None    None
Was this page helpful?
0 / 5 - 0 ratings