AWS promotes the use of IAM roles over IAM users for better security practices, as IAM roles are designed to be assumable by anyone who needs them. IAM roles do not have long-term credentials like passwords or access keys and instead provide temporary security credentials for specific role sessions.
In order to enhance IAM role management, organizing IAM roles hierarchically using paths is recommended. This helps establish a clear organizational structure and allows for better navigation of complex IAM setups. It also provides precise control over permissions and reduces the risk of assigning overly permissive policies. By enforcing naming conventions for paths, role names, and policies, standardization and efficiency in IAM role management can be achieved. This practice also promotes smooth collaboration and minimizes the risk of naming conflicts.
An example of a role path is “/D1/app1/admin/DevApp1admin” where two IAM roles, DevApp1admin and DevApp2admin, are organized under different development team paths. This hierarchical model can be used to separate and categorize enterprise roles and development team roles, enabling security controls at different levels such as service control policies, IAM policies, permissions boundaries, or pipelines.
Preventative controls can be implemented based on IAM role paths. For example, an SCP can be used to deny passing a role for enterprise roles except for roles within the IAM admin hierarchy. Restrictions can also be placed on IAM actions and attaching certain high-privilege AWS managed policies. Additionally, preventative controls can prevent non-production roles from assuming a role in production accounts.
Detective controls can be implemented to monitor IAM roles. For example, a CloudTrail Lake query can be used to track AssumeRole events for non-production roles and AccessDenied errors. This helps identify unauthorized role assumptions. Another query can be used to monitor CreateRole events in specific hierarchies, such as the enterprise hierarchy, to track role creation and ensure proper authorization.
It’s important to consider several factors when implementing IAM role paths, such as the length limitations of IAM role paths and names, the necessity to include the path when switching roles through the console, and the need to use automation for setting IAM role paths during role creation.
Implementing a path strategy for IAM roles allows for the establishment of a scalable hierarchical model and the effective implementation of security controls. This approach enhances overall security posture in IAM and provides a versatile framework for managing access control in evolving environments.
