If this is the first post you are reading in the #CloudSecurity series, Welcome! :) You will find some of the other topics covered under #CloudSecurity by me interesting too. Please feel free to follow my medium profile to see the remaining Cloud Security articles and be updated on upcoming posts on the same topic. I love connecting and talking security so do head to www.ashishrajan.com and connect with me to continue the conversation. Ok, back to the post.
If you prefer consuming educational content in video format, I have you covered. For everyone else keep reading.
From this point onwards, I assume that you have basic working knowledge of AWS to be able to create an AWS Account and understand what is an AWS IAM User. If you don’t and would want me to point you to resources that can help, feel free to comment and I can point you to them.
In this blog post we will be talking all things AWS Access keys, including What are they? Why would you need AWS Access Keys? Where can you find your AWS Access Keys? Access Keys Best Practice — Pattern and Anti-Pattern. Let’s start…
What are AWS Access Keys?
AWS Access Keys are a pair of secret credentials that allows individuals or enterprise users (with access to an AWS Account) to programmatically talk to protected AWS service endpoints.
These keys can be used to authenticate and run commands on AWS services over an encrypted channel.
AWS Access Keys are a pair of credentials called AWS Access Key ID & Secret Access Key. Access keys are recommended to be treated similar to username and password that you would have to login into an online service like Facebook/linkedin so no sticky notes with keys or sharing these keys with people you don’t trust.
What is AWS Access Key ID and Secret Access Key?
These credentials can be used to programmatically talk to AWS services in a “trusted” AWS Account using API or Cli protocols over encrypted channel. “Trusted” account in this context refers to the AWS Account where these credentials were generated.
Why will I need Access Keys?
AWS Access keys can be used to automate actions in an AWS Account. The action can be as benign as using ‘get-caller-identity’, which tells you what IAM user and which AWS account ID do the access keys belong to, to ‘put-bucket-acl’ which can be potentially dangerous as opening up S3 buckets to the internet. Full list of the possible actions against the AWS services can be found here.
Automating Security Capability and much more
Access Keys enable automating actions that used to be chore in on-prem environments. This awesome feature is tool that any developer, DevOps, DevSecOps or a security engineer can use to automate security in their organisaiton’s AWS cloud environment. This means you can use Access keys to automate things on these AWS Accounts. This can be things like running a script with set of commands or just set of commands directly from your terminal/powershell to —
- patch all your AWS EC2 instances
- find out all the AWS services currently being used in your organisation AWS accounts
- find out if you have any machines in AWS which may be affected by Heartbleed or something similar.
- You can even go one up on sophistcation to even start raising alarms on activity you detect as suspicious in your AWS Accounts.
There can be many more scenarios but you get the picture. Security and automation together, who would have thought. :)
Where do I find these AWS Access Keys?
AWS Access keys can be generated for an IAM user in two ways:
- AWS Management Console
Head to the IAM Console → Create IAM User to generate access keys for or use an existing user → Click on the Security Credentials link → Look for Access Credentials
- AWS Command Line Interface(Cli)
Install AWS Cli → Once successfully installed use the ‘aws configure’ to set the AWS Access Keys to use.
Refer to my youtube video above if you want to see how you can find your Amazon Web Service Access Key and how can you get AWS Access keys.
How do AWS Access Keys work?
Access Keys can authenticate and communicate with AWS service endpoints on encrypted channel like HTTPS. Once authenticated to AWS, all the commands send to execute are signed to help AWS identity who is requesting an action. This also prevents a possible replay attack by having a time based checks on incoming request at AWS end. You can also generate temporary credentials using Access keys against the AWS Security Token Service (STS).
AWS Access Key Security Considerations
As a cloud secuirty enthusiast, you should know the following when thinking about AWS Access Keys:
- Each IAM user can have maximum of two pair of Access Keys
- Each Access Keys has a current status displayed as active/disabled. The current state of access keys can be confirmed both from AWS Management Console and AWS CLi.
- The Access Keys will have the same persmission as the IAM user used to generate the access keys
- If the IAM user has a roles and/or policies which grants it admin level privileges, the access keys can perform the same admin level functions.
- All commands run against the AWS account are recorded in AWS CloudTrial, an audit services from AWS.
AWS Access Key Security Best Practice
- Generate access keys for AWS IAM users and never for a Root User
- Use AWS generated short term temporary credentials e.g via STS or Instance Role, instead of creating long term Access Keys for IAM users, especially if you only need api access for a very short period of 1hr.
- Rotate access keys periodically. Every 3–6 months is a good average based on the senstivity of the permission that the access keys have. Rotation can be performed both from AWS Management console (manual) and AWS Cli (automated)
- Disabled/Delete unused Access Keys
- IAM user with Access Keys should have IAM permission restricted only to actions and AWS Services they would need to fulfill activities required for their work
- Federate User identities instead of IAM Users as this will also use temporary security credentials instead of long terms creds
- Use IAM Roles or AWS STS services where possible when talking to AWS services programmatically instead of AWS Keys.
- Enable Two-factor authentication on IAM users with admin permission who also have access keys
- Generating access keys for root users is a big NO
- Providing IAM User with Access keys for 3rd party services is a big NO. Ask the 3rd party to use 3rd Party IAM roles instead.
- Hard coding access keys in source code of programs or mobile app talking to an AWS Account is a big NO.
- Having multiple active access keys for each IAM User is a big No.
- Generating Access keys with Cross Account Access is a big No.
- Storing Access Keys on AWS EC2 Instances as environment variables or AWS credential file, instead of use AWS Instance Role is a big NO
- Never rotating access keys for an IAM user is bad
- Using long term keys (AWS Access keys) instead of short term keys (AWS STS creds)
Thank you for your time. Now since you are armed with Good,Bad and Ugly of this AWS service go out in the world and create secure things.