Role Can be Assumed by External Identity
Informational (4)
- Orca Best Practices
About IAM Roles in AWS
An IAM role in AWS is an identity with specific privileges and access rights. Just like an IAM user, the access policies associated with an IAM role dictate which resources it can access, and what actions it can perform. However, unlike an IAM user, a role isn’t bound to a single user; instead, it can be assumed by any user who requires it.
Roles are a great way to grant permissions to people who don’t require indefinite access to your resources. For example, you may want to grant your developers short-term access to the production servers to fix a critical bug. Or you may want users of an AWS account to access resources in another account. Roles are also the way to go when granting temporary access to third parties such as vendors, service providers, etc.
With that said, extra care must be taken when allowing external entities to assume an IAM role. It’s recommended to configure external IDs and MFA while granting cross-account access. External IDs ensure that only the right people assume a role, under the right circumstances. Moreover, only trusted external identities should be allowed to assume a role using an external ID.
Cloud Risk Description
IAM roles that can be assumed by untrusted external identities, allow unauthorized cross-account access to sensitive resources. These roles can also be assumed by malicious actors who can exploit the role’s privileges to compromise your infrastructure.
How Does Orca Help?
Orca detects and prioritizes identity and access management misconfigurations such as weak and leaked passwords, exposed credentials, and overly permissive identities. Continuous IAM monitoring across your cloud estate prevents malicious and accidental exposure. In this specific case, Orca helps by looking for “roles that can be assumed by external identities” and will alert on this type of issue as shown in the screenshot above.
Recommended Mitigation Strategies
-
Use External IDs and MFA
Always use external IDs and/or MFA while granting access to external identities.
-
Utilize Temporary Credentials
When granting access to external parties, use temporary credentials.
-
Apply the Principle of Least Privilege
Always apply the principle of least privilege while defining access policies of a role.
-
Remove Unneeded Access
Use AWS’ IAM access analyzer to identify resources and accounts that are shared with external identities. If access is no longer required, revoke immediately.
-
Enable MFA
Enable MFA for all your AWS accounts.
Useful Links
- AWS IAM introduction: https://orca.security/resources/blog/anatomy-identity-and-access-management-cyber-attack-aws/
- Using external IDs while granting access to third parties: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html
- IAM roles: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
- IAM security best practices: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
- Policies and permissions in IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
- Troubleshooting IAM roles: https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html
- Defining permissions for role assuming APIs: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_assumerole.html
- AWS IAM access analyzer: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
Orca Security, the cloud security innovation leader, provides cloud-wide, workload-deep security and compliance for AWS, Azure, and GCP - without the gaps in coverage, alert fatigue, and operational costs of agents.