These notes were written while working through the A Cloud Guru AWS Certified Solutions Architect - Associate online course. These notes are partly from the videos, and also from various other online sources. Primarily, they’re notes for me, but you might find them useful too.
Since the AWS platform is changing so quickly, it’s possible that some of these notes may be out of date, so please take that into consideration if you are reading them.
Please let me know in the comments below if you have any corrections or updates which you’d like me to add.
IAM (Identity and Access Management)
- Gives you centralised control of an AWS account
- Is global - there is no concept of regional IAM at this time; all users, groups, policies, etc are available in all regions.
- Supports Identity Federation which can be used for Single Sign-on i.e. via SAML
- Can be used to give temporary access
IAM consists of Users, Groups Roles, and Policy Documents
Are the individual accounts.
By default, new users don’t have access to any AWS services.
Always set up MFA (Multifactor Authentication) on your root account.
IAM can be used to create and customise password rotation policies.
There are two ways to access AWS:
- Username + Password
- Access Key ID + Secret Access Key
Username and Password
- Cannot be used to interact with the API
- Can be used to sign in via a custom sign-in link which you can create via the IAM console i.e.
Access Key ID and Secret Access Key
- Assigned on user creation
- Can be used to interact via the AWS command line, SDKs, or APIs.
- Not the same as Username and Password.
- Can only be viewed once. If you lose them, they need to be regenerated. Save them in a secure location.
Are a collection of IAM users, simplifying the assigning of permissions. i.e. you can have groups for different departments such as Sales, Developers, HR, etc, which may all require different levels of AWS access.
- A user can belong to multiple groups
- Groups cannot belong to other groups
You can create roles, then assign them to AWS resources.
i.e. you might have an EC2 instance, and give it a role saying it can access S3. That way the EC2 instance can directly access S3 without having to manage usernames, passwords, etc.
Limited to 500 IAM roles under your AWS account. The acloud.guru course states up to 250.
- AWS Service
- Another AWS Account (allows entities in other accounts to perform actions in the current account)
- Web Identity (Amazon, Cognito, Facebook, Google)
- SAML / OpenID Connect
API Actions for assuming roles:
- You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.
- AssumeRoleWithSAML - for when users have been authenticated via a SAML authentication response, i.e. an on-premises VPC
- AssumeRoleWithWebIdentity (when users have been authenticated in a mobile app or web app with a web identity provider suh as Facebook, Google, or OpenID connect)
Including an IAM access policy with AssumeRole
When assuming a role, you can futher restrict access via passing an IAM access policy on each request.
If you pass a policy to this operation, the temporary security credentials that are returned by the operation have:
- the permissions that are allowed by both the access policy of the role that is being assumed
- and the policy that you pass.
… this gives you a way to further restrict the permissions for the resulting temporary security credentials.
You cannot use the passed policy to grant permissions that are in excess of those allowed by the access policy of the role that is being assumed.
An IAM policy is a document which formally defines permissions, and can be attached to users, groups, and roles.
The “ PowerUserAccess” policy provides full access to AWS services and resources, but does not allow management of users and groups.
For example, here’s one of the default AWS policy documents for assigning full access to S3:
STS (Secure Token Service)
STS is used for requesting temporary, limited-privilege credentials for AWS IAM users or for federated users which you authenticate.
The temporary security credentials are valid for the duration that you specified when calling AssumeRole, which can be from 900 seconds (15 minutes) to a maximum of 3600 seconds (1 hour). The default is 1 hour. More info
Supports the following sources:
- Federation (typically Active Directory)
- Uses SAML
- Allows you to use credentials from another provider (i.e. Active Directory) - does not need to be IAM credentials
- Does not need to be a user in IAM, or need any IAM credentials
- Federation with mobile apps
- Using Facebook/Amazon/Google or other OpenID provider to log in
- Cross-account access - allowing users from AWS account to access resources in another
To use STS Federation, you must implement the following steps in the following order:
- Develop an Identity Broker to communiate with LDAP (Lightweight Directory Access Protocol, one of the protocols that you can use to talk to Active Directory) and STS
- Identity Broker always authenticates with LDAP first, THEN with AWS STS
- Application then gets temporary access to AWS resources
Web Identity Federation
Useful for mobile apps which need to access AWS resources, and allows the app to aeceve an auth token, and then use that token for temporary credentials.
It’s strongly recommended to not embed or distribute long-term AWS credentials with apps that are user downloads to a device.
Web Identity Federation supports the following providers:
- Any other OpenID Connect (OIDC) compatible id provider