{"id":5691,"date":"2023-03-31T12:00:15","date_gmt":"2023-03-31T10:00:15","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5691"},"modified":"2023-03-31T15:07:52","modified_gmt":"2023-03-31T13:07:52","slug":"iam-policies-and-service-control-policies-scps-how-to-master-and-secure-access-and-permissions-in-an-aws-landing-zone","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/iam-policies-and-service-control-policies-scps-how-to-master-and-secure-access-and-permissions-in-an-aws-landing-zone\/","title":{"rendered":"IAM policies and Service Control Policies (SCPs): How to master and secure access and permissions in an AWS Landing Zone"},"content":{"rendered":"\n

Today we are proud to welcome a special guest post<\/em>: straight from<\/em> the IAM- focused Noovolari Leapp’s blog<\/a>, Nicol\u00f2 Marchesi – Nico for friends \ud83d\ude09 – will guide us deep into one of the key aspects of a successful multi-account strategy on AWS. <\/em><\/p>\n\n\n\n

As already covered in this blog post series<\/a>, implementing a Landing Zone is the starting point for a future-proof scalable, secure, and dynamic AWS environment. Within a Landing Zone,<\/em> some tricky aspects have to be handled with extreme care. That’s why we asked Nico to help us understand more about secure cloud access and permissions management in AWS. <\/p>\n\n\n\n

How to use IAM Policies and Service Control Policies (SCPs) effectively? And how this can help companies to keep up with every organization’s security and governance needs?<\/p>\n\n\n\n

Let’s find out!<\/em><\/p>\n\n\n\n

Introduction<\/h3>\n\n\n\n

Hello cloud fellows! Today we\u2019ll build up on the cloud landing zone series to explore a fascinating but often ignored context\u2026 Service Control Policies! SCPs are powerful, but there are a few caveats and tricks to make them work efficiently with every different kind of IAM policy<\/strong>. In this blog post, we will see how the whole IAM ecosystem interacts and how we can effectively leverage the tools to deploy a strong IAM strategy in our Cloud Landing Zone.<\/p>\n\n\n\n

There is a lot of ground to cover, so let\u2019s start immediately!<\/p>\n\n\n\n

\n\n\n\n

I don\u2019t want to bother you with all the details about AWS Organizations so that we can keep our focus on permissions. If that\u2019s not the case, refer to one of the thousands of articles on the web or check THIS<\/a> one I wrote.<\/em><\/p>\n\n\n\n

\n\n\n\n

Policies<\/h2>\n\n\n\n

So, let\u2019s get the foundations covered (for the laziest of you, skip after the graph, there\u2019s a neat bullet-point recap). Before jumping directly to the interactions, we need to understand what we have at our disposal in our IAM strategy and all the different kind of tools in IAM to make it work:<\/p>\n\n\n\n

    \n
  1. Identity-based policies<\/strong> are the most common type of policy. They are tied to IAM (Identity and Access Management) users, groups, and roles and specify what actions those entities can perform on certain AWS services.<\/li>\n\n\n\n
  2. Resource-based policies<\/strong>, on the other hand, are policies that are directly associated with an AWS resource, such as an S3 bucket or an EC2 instance. Resource-based policies specify who has access to the resource and what actions they can take. Not all AWS services support them (for a comprehensive list, check the AWS services that work with IAM<\/a> page), and they are usually used for very specific scenarios.<\/li>\n\n\n\n
  3. Permission boundaries (PBs)<\/strong> are policies that define the maximum permissions that an IAM entity can have. These policies limit an entity’s permissions, ensuring they cannot perform actions that exceed their authorized scope. Permission boundaries are also written in AWS policy language and can be attached to IAM entities.<\/li>\n\n\n\n
  4. Service control policies (SCPs)<\/strong> enforce restrictions on AWS accounts within an AWS organization. SCPs are hierarchical policies applied to the entire organization or specific organizational units. SCPs can be used to limit the actions that an AWS account can perform, preventing them from performing activities that are outside their authorized scope.<\/li>\n\n\n\n
  5. Session policies<\/strong> are applied to temporary credentials created by IAM roles. Session policies limit the permissions of a temporary credential set, ensuring that it cannot perform actions that exceed its authorized scope. However, they primarily work like PBs and SCPs: they do not grant permissions and are applied only for the duration of the token. For the sake of simplicity, we\u2019ll introduce this only at the end, so for now, let\u2019s not consider it.<\/li>\n<\/ol>\n\n\n\n

    The caveat<\/h2>\n\n\n\n

    As you may be starting to get, there is a fundamental difference between those policies, and it’s laid out in the diagram by the action that connects the policy to the actual permissions.<\/p>\n\n\n\n

    NOTE: Permission boundaries and Service control policies do NOT grant ANY permission<\/em><\/p>\n\n\n\n

    An Identity can access a Resource only through Identity-based and Resource-based policies. Permission boundaries and SCPs can only limit the aforementioned permissions. That means we need an Identity-based or Resource-based policy that explicitly allows permission to let the policy evaluation engine.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    In short, Identity-based and Resource-based policies define who can access resources and what actions they can perform. Permission boundaries and Service Control Policies limit the scope of those permissions, ensuring that entities cannot perform unauthorized actions.<\/p>\n\n\n\n

    A visual representation of policy interaction<\/h2>\n\n\n\n

    So let\u2019s get a visual representation of our policies: start by seeing how it works in a single account, and then see how things change by adding AWS Organizations to the equation.<\/p>\n\n\n\n

    Yeah, I know the icons differ from the AWS framework but bear with me; I want to highlight the differences and that we\u2019re working with fundamentally different policies.<\/p>\n\n\n\n

    Single account (without Organizations)<\/h3>\n\n\n\n

    As you can see, the three elements we can leverage are Identity-based, Resource-based policies, and Permission boundaries:<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    We can see that while the policies going in and out of the Identity and the Resource grants access, the Permission Boundaries limit that set of permission instead.<\/p>\n\n\n\n

    It\u2019s impossible to grant additional permissions through the use of Permission Boundaries.<\/p>\n\n\n\n

    Organization structure<\/h3>\n\n\n\n

    When integrating the AWS Organization service, we gain the ability to use Service control policies to have better control over our environment:<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    The behavior is practically the same as Permission Boundaries, but we\u2019ll see soon that it has a slight difference. So, to briefly recap:<\/p>\n\n\n\n

      \n
    1. AWS Identity-based policies:<\/strong>\n