Let’s talk about AWS Identity and Access Management (IAM). You may ask, isn’t this something that needs to be talked about at the beginning? Well, IAM is one of the most important core services which supports AWS security. It is not just an authentication and authorization engine, it serves and interacts with almost all the services AWS provides concerning access control. So, exploring a few topics is necessary before we understand IAM.
One can read IAM as an Authentication and Authorization management system. It is a global AWS service, meaning it is not specific to any region. Along with IAM, STS (Security Token Service) is global as well and we will touch upon the same in a post in future.
AWS is an IAAS platform, where customers and their users log in to provision infrastructure on the cloud and perform certain actions. All these tasks are done via requests, to be specific these requests may originate from the web console, APIs, SDKs, or CLIs. Every request made to AWS is first interpreted by IAM.
There are certain terms that AWS uses to identify users, applications, resources, etc., which may cause confusion. Below are certain terms you need to be well aware of. At a very high level they sound the same, but knowing the difference helps a lot while going through AWS documentation.
- Resources – think of resources as everything that IAM uses or deals with to perform its functions. Users, roles, groups, policies, and federated user objects are resources of IAM.
- Identities – resources used for identification purposes are termed as identities in IAM. Users, roles, and groups are identities. Policies can be associated with identities.
- Entities – resources used for authentication purposes are termed as entities in IAM. Usually, these are user objects within IAM.
- Principals – Any person or application trying to use the credentials to access AWS services is termed as principals.
A request is made by principals to AWS platform. This request has a context defined by resource, action. Here, a resource means any object belonging to AWS service on which actions are requested to be performed. Actions also define what kind of action it wants to perform on the resource. This request context is identified by IAM as the very first step.
Before evaluating the access, IAM uses the identity of the requestor to authenticate the attempt. Authentication happens based on what kind of credentials they use. A user may use a username and password for access via the web console, access and secret for CLI and SDK based (programmatic) access, or token-based access in case of federated users.
Once authenticated, the authorization framework evaluates the resource and action of the request against the related policies. Policies help define granular access control on the resources. By default, it denies all requests made to AWS resources. Explicit permission to allow the action needs to exist before the action can be performed. If there are multiple policies defined, then all of them should allow the action. If there is a single policy denying the access, the access is denied altogether.
Policies are stored in JSON format and can be associated with users, groups, resources, roles, and applications. AWS provides certain set policies that are predefined and can be used to associate. However, custom policies can be created to define access rules as per the needs of the organization.
The creation of policies can become cumbersome when they are not managed. Thus, various approaches are described to create policies that make it easier to maintain them. Identity-based policies are created keeping identities in focus, while resource-based policies can also be created. As you can imagine, there are quite a few angles for consideration in this area.
When you create a new account on AWS by using your email id, you become the root user of that account. Root users have full privileges on their AWS account. They are allowed to perform any action. As a best practice, it is always suggested that you use this user to create other IAM users and use one of the IAM uses to perform day-to-day activities. This is because with power comes responsibilities and considering the scope of human error, things can go wrong in unexpected ways.
Apart from root user and IAM users, applications can also perform actions on AWS requests. IAM users are also created for applications to generate access keys for their programmatic access. Generally, organizations have their corporate user directory which they use internally for user authentication. If the directory supports SAML 2.0, federated authentication can be achieved using SSO. IAM also supports web identity federation.
AWS supports policy management using their managed service – AWS Organizations. As far as you are working in a single AWS account, it should be fairly easy to manage policies. Policies can be associated with users directly or they can be associated with a role or a group. When a role is assigned to the user, or when a user is added to a group, all the policies associated with the role and group are now applicable to the user.
Federated users are not permanent users on AWS. They access AWS accounts temporarily. So which role do they assume is a question. In this case, a generic role can be defined with appropriate policies. Whenever a federated user logs in to AWS, this role can be associated with them to define access based on their source.
As discussed earlier, there are 2 approaches to define policies. Identity-based policies are associated with identities like user, group, roles which define what actions a user can perform and on which resources. Looking from the user’s perspective, we know what is blocked and what is allowed. However, only looking at the policy settings on a specific resource, we may not know who all have access to it.
Resource-based policies are defined as keeping resources in focus. Policies are defined for and associated with the resource. These policies define the terms a user should satisfy to perform a certain action on that specific resource. Identity-based and resource-based policies are not mutually exclusive. The resulting access is usually the overlap of the policies on both sides.
Access controls can also be defined using attributes, known as Attribute-Based Access Controls (ABAC). AWS resources make use of tags. Quite often, organizations rely on these tags to classify their resources. For example, several projects being executed can have their project name or project code as part of a tagging convention for the cloud infrastructure they own. Tags have also been used to analyze billing reports.
Thus, using tags to define access control is a good idea. It offers several advantages like – requiring a fewer number of policies and can be maintained at the granular level. Tags can be mapped to federated users, thus assigning them roles based on the attributes their identity carries eases the decision-making process of granting access.
IAM plays a huge role when it comes to AWS security. AWS security is a shared responsibility model where AWS is responsible security of the cloud and customers are responsible for security in the cloud. IAM is one of the security pillars customers rely on for security in the cloud. IAM enables MFA for users, encryption for the data at rest, and usage of highly secure protocols for data in transit.
AWS IAM provides a service named Access Analyzer. It helps us identify an analyzer that scans through the policies and identifies any unintended access. This helps us keep a tab on any active findings identified by the analyzer. Findings by the analyzer can be used to decide whether the access needs to be revoked or it is intentional access.