AWS Indentity and Access Management (IAM) enables you to securely control access to AWS services. As such there is no cost involved with it, yet IAM is one of the services that every single AWS solution uses and does NOT apply to a single region.
Root Account Credentials - the user account that created the AWS account is called the root account. The root account has complete access to ALL the resources on the account - makes sense. You also can’t restrict access control to the root account - makes sense because otherwise a different user could lock the root account out of the account they created!
IAM users - Authentication is the name of the game here.
Federated users - Authentication can occur via some other mechanism and be added granted access to AWS resources via a role.
Roles vs Access Keys
A role is set of permissions that can be attached to groups, users, or services. Roles are not access key credentials - they don’t give a user the ability to login to AWS - they control what the user can do or not do on AWS. Delegation of rights is a good term to think about in this case.
For example, instead of creating a username/password in an instance so it can access s3, and IAM roles can be assigned to the EC2 instance. This works for other services that you would like to communicate in AWS. IAM Roles can also be used to grant access to users from one AWS account to another or enable a mobile app to access AWS resources.
When an IAM role is assigned to a resource, the resource takes on that role. As an application of this concept, the code that runs on an EC2 instance takes on the role assigned to that instance.
An access key is used to sign requests from outside AWS. AWS SDKs and CLI use access keys. Of course, they can be disabled. Of course, they can be deleted. They can not be retrieved. Access keys do have a temporary nature to them which can be optionally assigned.
There are two types of policies: Identity policies (connected to a user, role or group) and Resource policies (attached to a service like S3). AWS has Managed policies, which are defined by AWS, and Customer Policies defined by customers. It is possible to create policies attached to a specific role, called an In-line Policy, but these are not best practice - much cleaner to write policies then attached them to an identity.
Policies contain statements and each statement matches an AWS API request. Each statement has an effect, an action, a resource, and perhaps conditions. Without a statement all API requests, by default, ALL requests to use a resource are denied - default deny. For effect, all allows override any default denies and all explicit denies override allows.
Permission Boundaries enables administration delegation and set what privileges the admin can be delegated. For instance, if you want to create a role to admin DynamoDB, first assign
AdministratorAccess to the identity then apply the
AmazonDynamoDBFullAccess policy to scope the privileges down.
Rotating keys is a big part of security…
Roles use STS to automatically get access to AWS resources and rotate credentials several times a day. From an EC2 instance you can retrieve the information from the instance meta-data.
Instance profiles are wrappers around an IAM role that will be passed to an EC2 instance. When an EC2 instance is created from the console the instance profile is created automatically; from the CLI you would need to create this and use it automatically.
Cross Account Role
To establish a cross account role access, there is a source account and a target account.
In the source account make a user group and add users to the group that need access to the target account.
In target account, create a policy that gives access to the required resources.
In target account, create cross-account access role from the source account/group name and attach the policy from step #2; copy ARN including the account name and role
In source account, create inline policy to the user group that enables
sts:AssumeRoleto the target account/role ARN