At my work, when using aws cli we use aws_session_token. I don't see anything in puppetlabs-aws support for aws_session_token. Any ideas?
AWS_SESSION_TOKEN is usually used when you're obtaining temporary credentials from AWS security token service (STS). This is usually when you make the call to Assume a role. So a lot of this depends on how you've got your command line set up:
If you are explcitly calling assume role like this:
aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/RoleToAssume" --role-session-name AWSCLI-Session
You should get back a response with three variables:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
You should just be able to export each of these as environment variables and then run puppet apply.
If you are not explicitly calling assume role and are using instance profiles, puppet should automatically find these 3 variables.
If you are calling assume role via AWS_PROFILES in your ~/.aws/config then it should just be sufficient to run puppet apply after setting the AWS_PROFILE environment variable.
You may also want to consider using the newer puppetlabs amazon_aws module which superseeds puppetlabs/aws.
Related
I want to pull from a private AWS ECR. I have created a new policy and a API user with the correct permissions to pull.
The issue I have is... I'm running this on a machine where I don't want to use credentials files:
aws ecr get-login
I would like to use the aws_access_key_id and aws_secret_access_key to get a login token i.e
aws ecr get-login <aws_access_key_id> <aws_secret_access_key>
Is this possible or do I have any way to achieve this without saving out a file or running aws configure?
You can specify your configuration with environment variables, for example like this (Linux/Mac OS):
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-west-2
They will then only last until the end of your shell session (unless you put them in your shell startup script). You can read more about this, and see additional examples here.
I have an assumed role which I assumed using aws sts assume-role CLI command.
I want to "unassume" this role and switch back to my aws credentials configured in my local system.
How do I acheive this?
I have tried doing so by going to the console and clicking the "Revoke Active Sessions" button, but that doesn't seem to be working. I tried rm -r ~/.aws/cli/cache too but in vain. Please help
There's a few things you can do:
You can unset the AWS environment variables in your terminal:
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
You can reconfigure your aws configuration:
aws configure
However, you'll need to make sure there are no environment variables set for your AWS credentials. By default, the AWS CLI looks at your environment variables, then your config file, then your credentials file for credentials to use in CLI commands.
I had an AWS account configured to work with the CLI. The free tier expired so I setup another account. I created an IAM user ran aws configure and put in the credentials for that user. I have the default profile setup with that users credentials as well.
From the cli if I run the command aws s3 ls it will always show the buckets from the old account. If I specify the profile using aws s3 ls --profile GrantM then it lists the buckets from the correct account and IAM user.
The environment variables are set to the new user also. Can someone explain this and how to switch it to use my new account?
create or edit this file:
% vim ~/.aws/credentials
list as many key pairs as you like:
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
[user1]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
set a local variable to select the pair of keys you want to use:
% export AWS_PROFILE=user1
do what you like:
aws s3api list-buckets # any aws cli command now using user1 pair of keys
more details:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
When you use aws configure without any additional arguments it should allow you to amend the default profile, which is the one that is being accessed when you specify no profile. By amending this you will not need to specify the --profile flag.
If you would also like to amend over named profiles you would simply use aws configure --profile $PROFILE_NAME, where you can just as above replace the credentials currently stored in the configuration.
Alternatively for Linux/MacOS you can access your credentials in ~/.aws/credentials or for Windows in %USERPROFILE%\.aws\credentials. You can modify these files to replace any values.
More information is available on the Named profiles documentation page.
I would not mix environment variables and credentials profiles, you'll just get confused.
Remove the environment variables, ensure that the default profile in your ~/.aws/credentials file (or %USERPROFILE%\.aws\credentials on Windows) is set to the new credentials, then run aws s3 ls. If it's not what you expected, then run aws s3 ls --debug to work out what you did wrong.
According to Credentials — Boto 3 Docs documentation, the Environment Variables will be used in preference to the configuration files.
Therefore, I suggest you remove the credentials from your Environment Variables, and just use the configuration files.
Depending upon your operating system, you could use unset, or remove them from where ever you put them in the Environment Variables.
run on terminal where you be running the cli commands
export AWS_PROFILE='PROFILE_NAME'
move this the bashrc/zshrc file to make this permanent or just add a default section to the .aws/config and .aws/configure. Run following command and input the credentials you want.
aws configure
works on mac and windows.
Disclaimer: I do have variable AWS_PROFILE set to default and echo $AWS_PROFILE does return default.
However though, my simple aws commands are failing if I do not pass --profile flag with it.
For example,
if I do aws2 s3 ls, then it fails with error : An error occurred (InvalidToken) when calling the ListBuckets operation: The provided token is malformed or otherwise invalid.
when I do, aws2 ec2 describe-instances, it fails with error An error occurred (AuthFailure) when calling the DescribeInstances operation: AWS was not able to validate the provided access credentials
even though message is different, the underlying problem is same. If I do aws2 s3 ls --profile default then it works fine, same with aws2 ec2 describe-instances command.
I have no idea how to not need the --profile flag even though I do have AWS_PROFILE set.
my credentials file look like following:
[default]
aws_access_key_id = AKIA****
aws_secret_access_key = VpR***
My config file looks like following:
[default]
region = us-west-1
output = json
I have set following two enviroment variables:
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Also, Ihave echoed their values back and made sure that the values are same exact as in credentials file.
any ideas?
Use unset AWS_PROFILE to remove profile plag.
Run aws configure to update the credential
Make sure your machine time is correct.
The profile referenced by AWS_PROFILE is invalid or expired. Your default profile is valid. That is why you see the error behavior. Check all credentials via cat ~/.aws/configure and remove or correct any that are invalid.
ok so I am baffled by this aws cli behavior. Basically what is going on is that when I set my AWS creds related in environment variable, AWS CLI forces me to pass --profile flag each time I use the CLI.
So basically when AWS_ACCESS_KEY_ID AND AWS_SECRET_ACCESS_KEY then I cannot run commands like aws s3 ls without passing --profile flag to it even though my profile is [default]
Also, jus to note the environment variable values and the values inside my /.aws/credentials
file is exactly same. Also, I tried to set both AWS_PROFILE and AWS_DEFAULT_PROFILE to default hoping that if all values such as keys,secret and profile are set in environment variable then I do not have to pass any --profile flag explicitly. Not having to pass this flag explicitly is very important for me at this point because if I am running an application which connects with aws and picks up default credentials, there is no easy way to pass profile information to that app.
my credentials file look like following:
[default]
aws_access_key_id = AKIA****
aws_secret_access_key = VpR***
My config file looks like following:
[default]
region = us-west-1
output = json
And my environment variables do have the same values for corresponding entries. for key, secret and profile at least.
Any idea on how to solve this issue?
The AWS CLI looks for credentials using a series of providers in a particular order. (https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#config-settings-and-precedence)
Specifically:
Command line options – You can specify --region, --output, and --profile as parameters on the command line.
Environment variables – You can store values in the environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN. If they are present, they are used.
CLI credentials file – This is one of the files that is updated when you run the command aws configure. The file is located at ~/.aws/credentials on Linux or macOS, or at C:\Users\USERNAME\.aws\credentials on Windows. This file can contain the credential details for the default profile and any named profiles.
CLI configuration file – This is another file that is updated when you run the command aws configure. The file is located at ~/.aws/config on Linux or macOS, or at C:\Users\USERNAME\.aws\config on Windows. This file contains the configuration settings for the default profile and any named profiles.
Container credentials – You can associate an IAM role with each of your Amazon Elastic Container Service (Amazon ECS) task definitions. Temporary credentials for that role are then available to that task's containers. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide.
Instance profile credentials – You can associate an IAM role with each of your Amazon Elastic Compute Cloud (Amazon EC2) instances. Temporary credentials for that role are then available to code running in the instance. The credentials are delivered through the Amazon EC2 metadata service. For more information, see IAM Roles for Amazon EC2 in the Amazon EC2 User Guide for Linux Instances and Using Instance Profiles in the IAM User Guide.
Another potential option for you would be to unset any colliding variables in your env and rely on the aws credentials file to provide the appropriate access credentials from the default entry.