Amazon Web Services (AWS) is one of the most popular cloud computing platforms out there, providing businesses and organizations with a wide range of services to manage their digital infrastructure. One of the most critical aspects of managing your AWS environment is managing your users with IAM (Identity and Access Management).
The AWS IAM Identity Center, previously AWS SSO is a powerful tool that enables you to create and manage users, groups, and roles.
You may wonder, “Wait, but I can already do this with IAM users ?”. Yes, IAM users is the old-classic way to manage your users, it has a few limitations we will see in this article.
AWS IAM Identity Center is the tool to use to tackle this problem. Compared to standard IAM users, it brings advantages to cater to different organization sizes.
When connecting to AWS through a CLI, the general method is to use access keys. These are linked to an IAM user and can be compared to standard API keys.
Although they serve the purpose of authentication, access keys are static and do not expire, making them vulnerable to attacks. If an attacker manages to get hold of them, they can have unrestricted access to the account until the issue is noticed, potentially leading to a significant security breach. In fact, AWS warns and does not recommend using access keys due to this security risk.
To mitigate this risk, AWS offers a solution in the form of the IAM Identity Center. Access keys are generated and rotated automatically with this center every 1 to 12 hours, depending on the settings. This means that even if an attacker gains access to the credentials, they will only be valid for a short period, thus reducing the damage that can be done.
The IAM Identity Center also provides detailed logs of key usage, allowing users to monitor and identify potential security breaches. By implementing this solution, AWS users can ensure their accounts are more secure and less susceptible to attacks.
It is a good practice to separate the environments into different accounts. If you have a small infrastructure, the least you can do is separate the production environment from the nonprod environment. If your infra gets bigger, you can set up Hub and Spoke architecture.
With multiple accounts, user management with IAM users gets more complex. Either, each user has an IAM user assigned per account.
Or you may have an architecture with IAM users using federation and cross-account assumable roles.
Although these architectures can work with small organizations, they don’t scale well. As the accounts and the employees in your organization increase, the cost of maintainability and audibility increases too.
On the other side, IAM Identity Center successfully manages permissions by using permission sets. These ones are collections of permissions that can be assigned to users, groups and can be used across multiple accounts. This allows for more efficient permissions management and reduces the risk of errors or inconsistencies.
After linking users and groups with policies using permissions sets, we obtain a clear view of where it is used and by who.
For instance, you can see on this capture above that the permission set AWSAdministratorAccess is assigned to multiple accounts. This permission set has the managed policy AWSAdministratorAccess.
Another advantage of AWS IAM Identity Center is that you can easily map it to another identity provider. The supported identity protocols are SAML (Security Assertion Markup Language) and OAuth 2.0. You can therefore match most identity providers such as Azure AD, Google IDP, or Auth0.
AWS IAM Identity Center has one downside to being unable to customize the password policy. Delegating the authentication to a third party with better options allows you to solve this problem. This was useful for one of my Padok Security projects, where the infrastructure needed to be PCI DSS (Payment Card Industry Data Security Standard) compliant. AWS default password policy is not PCI DSS compliant, so we externalized the authentication to Azure AD.
Now that you are fully convinced by switching to AWS IAM Identity Center, you can create a policy restricting the IAM Users and Access Key creation. This policy can then be attached on an SCP (Service Control Policy) and therefore prevent anyone from creating IAM users.
Here is the policy you can attach to an SCP :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventIAMUserCreation",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey"
],
"Resource": [
"*"
],
"Effect": "Deny"
}
]
}Note: If you didn’t understand what was these upper lines of code, you should check another article from our blog talking about AWS Identity and Access Management.
Be careful of disabling IAM Users on the whole account before thinking of your global architecture. Indeed, there is one and only one case where IAM Users can be used: an external script that needs to have access to AWS resources without OIDC access.
When external scripts need to have access to AWS resources, always try to use authentication through an OIDC provider. For example, a GitHub action runner can authenticate through AWS through a token signed by GitHub. You can find more info in this blog article about Identity Federation between GCP and GitHub Actions.
We have explored the benefits of using IAM Identity Center, especially compared to IAM Users. While it may be possible to replicate some of the IAM Identity Center's capabilities using IAM users and unconventional methods, it is essential to consider the advantages of making the switch.
By transitioning to IAM Identity Center, you can enjoy a more streamlined and efficient approach to identity management. It offers advanced features and functionalities that can help to optimize your organization's security and overall performance.
Furthermore, making the switch can help to future-proof your systems and ensure that you are well-positioned to meet evolving security and compliance requirements. It also provides a more seamless and user-friendly experience for your employees and stakeholders.
Overall, the benefits of adopting IAM Identity Center far outweigh any potential drawbacks, and this decision can have a positive impact on your organization's security posture and bottom line.