AWS CLI Credentials Provider Chain
The CLI will look for credentials in this order
- Command line options --region, --output, and --profile
- Environment variables - AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN
- CLI credentials file - aws configure
- CLI configuration file
- Container credentials - ECS tasks
- Instance profile credentials
The IAM Instance profile was assigned to the EC2 instance, but it still had access to ALL s3 buckets. Why?
Answer: The credentials chain is still giving priorites to the environment variables.
Metadata
- It allows AWS EC2 instance to "learn about themselves" without using an IAM roe for that purpose.
- The URL is http://169.254.169.254/latest/meta-data
- Metadata = info about the EC2 instance
- Userdata = launch script of the EC2 instance
- You can retrieve the IAM Role name from the metadata, but you CANNOT retrieve the IAM policy
SDK
- AWS CLI uses th Python SDK
- If you don't specify or configure a default region, then us-east-1 will be chose by default
MFA with CLI
- To use MFA with the CLI, you must create a temporary session
- To do so, you must run the STS GetSessionToken API call
AWS Credentials Bests Practices
- NEVER EVER STORE AWS CREDENTIALS IN YOUR CODE
- Best practice is for credentials to be inherited from the credentials chain
- If using working within AWS, use IAM Roles
- => EC2 Instances Roles for EC2 Instances
- => ECS Roles for ECS tasks
- => Lambda Roles for Lambda functions
- If working outside of AWS, use environment variables / named profiels
AWS CLI STS Decode Errors
- When you run API calls and they fail, you can get a long error message
- This error message can be decoded using the STS command line
- sts decode-authorization-message
Sign AWS API requests
- When you call the AWS HTTP API; you sign the reuqest so that AWS can identify you, using your AWS credentials (access key & secret key)
- Note: some requests to Amazon S3 don't need to be singed
- If you use the SDK or CLI, the HTTP requests are signed for you
- You should sign an AWS HTTP request using Signature v4 (SinV4)
Ganting a User Permissions to Pass a Role to an AWS Service
- To configure many AWS services, you must pass an IAM role to the service (this happens only once during setup)
- The service will later assume the role and perform actions
- Example of passing a role
- To an EC2 instance
- To a Lambda function
- To an ECS task
- To CodePipeline to allow it to invoke other service
- FOr this, you need the IAM permission iam:PassRole
- If often comes with iam:GetRole to view the role being passed
The first statement says: Allow any Resource to perform any EC2 actions.
Second statement says: Only allow to assign S3Access role to EC2.
Role CANNOT be passed to ANY service because there is "trust policy", for example, you can assign some roles to Lambda or EC2, to allow those service act on your behalf (access DynamoDB...S3...), but you cannot assign the same role to other service like KMS... which doesn't make sense.
- AD Connector: using proxy
- Simple AD: cannot be joined with on-permise AD
- AWS Managed Microsoft AD: MFA support