An AWS Identity and Access Management (IAM) role is an IAM identity that you create in your AWS account that has specific permissions. An IAM role is similar to an IAM user because it’s an AWS identity with permission policies that determine what the identity can and cannot do on AWS. However, as outlined in security best practices in IAM, AWS recommends that you use IAM roles instead of IAM users. An IAM user is uniquely associated with one person, while a role is intended to be assumable by anyone who needs it. An IAM role doesn’t have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session that are only valid for certain period of time.

   <p>This blog post explores the effective implementation of security controls within IAM roles, placing a specific focus on the IAM role’s <a href="https://aws.amazon.com/blogs/security/optimize-aws-administration-with-iam-paths/" target="_blank" rel="noopener">path feature</a>. By organizing IAM roles hierarchically using paths, you can address key challenges and achieve practical solutions to enhance IAM role management.</p> 
   <h2>Benefits of using IAM paths</h2> 
   <p>A fundamental benefit of using paths is the establishment of a clear and organized organizational structure. By using paths, you can handle diverse use cases while creating a well-defined framework for organizing roles on AWS. This organizational clarity can help you navigate complex IAM setups and establish a cohesive structure that’s aligned with your organizational needs.</p> 
   <p>Furthermore, by enforcing a specific structure, you can gain precise control over the scope of permissions assigned to roles, helping to reduce the risk of accidental assignment of overly permissive policies. By assisting in preventing inadvertent policy misconfigurations and assisting in coordinating permissions with the planned organizational structure, this proactive solution improves security. This approach is highly effective when you consistently apply established naming conventions to paths, role names, and policies. Enforcing a uniform approach to role naming enhances the standardization and efficiency of IAM role management. This practice fosters smooth collaboration and reduces the risk of naming conflicts.</p> 
   <h2>Path example</h2> 
   <p>In IAM, a role path is a way to organize and group IAM roles within your AWS account. You specify the role path as part of the role’s Amazon Resource Name (ARN).</p> 
   <p>As an example, imagine that you have a group of IAM roles related to development teams, and you want to organize them under a path. You might structure it like this:</p> 
   <p>Role name: Dev App1 admin<br>Role path: <span>/D1/app1/admin/</span><br>Full ARN: <span>arn:aws:iam::123456789012:role/D1/app1/admin/DevApp1admin</span></p> 
   <p>Role name: Dev App2 admin<br>Role path: <span>/D2/app2/admin/</span><br>Full ARN: <span>arn:aws:iam::123456789012:role/D2/app2/admin/DevApp2admin</span></p> 
   <p>In this example, the IAM roles DevApp1admin and DevApp2admin are organized under two different development team paths: D1/app1/admin and D2/app2/admin, respectively. The role path provides a way to group roles logically, making it simpler to manage and understand their purpose within the context of your organization.</p> 
   <h2>Solution overview</h2> 
   <div id="attachment_33310" class="wp-caption aligncenter"> 
    <img aria-describedby="caption-attachment-33310" src="https://infracom.com.sg/wp-content/uploads/2024/02/img1_v2.png" alt="Figure 1: Sample architecture" width="846" height="589" class="size-full wp-image-33310"> 
    <p id="caption-attachment-33310" class="wp-caption-text">Figure 1: Sample architecture</p> 
   </div> 
   <p>The sample architecture in Figure 1 shows how you can separate and categorize the enterprise roles and development team roles into a hierarchy model by using a path in an IAM role. Using this hierarchy model, you can enable several security controls at the level of the <a href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html" target="_blank" rel="noopener">service control policy (SCP)</a>, IAM policy, permissions boundary, or the pipeline. I recommend that you avoid incorporating business unit names in paths because they could change over time.</p> 
   <p>Here is what the IAM role path looks like as an ARN:</p> 
   <div class="hide-language"> 
    <pre class="unlimited-height-code"><code>arn:aws:iam::123456789012:role/EnT/iam/adm/IAMAdmin</code></pre> 
   </div> 
   <p>In this example, in the resource name, <span>/EnT/iam/adm/</span> is the role path, and <span>IAMAdmin</span> is the role name.</p> 
   <p>You can now use the role path as part of a policy, such as the following:</p> 
   <div class="hide-language"> 
    <pre class="unlimited-height-code"><code>arn:aws:iam::123456789012:role/EnT/iam/adm/*</code></pre> 
   </div> 
   <p>In this example, in the resource name, <span>/EnT/iam/adm/</span> is the role path, and <span>*</span> indicates any IAM role inside this path.</p> 
   <h2>Walkthrough of examples for preventative controls</h2> 
   <p>Now let’s walk through some example use cases and SCPs for a preventative control that you can use based on the path of an IAM role.</p> 
   <h3>PassRole preventative control example</h3> 
   <p>The following SCP denies <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html" target="_blank" rel="noopener">passing a role</a> for enterprise roles, except for roles that are part of the IAM admin hierarchy within the overall enterprise hierarchy.</p> 
   <div class="hide-language"> 
    <pre class="unlimited-height-code"><code class="lang-text">     {
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyEnTPassRole",
        "Effect": "Deny",
        "Action": "iam:PassRole",
        "Resource": "<span>arn:aws:iam::*:role/EnT/*</span>",
        "Condition": {
            <span>"ArnNotLike": {</span>
                <span>"aws:PrincipalArn": "arn:aws:iam::*:role/EnT/fed/iam/*"</span>
            }
        }
    }
]

}

   With just a couple of statements in the SCP, this preventative control helps provide protection to your high-privilege roles for enterprise roles, regardless of the role’s name or current status.</p> 
   <p>This example uses the following paths:</p> 
   <ul> 
    <li><span>/EnT/</span> — enterprise roles (roles owned by the central teams, such as cloud center of excellence, central security, and networking teams)</li> 
    <li><span>/fed/</span> — federated roles, which have interactive access</li> 
    <li><span>/iam/</span> — roles that are allowed to perform IAM actions, such as CreateRole, AttachPolicy, or DeleteRole</li> 
   </ul> 
   <h3>IAM actions preventative control example</h3> 
   <p>The following SCP restricts IAM actions, including CreateRole, DeleteRole, AttachRolePolicy, and DetachRolePolicy, on the enterprise path.</p> 
   <div class="hide-language"> 
    <pre class="unlimited-height-code"><code class="lang-text">{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyIAMActionsonEnTRoles",
        "Effect": "Deny",
        "Action": [
            "iam:CreateRole",
            "iam:DeleteRole",
            "iam:DetachRolePolicy",
            "iam:AttachRolePolicy"
        ],
        "Resource": "<span>arn:aws:iam::<em>:role/EnT/</em></span>",
        "Condition": {
            "ArnNotLike": {
                <span>"aws:PrincipalArn": "arn:aws:iam::<em>:role/EnT/fed/iam/</em>"</span>
            }
        }
    }
]

}