AWS Identity Federation and Least Privilege – Friends or Foes?

Learn how to address the challenges in basic and advanced implementations of AWS federation.

When it comes to achieving least privilege, Amazon Web Services (AWS) federation is a crucial step. It’s a great tool for controlling the access of users already managed in an identity provider (IdP) to resources in your AWS environment. However, it does pose challenges when you want visibility to the entitlements users have in the AWS environment, or ensure that user entitlements in AWS are not excessive - a crucial capability both for compliance with standards like HIPAA or GDPR, as well as for staying one step ahead of cyber adversaries.

In this post, we explore how federation creates challenges in both basic and advanced implementations. In addition, we will present how utilizing automated policy analysis can help bridge that gap so you can conveniently use AWS federation while also not compromising and even increasing your ability to gain visibility to entitlements and achieve least privilege in your cloud environment.

What is AWS federation?

AWS IAM federation is a feature of AWS to establish trust between AWS and an external IdP. The main purpose of federation is to use identities managed by the IdP to access AWS resources without having to set up new identities within the AWS environment (i.e. IAM users). Users who log in using an IdP-managed identity can perform a single sign-on (SSO) to the AWS environment and be entitled to a set of permissions giving them access to resources in AWS.

AWS federation leverages an AWS IAM role which makes the IdP a trusted entity. Any IdP entity that assumes the role is granted the access permissions associated with that role. When needed, the IdP requests temporary security credentials from an AWS Security Token Service (STS) which provides the required access. More information on this procedure is available in the AWS documentation.

You can set up AWS federation if your IdP is compatible with OpenID Connect or SAML 2.0.

Why is AWS IAM federation important?

Federation is a best practice for many reasons; first of all, it makes it much easier for system admins to manage identities and entitlements. Instead of managing more entities – that is, a new IAM user for each user – on top of the already existing ones in the IdP, users are managed in a single location. Information about users from the IdP (for example, assignment to groups / roles and other attributes) could also be used to establish access policies. This doesn’t only save time, but also helps avoid configuration mistakes which could result in security vulnerabilities. Additionally, you provide human users a far better access experience with an SSO log-in mechanism, which removes the need for more passwords (also a security benefit).

So… What seems to be the problem?

So far so good, right? Using AWS IAM federation should be a natural step on the journey to least privilege access in an AWS cloud environment and obtaining full AWS cloud security.

Unfortunately, we’re only getting started. As entitlements in AWS are highly complicated to manage and business operations usually trump security best practices (if they are even considered), excessive, sometimes absolute permissions to resources are not uncommon in many AWS environments. In addition, permissions are usually quick to be granted as needed, but are not so quickly taken away when no longer necessary. This kind of privilege accumulation might cause a security audit failure, or worst yet a security breach.

For this reason, constantly reviewing entitlements and making sure they are not excessive is vital to achieving and maintaining least privilege. Unfortunately, AWS IAM federation makes this important task both more significant and more difficult. Let’s see why.

When utilizing AWS IAM federation, the roles defined to allow federated users access to AWS resources are a classic single point of failure (SPOF). Excessive permissions assigned to a single role would mean excessive permissions to all users who have assumed that role for access to your cloud resources. This means that if any of these users are compromised (e.g. - their password / endpoint is controlled by a malicious actor), then these excessive permissions would be available to the threat. If role chaining is involved (i.e. the role used for federation is allowed to assume another role or roles), then the problem becomes exponentially more complex.

In addition, the way federation is used makes it prone to privilege accumulation. First of all, since many users use the same role to access resources, the easiest thing to do (which unfortunately is usually the route taken) is to simply grant as many permissions as possible to this shared role. But even if the original design is perfect, mistakes still happen along the way.

Let’s say that during the workday, one user finds out he needs access to additional resources in the cloud environment, or needs the ability to perform additional actions on resources he already has access to. When he contacts the person managing policy permissions for AWS resources, that person decides the request is legitimate for that specific user but not for other users who can use the same role. The reasonable thing to do would be to grant the additional access to that specific user via a new role that would be assigned to that user and that user alone.

However, federation is usually done based on groups within the IdP, so an event like this might mean that in order to fulfill this need correctly, the system admin might need to rethink the entire permissions model. There are ways to address these kinds of issues elegantly (which we will address in future articles), but they may require some effort from the system admin. Unfortunately, it’s more likely for a system admin to simply add the necessary privileges to the role assumed by all those users to access AWS resources (thus granting these privileges to all the users) and provide the availability required for the business to keep running.

It’s also important to remember that since, by design, the IdP is a source of truth for granting permissions, mistakes or neglect in the management of the IdP could easily translate to excessive permissions to AWS resources. When managing users in an IdP, it’s common to simply assign a user to a group in the IdP to which he doesn’t belong, or forget to remove the user from such a group when he transfers to a new position. Both of these cases could result in that user being granted or keeping privileges he or she shouldn’t have.

The Complicated matter of an audit

For the reasons above, using AWS federation makes the rightsizing of permissions more significant. However, as mentioned, it also makes it more difficult to achieve least privilege. First of all, to simply gain visibility and figure out which users can access what resources, you have to combine information from AWS (the permissions policy of the role used for federation) with information from the IdP (the knowledge of which user is assigned which roles).

Additionally, it is extremely difficult to achieve least privilege using out-of-the-box tools from your AWS environment such as policy simulator and access advisor to understand access entitlements. Unfortunately, when utilizing AWS federation, these tools become even less useful. Since they apply to IAM users or roles, the best they can do when utilizing AWS federation is to analyze the usage of the role being used for federation as a whole, not the specific activity of each federated user. The only way to know the actual permissions each user requires by auditing his or her usage of these permissions is to analyze logs from CloudTrail. This is nearly impossible to do manually.

Finally, it’s important to point out that manually auditing user activity becomes more difficult as well; even the basic auditing abilities we normally get from logs such as being able to associate events with specific users is not straightforward when AWS federation is involved. There’s a special procedure which enables a unique value for the “RoleSessionName” attribute for each federated user logged in AWS’s CloudTrail. Doing this allows you to identify the user in the event record where the IdP requests temporary security credentials (labeled “AssumeRoleWithSAML”), and allows you to associate future events with the same user. More details about this procedure can be found on the AWS Security Blog. Even with this configuration set up properly, it is still quite challenging to review the logs and deduce actionable insights.

Automated analysis to the rescue

Fortunately, to obtain valuable insights and implement the policies that you need, automated tools which do the heavy (and sometimes impossible) lifting for you are available. Let’s take a look at how Tenable Cloud Security can help you achieve least privilege while utilizing AWS federation.

First of all, Tenable visualizes the permissions assigned to the role assumed by federated users, so you can review it in a convenient way. It clearly marks which permissions are excessive and from which policy they originate. This assessment is done both based on advanced logic defined by security experts and actively monitoring the activity of users in your environment. This way, you have everything you need to reconfigure policies and reduce assigned permissions in order to achieve least privilege. Applying this practice to roles, which a large number of users assume to gain AWS access, could make a meaningful difference in terms of security.

Graphical view: Federated users group (on the left) can access the “OktaUsers” role (second from the left) which can in turn use multiple policies which provide it with access to multiple cloud resources.

If a particular access policy is interesting, zoom in on that policy to see which resources it allows the role to access, and which access permissions are excessive. For more information on the permissions the policy provides the attached role for a specific AWS service, select it to see more. For example, here we show the permissions the “SecurityAudit” policy provides to the RDS clusters in our environment.

The permissions for the RDS Clusters provided by the “SecurityAudit” Policy.

As some users might have the ability to assume more than one role, view the user to examine the accumulation of permissions it has. For example, in the following figure, we can see Michal is assigned to two roles and we can also view the total permission set she has because of this configuration:

The user Michal F is assigned to two roles (“OktaUsers” and “OktaUsers2”, marked in red boxes) and can thus access the accumulated permission set from both.

Tenable also enables you to audit activity on the user level, the same way its logic does: with a log specifying which user performed which action.

The Tenable Cloud Security activity log allows viewing the specific activity of Michal F as a federated user.

Tenable Cloud Security audits the activity of each user separately in order to understand the effective permissions for each user, rather than for the role in general. This means that the excessive permissions analysis presented in Figure 3 for each user is unique to each user based on their specific activity. It could vary between different users even if they assume the exact same role. This could enable you to make a significant leap towards least privilege and ensure that each user has the specific permissions set they need.

In the mood for more?

In our next post, we will take AWS federation to the next level and demonstrate how to use attributes pre-configured in your IdP to dynamically grant or revoke access to AWS resources with attribute-based access control (ABAC).

Very similarly to what we’ve demonstrated in this post, this is both an important management tool to achieve least privilege, and at the same time, an obstacle. Tenable can help you mitigate this.