You get a role, you get a role, everyone gets a role! IAM roles are the cornerstone of a strong Identity and Access Management (IAM) strategy, facilitating the interaction between identities and cloud resources, ensuring streamlined operations, and, most importantly, strengthening security.
Managing IAM roles for internal users and workloads is relatively simple. But what happens when external providers need access to your AWS resources? Only 41% of organizations have implemented zero trust controls in their cloud infrastructure, showing that companies may be giving access to their IAM roles way too freely.
AWS realized this problem and released a new service called IAM Roles Anywhere, designed to create a more secure approach for workloads outside AWS to access AWS resources. This article will look at AWS IAM Roles Anywhere and cover the most critical pitfalls you must avoid to use it effectively.
AWS IAM Roles Anywhere Explained
With the native IAM service in AWS, administrators tend to create long-term credentials associated with IAM roles for accessing AWS resources. All attackers need to do is get hold of these credentials to gain unauthorized access into your system and steal files, compromise accounts, or delete information - none of which are ideal for any business.
Auditing and rotating credentials are easy steps to prevent such security breaches. Still, the growing number of entities accessing your resources from external environments can quickly become an operational overhead and sabotage your Cloud Identity Management strategy.
AWS IAM Roles Anywhere allows external entities (such as servers, containers, and remote applications) running outside AWS to access AWS resources without using the default, long-term credentials generated for IAM roles. Instead, the AWS account administrator provides them with temporary, short-lived digital certificates to enter the IAM roles containing the permissions to access the necessary resources.
This feature offers a more secure integration between AWS resources and workloads running in on-premise data centers or other cloud providers. Given this extension of trust between AWS and non-AWS workloads, there is a need to pay more attention to possible lapses.
How AWS IAM Roles Anywhere Works
AWS IAM Roles Anywhere extends the core capabilities of IAM in three ways:
Establishing a trust anchor with another Certificate Authority (CA): AWS IAM Roles Anywhere interfaces with a third-party CA to set a trust anchor (a reference to the AWS Private Certificate Authority or an external CA certificate).
Creating Temporary Credentials: AWS IAM Roles Anywhere works with the trusted CA to generate temporary credentials in the form of X.509 digital certificates. These are attached to existing IAM Roles and include a compulsory expiration timestamp, so they are never long-lived.
Creating Profiles: Profiles are used in AWS IAM Roles Anywhere to aggregate a list of IAM roles that the IAM Roles Anywhere service is trusted to assume.
To better understand the impact of this tool on AWS security, let's consider a before and after scenario for an application running on a remote server, which needs to access the AWS S3 service to create periodic backups for some data.
Before using AWS IAM Roles Anywhere, this remote application would require access and secret keys associated with an IAM user and role that allows write access to a particular S3 bucket. These keys are stored in plain text in the remote server's filesystem. They are permanent and always active even when the application is not performing the backup. If the remote server is compromised, a data breach from S3 is a legitimate threat.
Using AWS IAM Roles Anywhere, the remote application generates a temporary X.509 digital certificate for a session associated with the same IAM role for accessing the S3 bucket. However, in this case, the access is granted only for a limited time, ranging from a few minutes to a few hours. This configuration ensures that access to the S3 bucket is available to a temporary credential for a limited time.
AWS IAM Roles Anywhere: Seven Things to Avoid
1. Using Default IAM Policies
AWS has a ton of default policies, pre-generated for all the services. These cover various use cases for preconceived user profiles such as administrator and power user. While these policies offer a great starting point, they are not specific to individual AWS resource instances. Therefore, they should not be used, especially when IAM Roles Anywhere is involved. Make sure you customize all your policies to ensure that your external users can access what they need to access and nothing else.
2. Neglecting Policy Reviews
AWS IAM Roles Anywhere helps you provide safer access to IAM roles but doesn’t help you create the associated policies. AWS IAM policies are generally complicated: they’re written in JSON format, so even a minor syntax error, such as a missing comma, can invalidate them.
Their complexity often makes them a frequent source of human mistakes and malpractice. For instance, engineers often use wildcards (*) in the policy definition to grant broad-level access to AWS resources, which is the equivalent of putting a band-aid on a bullet wound. Sooner or later, you must deal with the effects of not treating the injury properly. In the case of IAM, broad-level access opens doors for attackers to get into your system.
You can use the AWS Policy Simulator to validate your policies and ensure that they meet the access needs of your users. But you wouldn’t have to focus so much on the reviewing process if you could create robust and secure policies from the get-go. Slauth lets you minimize reviewing efforts by tracking your identities’ activity (real-time API calls from end-to-end tests to AWS) and ensuring that the policy definitions match their access needs and follow the least privilege principle.
3. Not Using a Real CA from a Well-configured PKI
A real CA with an established trust chain is mandatory for any production-grade application and a key IAM best practice. This kind of CA is available as part of an enterprise PKI service with a certificate chain linked to a well-known root CA. Neglecting this advice may mean relying on a self-signed CA or a free public CA service. A self-signed CA can lead to potential security issues if its private key is compromised and used to issue fraudulent certificates. Similarly, using a free CA service is risky since anyone can get a certificate issued by that CA and authenticate to IAM Roles Anywhere.
4. Neglecting IAM Logging and Monitoring
It’s all too easy to sit back and relax once you have deployed your IAM roles and policies, but you have to play the long game with IAM, even if using short-term credentials from AWS IAM Roles Anywhere. Enter the next step of your journey: continuous monitoring. You need complete visibility over your user activity to understand what identities are accessing what resources, spot any unusual behavior, and close access gaps promptly.
Slauth provides a 360º overview of all your machine identities’ activity in AWS through logs placed across your SDLC. This makes it easier to review unusual activity, such as IAM access changes, and respond quickly to avoid full-scale security breaches. Logging is also critical to prove compliance with regulations such as SOC2, PCI, and HIPAA. For example, you may need to prove that you store data safely or that data doesn’t travel across borders. Even if leveraging edge computing, which encrypts data before transmission and stores it locally, you should use existing logs to review, collect, and share evidence of regulatory compliance.
5.Unrestricted External Access
External access to AWS resources is often granted as a single IAM role with generic permissions. However, external identities need different permissions at different times depending on the application development phase. Considering the cloud environment is vital since production and non-production environments have unique access requirements for developers and testers.
Make sure you segregate the permissions for each environment to minimize the risk of accidental changes or data breaches. You can use profiles within AWS IAM Roles Anywhere to specify which IAM roles can be assumed by environment-specific workloads outside AWS.
6. Unnecessary Trust Relationships
AWS IAM Roles Anywhere relies on an established trust anchor with a CA for authenticating temporary credentials generated through that CA. This association forms a trust relationship that is part of the AWS configuration. Using multiple trust anchors is good practice to ensure reliability. However, you must ensure that trust relationships are configured correctly to avoid violating the separation of duties and the least privilege approach. As part of this separation, having a limited number of such trust anchors based on cloud environments is also advisable.
7. Avoiding the Quotas
Finally, it is crucial to keep track of the AWS service quotas. Like all AWS services, AWS IAM Roles Anywhere, too, is bound by certain limits. These limits can often reach their ceiling values and cause unexpected behavior.
For example, there is a fixed limit of ten CreateSession requests per second, meaning there can be a maximum of ten requests every second to generate temporary credentials. While this limit is modest for most workloads requiring access to AWS resources, scaling up the workloads can exceed this limit and cause application-level malfunction.
Hacking the AWS IAM Arsenal
With IAM Roles Anywhere, AWS added yet another weapon to its already extensive arsenal of security-focused services. But as your cloud deployment gets more complex, your visibility of impending threats gets cloudier. As we have seen earlier, this can become an overhead with an extensive hybrid or multi-cloud workload spanning hundreds or thousands of external entities.
Slauth helps you demystify the IAM clutter by creating IAM policies based on the actual access needs of machine identities, avoiding the operational frenzy of constantly updating access controls (IT Helpdesk, we see you!) while ensuring zero-trust security. You also get automated real-time analytics, versioning, and auditing of provisioned IAM policies to enable holistic access management for large and complex AWS workloads. Explore more here.