IAM controls access to AWS services via policies that can be attached to users, groups, and roles. Users are given long-term credentials to access AWS resources (username and password or access keys).
Roles allow for short-term access to resources when assumed, using temporary access credentials.
IAM Users
Root User
• The user created when an AWS account is created.
• The credentials are the email and password used when signing up for an AWS account. By default, the root user has full administrative rights and access to every part of the account.
Best Practices for Root User:
• The root user should not be used for dailywork and administration:
• Another user should be created for daily work that has admin rights.
• The root user account should not have access keys; delete them if they exist.
• The root user should always use multi-factor authentication (MFA), like Google Authenticator.
IAM Users
• A new user has an implicit deny for all AWS services, requiring a policy be added to grant them access.
• Users receive unique credentials (username, password, and possibly access keys).
• Users can have IAM policies applied directly to them, or they can be a member of a group that has policies attached.
• With policies, an explicit deny always overrides an explicit allow from attached policies: For instance, all policies attached to a user will be ignored if a single deny-all policy is added.
Best Practices for Users:
- Require MFA for root level access.
- Do not share root credentials with anyone other than the accoount holder.
- Physicaly secure root account hardware MFA devices in the safe place, such as a vault.
- Create indyvidual IAM users.
- Use groups to assign permissions to IAM users.
- Enable MFA for provileged users.
- Use IAM rroles for application that run on Amazon EC2 instances.
- Delegate by using IAM roles instead of sharing credentials.
- Rotate credentials regulary.
- Remove unnecessary crredentials.
- Use policy conditions for extra security.
- Monitor activity on your AWS account.
- Remove root credentials.
- Use access levels to review IAM permissions.
- Use AWS definied pollicies to assign permission whenever posiible.
- Use IAM rolres to provide cross-account access.
- Never store or “pass” your access credentials to an EC2 instance — use SSH forwarding.
- MFA can and should be used for user accounts.
IAM Groups
• Allow for policy assignments to multiple users at the same time
• Permissions may be assigned to group
• More organized and efficient way to manage users and policies
• Cannot be nested
• Users may be a member of multiple groups
Best Practices for IAM Groups
• Organize users by function (e.g., DB admins, developers, architects, etc.)
• Assign IAM policies to groups, not individual users
IAM Access Keys
Access keys are a pair of values used by applications, SDKs, or the AWS command line to authenticate to AWS.
Access keys consist of two parts:
- Access Key ID
- Secret access key
The access key ID is the public part of the key and is stored by AWS once generated.
Access Key ID AKIAIOSFODNN7EXAMPLE
The secret access key is the sensitive and private part of the access key, available only once when the access key is initially generated. It’s stored only by the owner and should never be revealed.
Secret Access Key WalrXUtnFEMI/K7MDENG/OPKRfiCYEXAMPLEKEY
An IAM user is the only identity that uses access keys. They are allowed two sets. They can be created, deleted, enabled, and disabled.
They can’t be used to log in to the console, and they don’t expire. If anyone finds a set of access keys, they have access to the permissions of the IAM user to which they belong.
The access key is active by default. Each user can have two active keys. Deleted access key is removed and cannot be retrieved.
A best practice:
- Rotate access keys regulary for all of the IAM users in AWS account.
- The root user access keys should not be used. Recommended practice is to delete the root user access keys.
The IAM access keys can be placed in:
Linux: ~/.aws/credentials file
Windows: \%USERPROFILE%\.awscrredentials
IAM Policies
• A document that states one or more permissions (JSON formatted).
• An explicit deny always overrides an explicit allow.
• This allows for the use of a deny-all policy to quickly restrict all access a user may have.
An IAM policy consists of four main elements:
- Action
- Effect
- Resource
- Conditions (optional)
A least privilege approach should be used when assigning permissions.
Managed Policies
- AWS Managed policies
• Created and managed by AWS
• AWS provides pre-built policy templates to assign to users and groups. Examples include:
– Administrator access: Full access to on AWS resources
– Power user access: Admin access except it does not allow user/group management
– Read-only access: Only view AWS resources (e.g., user can only view what is in an S3 bucket)
- Customer managed policies
• Policy that you create and can attach to principals in your AWS account.
• Provides several features: reusability, central change management, versioning and rollback, ability to delegate permission management to the other users.
• You can also create custom IAM permission policies using the policy generator or write them from scratch.
• More than one policy can be attached to a user or group at the same time.
• Policies cannot be directly attached to AWS resources (such as an EC2 instance).
Inline policies
Embeded in a principal entity such as a user, group or role. Inherent part of the entity. The Same policy can be used for multiple entities, but those entities do not share the policy. Instead each policy has its own copy of the policy (inline policy cannot be centraly managed).
IAM Roles
• Temporary security credentials in AWS managed by Secure Token Service (STS).
• Another entity can assume the specific permissions defined by the role.
• These entities include:
– AWS resources (such as an EC2 instance)
– A user outside of our AWS account who needs temporary access
IAM roles consists of:
- Access key ID
- Secret access key
- Token
- Duration
Roles with AWS Services
• Roles must be used because policies cannot be directly attached to AWS services.
• Services can only have one role attached at a time.
• You should never pass or store credentials to an EC2 instance — instead, use roles.
• Example:
– An EC2 instance needs to be able to read data from an S3 bucket: The instance assumes a role with S3 read-only permissions from IAM. The instance can then read objects from the bucket specified in the role’s policies. You may change roles on running EC2 instances through the console and CLI.
Other Uses of Roles
• Cross-Account Access (Delegation):
– Provide access to another AWS user from another account.
• Identity Federation:
– Users outside AWS can assume a role for temporary access to AWS accounts and resources.
– These users assume an identity provider access role.
– Example identity providers: Active Directory, Single sign-on providers (like Facebook, Google, Amazon, etc).
Role switching is a method of accessing one account from another using only one set of credentials. It is used both within AWS Organizations and between two unconnected accounts.
1. A role in Account B trusts Account A.
2. An identity in Account A can assume the role in Account B…
3….and, using that role, it can operate inside Account B.
Permission boundaries
When you attach a policy to a principal to grant that principal access, the policy is called a permissions policy. You can also use a policy to define permissions boundaries, which let you limit the maximum permissons an IAM principal can be assigned.
For example you may create the following policy that allows all actions for the EC2 service and than attach that policy to an IAM useer as a permissions boundary:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*" ], "Resource": "*" } ] } |
If you then attach to the user the AdministratorAccess policy – which grant full access to all AWS services – the user will still only be able to perform actions in EC2.
IAM Multi-Factor Authentication (MFA)
• A security method that requires multiple separate authentications.
• One authentication option we have with AWS uses time-based codes.
• Familiar example of MFA: You go to an ATM to withdraw money from your bank account. This requires both the physical card and a PIN. This example uses two-factor authentication, which is a form of MFA.
AWS Scenario
- Enable MFA in order to access the AWS console:
• Users type in their username and password as well as a time-based code:
• The username and password are not enough to be authenticated.
• The time-based code can be on the user’s computer, smartphone, or a device they carry around.
- This should be turned on for users who have access to the console.
- MFA Delete for S3 objects can be used to mitigate accidental deletions.
IAM service supports the following MFA types:
- Hardware devices (Gemalto)
- Virtual MFA applications (such as Google Authenticator)
- SMS via mobile devices
Secure Token Service (STS)
STS is an extension of IAM that allows for management of temporary security credentials for IAM users or federated users.
- It allows for granular control of how long the access remains active
– Fifteen minutes to one hour (default = 1 hour)
- Credentials are not stored with the user or service granted temporary access A token is attached to the access request or API call
- Beneficial in a number of ways
– Low risk of credentials being exposed (not distributed)
– Do not have to create IAM identities for every user – Because they are temporary in nature, there is no need to rotate keys - STS uses a single endpoint: https://sts.amazonaws.com – This single endpoint resides in us-east-1 (N. Virginia) – Latency can be reduced by using STS API calls to regions that support them – Temporary credentials have global scope, just like IAM
Identity Federation
Federation: Providing a non-AWS user temporary AWS access by linking that user’s identity across multiple identity systems
Federation with Third-Party Providers:
- Most commonly used in web and mobile applications
- Amazon Cognito allows for creation of unique identities for users
- Uses identity providers to federate them Facebook, Google, Amazon, etc.
Establishing Single Sign-On (SSO) Using SAML 2.0:
- Most commonly used in enterprise environments with an existing directory system Active Directory, etc.
- Federated users can access AWS resources using their corporate domain accounts
- Federation also aids user management by allowing central management of accounts