AWS Identity and Access Management (IAM) Services
Your whole AWS security is there:
• Users — End Users(People)
• Groups — A collection of users under set of permissions
• Roles — Create role by users & assign them to AWS resources
• Policies — A docs which specify one or more permission.
IAM doesn’t require any region. It’s global.
Let’s see what is AWS IAM Service…
AWS Identity and Access Management (or IAM) is a service that enable you to securely manage identities, resources, and permissions at scale. AWS IAM is at the heart of AWS security because it empowers you to control access by creating users and groups, assigning specific permissions and policies to specific users, setting up multi-factor authentication for additional security, and so much more.
For applications running on AWS, you can use fine-grained access controls to grant your employees, applications, and devices the access they need to AWS services and resources.
Let’s get started!
AWS IAM — Key Features
We should think of IAM as the first step towards securing all your AWS services and resources. Let’s look at some of the key features that make IAM powerful….
1. Authentication: AWS IAM lets you create and manage identities such as users, groups, and roles, meaning you can issue and enable authentication for resources, people, services, and apps within your AWS account. In the next section, we’ll look at authentication in detail.
2. Authorisation: Access management or authorisation in IAM is made of two primary components: Policies and Permissions.
3. Fine-grained permissions: Consider this — you want to provide the sales team in your organisation access to billing information, but also need to allow the developer team full access to the EC2 service, and the marketing team access to selected S3 buckets. Using IAM, you can configure and tune these permissions as per the needs of your users.
4. Shared access to AWS accounts: Most organisations have more than one AWS account, and at times need to delegate access between them. IAM lets you do this without sharing your credentials, and more recently, AWS released ControlTower to further simplify multi-account configurations. We also published a quick, hands-on tutorial on Securing Multi-Account Access on AWS.
5. Identity Federation: Many times, your organisation will need to federate access from other identity providers such as Okta, G Suite, or Active Directory. IAM enables you to do this with a feature called Identity Federation.
Authentication in IAM
Authentication or identity management in AWS IAM consists of the following identities:
- Users: An IAM user is a person that needs to interact with your AWS resources or services either from the AWS Console or with the AWS CLI. When you create a new user, no credentials are assigned, and the user does not have any permission to access your AWS resources.
- Groups: An IAM group is a collection of users and permissions assigned to those users. Groups provide a convenient way to manage permissions for users with similar needs by categorising them according to their job function/role, department, or any other requirement. Then, permissions for all those users can be managed at once through the group.
- Roles: An IAM role is an entity within AWS which defines a set of permissions the role can perform, and what entities can assume the role. A role is not directly linked to a person or a service, rather it can be assumed by any resource that the role grants permission to. Role credentials are always temporary and rotated periodically by the AWS Session Token Service (STS).
IAM roles fulfil a unique and powerful niche in the identity and access management landscape. Instead of assigning permissions to an entity directly, roles allow an entity to be granted permissions temporarily (on an as-needed basis) to perform tasks. This enforces the least privilege principle which is based on both identity and time, as you can restrict entities to both the minimum amount of access needed as well as the minimum amount of time needed to complete a task.
Authorisation in IAM
Authorisation or access management in IAM is controlled by Policies that grant Permissions.
A. What is a Policy?
A policy is a document with a set of rules, having one or more statements. Each policy grants a specific set of permissions and can be attached to any of the IAM identities we covered earlier — users, groups, and roles. Policies are always written in JSON or YAML format and each policy has a name.
There are two types of policies you should know about:
1. Managed policies: Managed policies can be created and attached to multiple entities. AWS has built-in managed policies that cover a wide variety of use cases. Managed policies can also be mixed and matched to provide generalised access to roles, users, or groups. AWS customers can also create their own managed policies.
2. Inline policies: These policies are directly applied to IAM entities, and do not have distinctive ARNs. You use inline policies for a specific objective, which makes them non-reusable.
AWS recommends the use of managed policies instead of inline policies so that permissions are more standardised and can be reused.
B. What are Permissions?
Permissions enable you to perform actions on AWS resources. When a new user or group is created, it has no permissions and a policy must be attached to allow actions to be taken on AWS resources.
You can assign permissions to all AWS identities (users, groups, and roles). Permissions are assigned in the following two ways:
1. Identity-based: Policies attached directly to users, groups, or roles
2. Resource-based: Policies attached to AWS resources, such as S3 Buckets, ECR Repositories, and more
When writing new policies, the following resources can be helpful:
Manage IAM Permissions: This page offers quick reference to help you assign and manage IAM permission
Actions, Resources, and Condition Keys: A comprehensive reference to all possible actions that can be taken on various AWS services
AWS Policy Simulator: Validate that newly created policies work end-to-end by creating access simulations.
IAM Best Practices you should know
Before we wrap up, let’s review some of the best practices you will find useful to help secure your AWS resources:
1. Avoid the use of root account unless strictly necessary: Do not use the root account for day to day administration activities. By default, the root account user has access to all resources for all AWS services and it is best practice to create IAM users with least privilege access. Additionally, do not create access keys for the root account unless strictly necessary.
2. Use temporary credentials: Never share your credentials with anyone. It’s advisable to create individual users for anyone who has access requirements and even better use temporary credentials. You can visit our practical tutorial on Securing Multi-Account Access on AWS for detailed instructions on this.
Congratulations!! you have basic idea of AWS IAM Service.