AWS identity and access management (IAM) enables access to AWS accounts and their related cloud resources in a secure fashion. It facilitates the administration of users and groups with associated permissions to allow and deny access to services and resources. In this blog, I will discuss the basic principles of IAM identities: security in the cloud, user access, roles and policies.
Security before and after the Cloud
Before the days of the cloud, compute resources and related services would typically reside in a corporate datacenter. These resources would be secured by a firewall device ensuring unwanted traffic is not accessible to the network and only allowing accepted traffic. There would be a security officer or security administrator overseeing the implementation of security protocols for the datacenter. His or her job would rely on the active measures taken to ensure the datacenter was not breached. This was usually an unenviable post, burdened with anxiety. In this scenario, security was essentially implemented at the perimeter of the datacenter. The possibility for finer grain control was usually limited to domain specific areas where admins would need to be experts in these domains, for example database access controls etc.
In the modern cloud era, the elasticity of the cloud is a consequence of concepts like only paying for what you use and provisioning resources with API’s. These approaches allow administrators to work much faster than their predecessors. Since everything is controlled by API’s, authentication and authorization exists at every level. In AWS, all accessible resources and services are mediated by IAM. This level of security control is pervasive in the positive sense, reaching all aspects of the AWS cloud and uniform across the entire surface. It should be noted that IAM is not the only method to secure services in the AWS cloud and, in fact, there are numerous services dedicated to aspects of security but the service that all AWS users will and need to use is IAM, the fundamental security control of AWS.
IAM Identities
Once you have registered with AWS via a credit card, you will be assigned an AWS account. An account, for lackof a better word, is a container for cloud resources and services that are available to you to be deployed to facilitate your experience in the cloud. This also includes identities. Depending on your needs as an individual or organization, you may have to register multiple accounts which can be collected together in something called an AWS organization.
Multiple accounts are able to facilitate the division of environments, which in turn may promote an even more secure and robust overall ecosystem. For example, one account could be dedicated to a development environment, another to a staging environment and another to a production environment and so on. Larger organizations could have 100’s or even 1000’s of accounts all allocated to different aspects and divisions of the business managing distinct workloads, using AWS organizations to divide them up into organizational units. An organization managing multiple accounts will typically have a master account that is used exclusively for billing and the management of security controls throughout the organization.
No matter how you choose to manage your accounts, whether single or multiple, IAM identities will reside within AWS accounts and be assigned permissions to access resources. Identities can also be referred to as principals. A principal is simply someone or something in IAM that can be authenticated. Depending on the organizations existing infrastructure, there are choices available as to how the organization wants to manage identities.
If an existing user directory is available and the organization wishes to continue using it, there are a several of options:
AWS Single Sign On (SSO) with directory integrations. This allows SSO capabilities with integration to products like Azure Active Directory. The Active Directory identities can be synced into the AWS SSO service and users will use the Active Directory credentials and then the entitlements would be mapped based on users and groups into the required roles in the account.
Your own Security Assertion Markup Language (SAML) federation. This option would work best for corporate users in an Active Directory on premises or managed by AWS who are run Active Directory Federation Service. The Active Directory administrator could then map the users and groups to the required roles.
Custom federation for more advanced use cases. This option can be used for custom identity tools or third-party SaaS offerings. This will also require more granular control over user permissions as well as rules to map groups of users to AWS environments.
If the organization does not have an existing user directory, the options are:
AWS SSO user pool. AWS offers an SSO service for access to accounts. Users will be created directly in the SSO service. This is called an SSO user pool. Users authenticate via the SSO service and then get mapped to their required roles. Even if there are multiple accounts, each user will only have a single set of credentials, manage via the SSO pool.
IAM users. This is the most basic of use cases and common for when getting started with AWS and relatively small-scale accounts. Each IAM user will have long term credentials within AWS and will not be mapped to roles. IAM users will sign in directly into the console with a password or via the CLI using an access and secret key associated with their long-term account.
The takeaway here is that access to AWS is either via a user or a role but no matter what method is being used for access, it can always be considered an IAM identity in an account.
IAM Roles
As discussed in the previous section, a role is similar to a user in the sense that it is an identity with permissions determining the actions of the identity. There are, however, some key differences. A role is not associated with one user but is intended to be assumed by any user who needs it. Roles do not have any persistent, long-term credentials either. When using roles, users are in a temporary session for that role with temporary security credentials that expire once the role session terminates. Regarding security of the overall account, roles can be considered somewhat preferable.
A significant aspect of roles is that they can be assigned to applications for non-human access. Any application written for the cloud will most likely need to access other resources in the cloud. For example, an application running on an EC2 instances or a lambda function may have to access an S3 bucket. There are a multitude of compute environments on AWS and anywhere that one is supplying one’s own logic it’s almost always the case that there is some access request being made to other resources via API calls. These API calls will require authentication and authorization and subsequently an identity needs to exist for this to take place. This identity should be an IAM role.
AWS compute environments are optimized to integrate with IAM roles. Engineers or developers working with applications in the cloud accessing resources do not have to handles credentials. Resources would be associated with roles and the compute environment handles the temporary credentials, making them seamlessly available via the SDK to the application requesting access to the particular resource.
IAM Policies
In the previous sections we had a look at identities. But identities on their own are not sufficient for actions in the account. For identities to perform actions, they need associated permissions. This is controlled via IAM policies.
Policies, when associated with an identity or resource, defines their permissions and are critical in the sense that AWS uses the principle of least privilege. It’s a simple yet effective idea: give the user or process the minimal amount of permission required to get the job done. This means that any IAM identity, before it is associated with a policy, will not be able to perform any action.
On the policies section in IAM one will be presented with a list of managed policies. Each AWS service has a number of managed policies. They are a curated list of permissions created by AWS for the purposes of associating them with services or resources. These are managed policies that can be associated to job roles. For example, DatabaseAdministrator, NetworkAdministrator and AdministratorAccess. The managed policies are very useful for assigning access to human users since they include access to adjacent services. For example, the DatabaseAdministrator policy will give the user access to the relational database services as well as the associated limited access that they would require in EC2 and other related services. An example of the AdministratorAccess role is:
This role is simple, yet the most powerful. It allows all action on all resources.
An example of the DatabaseAdministrator role is:
This shows some of the resources and the related actions allowed in this role.
Managed rules with a combination set of permissions can be customised for use cases or new rules can be created with customised combinations. As previously stated, these are great for human access requiring more complex set of actions but should not be used for applications. Application code tends to do very specific things only and policies should be written to correspond to these deterministic actions.
Writing policies for applications should always use the principle of least privilege and this gets us into the realm of authorization which is a subject all on its own related to policy best practices and will be covered in an upcoming blog.
Conclusion
Security in the AWS cloud is multifaceted. Unlike the days of hardware management and corporate datacenters, it takes a more contemporary approach. Security is baked into all the offered services taking a comprehensive and holistic view of cloud native security and reliability. At the core, though, of AWS security is Identity and Access Management. I hope this blog has been somewhat useful as an introduction to IAM and as always, I encourage feedback in the comment section.
Top comments (0)