Quick warning before we start

This is the friendly tutorial that helps you create an AWS access key and secret for CLI access to S3 without setting your account on fire. You will learn where to make keys in IAM how to configure the AWS CLI and how to test that your new credentials actually work.

What you will need

• An AWS account with permission to manage IAM users or your friendly admin on speed dial
• A user account to attach programmatic access to
• A password manager or secrets vault so you do not paste secrets into a gist or a public repo

Step by step

1. Open the AWS Console and go to IAM

   Find IAM in the services list and click in. That is where identities and credentials live. You can create a brand new user or pick an existing one to grant programmatic access.

2. Enable programmatic access for the user

   When you create or edit the user enable programmatic access so API and CLI calls will be allowed. This is required for S3 command line operations.

3. Attach least privilege policies

   Do not hand out AdministratorAccess like candy. For S3 tasks attach a scoped policy or use AmazonS3ReadOnlyAccess when read only is enough. If you need write access craft a policy that limits buckets and actions to the smallest scope that still gets the job done.

4. Create the access key and save the secret

   From the user security credentials tab create a new access key. The secret access key is shown only once. Save it to your password manager or download the key file. If you lose the secret you cannot recover it and must make a new key pair.

5. Configure the AWS CLI

   Run aws configure and paste in the Access Key ID and Secret Access Key when prompted. You can also set credentials using environment variables if you prefer shell scripting.

   export AWS_ACCESS_KEY_ID=YOURACCESSKEY
   export AWS_SECRET_ACCESS_KEY=YOURSECRETKEY
   export AWS_DEFAULT_REGION=us-east-1

   The CLI stores credentials in the .aws folder under your user profile so commands can authenticate without you typing the key every minute like a caffeine powered robot.

6. Verify S3 access

   Test the new credentials with a simple command. If you have at least list permission try running

   aws s3 ls

   If you get a permission error go back and check the policies you attached. Do not create more keys as an emotional reaction to permissions errors.

Best practices that keep you out of trouble

• Rotate keys regularly and delete any keys that are not in use
• Never commit keys to source control or paste them into issue trackers
• Use scoped policies to follow least privilege principles
• Store secrets in a secure vault or use AWS Secrets Manager when appropriate
• Enable MFA and monitor usage with CloudTrail so you spot suspicious access fast

Troubleshooting and tips

If aws s3 ls fails with access denied inspect the attached policy and the resource ARNs involved. If the policy looks fine check for deny policies at the account level or SCPs in AWS Organizations that might be blocking access.

If you need temporary credentials consider using roles and assume role flows rather than long lived keys. Roles are the grown up way to do things and they reduce the chance of accidental exposure.

Final words of wisdom

Creating keys is boring but necessary. Treat the secret like a toothbrush and not like a sticky note. Rotate keys often and remove unused credentials. Follow least privilege and you will sleep better at night. If you ever need to explain why a credential leaked at least make it a good story.