Working with AWS Permission Policies

Policies and Permission Controls

Access management is a crucial part of managing your workloads. It is also one of the primary areas where debugging can be problematic. In AWS, there are multiple ways to control access to the platform at various levels. These permission policies make it possible to optimize control of applications, programs, and resources, so day-to-day operations run as smoothly as possible. AWS has many options to create secure policies on its platform. Deciding which policies and permission controls to use for different organizations can seem daunting. Organizations rely on AWS Identity and Access Management (IAM) for access management. But there are more options, particularly for larger, more complex organizations with many accounts. Here, we tackle the best use case scenarios for AWS access management according to the needs of different users and organizations, small and large. We also address new developments and guidance in debugging permission errors.

Identity and Access Management (IAM)

AWS identity access management is a web service that securely enables user or application access to AWS resources and services. It allows users to control and define what users or applications are allowed to do within an account by authenticating and authorizing the user. It also limits what users can do. Within IAM, you have users and roles; unlike a role, a user can be organized into groups. Within IAM, these entities are referred to as principals. Principals can only perform actions when granted permission. IAM roles are not unique to a single individual, they are like a hat that any users or resources can wear if they have permission to do so, and it can give you a temporary “superpower”. Roles permit actions executed by AWS services, and users can assume a role. For example, an AWS service can request temporary access by assuming a role. The most commonly used services are Amazon Simple Storage Service (Amazon S3) buckets, Amazon Elastic Compute Cloud (Amazon EC2), AWS Lambda, and Amazon DynamoDB. Roles are used either within the web console or through a program such as AWS CLI. IAM policies are attached to users, groups, roles and resources. This makes managing permissions in your workload more manageable, particularly for smaller organizations with a small number of accounts. In the case of broader permissions, with multiple accounts. In these cases, you typically have a platform team managing the account vending process. And you probably have some standardized resources that you deploy. The workload teams should not alter these resources because they are created by the workload team. You can protect these resources on an organizational level using Service Control Policies (SCPs).

AWS Permissions

Policies are created based on a user’s request and authorization. They should follow the principle of least privilege. A policy defines permissions and determines access or denial when an IAM principal (user or role) requests it. A policy is nothing more than a JSON definition. You can write them from scratch, copy from existing ones, or use the visual editor, you define the policy, but AWS does the enforcement. AWS also offers managed policies that are managed and maintained by AWS’s team. You can use them directly and let AWS maintain them or, you can copy and modify them according to your needs. Each user and role can have policies attached to it. Users can inherit policies based upon the groups they are a member of. At the time of writing, there are a maximum of 10 policies that you can attach to a user or role. This is a soft limit and you can request an increase with a maximum of 20. There are six types of policies AWS supports which are mainly composed in the JSON policy document format:

• Organization SCP: Service Control Policy is used to define the maximum permissions in an organization. SCPs are applied to organization units, and policies are inherited from the parent OU. SCPs are not for allowing actions, they are only used to deny actions. For example, you can use SCPs to prevent the development team from deploying expensive resources such as EC2 “u-12tb1.112xlarge” which costs $3,648 per day. Or you can use SCPs to limit which regions can be used in your organization by denying the rest of the regions.
• Identity-Based Policies: Permissions granted by IAM identities (users, groups, or roles). This controls what actions an identity can take. In policy, you can deny or allow actions related to each service involving all or specific resources with certain conditions. For example, you can have a policy to allow listing objects of S3 buckets whose name starts with app1-acc-* with the condition that the user used MFA during authentication.
• Resource-based Policies: You can deny or allow specific actions to users or groups by attaching inline policies to resources. Resource-based policies are available for several services; you can find the list here.
• Permission Boundaries: The maximum permissions an identity-based policy can grant to an entity. Permission boundaries are the perfect solution to delegate more tasks to developers to remove overhead from the platform team without compromising security.
• Session Policies: Limits the permission the user or role can grant to a session when you are programmatically assuming a role. By passing a session policy, you can ensure this specific session has only the least privileges needed and not the entire role permission.

AWS Organizations

When your organization grows you will face multiple challenges. One of them is that you onboard more people to your organization. You can use your existing SSO (Single Sign On) solution or use AWS Single Sign On to authenticate these users. Allowing them to assume a role in one of the AWS Accounts. Another challenge would be that you separate your workloads across multiple AWS Accounts. This would lead to more and more AWS Accounts while you grow. A common practice is also to split environments across multiple accounts. So for a single workload you could easily have development, testing, acceptance and production accounts. These challenges can be addressed using AWS Organizations. It allows you to centrally manage the accounts itself and access to them. It would also allow you to manage SCP (Service Control Policies).

Managing Permissions in AWS Organizations: Service Control Policies

Service Control Policies are a policy type found in AWS. SCPs work well in large organizations because they allow the organization to split the responsibilities. With an organizational SCP you can deny complete services, or only a handful of actions. These SCPs have the same policy structure as the IAM policies with one difference. They apply to the whole AWS Account. For example, when you have a certain blueprint of how an AWS Account needs to look like when you hand it over to a workload team. You can protect these resources from being altered or deleted by the users and roles used by the workload team. An SCP is placed on an Organization Unit (OU) and is applied to all accounts in the OU including any nested OUs. One of its primary functions is to ensure that all accounts stay within an organization’s access control guidelines. This means that while SCPs do not grant permissions, they do, however, define the limits and actions of IAM users and roles. SCPs effectively act as the guardrail of all accounts an administrator controls. An SCP can override an IAM policy. In effect, an SCP helps organizations resolve problems that may arise in an evolving cloud infrastructure. Because organizations tend to have many moving parts, with different teams, departments, hierarchies, etc., SCPs help define the boundaries of what is allowed within the account. In the account itself you still need to define the access rights for each principal. If the principal is granted access that is denied by the SCP. The principal is not allowed to perform that action.

Working with an SCP Example

Assume we have a platform team and a workload team. The workload team is the only team allowed to create S3 buckets that start with xebia-workload. The platform team is the only one that can create buckets that start with xebia-platform. You can achieve this with the following SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPlatformPrefixBuckets",
      "Effect": "Deny",
      "Action": [
        "s3:CreateBucket"
      ],
      "Resource": [
        "arn:aws:s3:::xebia-platform-*"
      ],
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/Administrator*"
          ]
        }
      }
    },
    {
      "Sid": "AllowWorkloadPrefixBuckets",
      "Effect": "Deny",
      "Action": [
        "s3:CreateBucket"
      ],
      "Resource": [
        "arn:aws:s3:::xebia-workload-*"
      ],
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/Developer*"
          ]
        }
      }
    }
  ]
}

When you try to create a xebia-platform-myworkload S3 bucket using the “Developer” role. You will get an error like this:

When you create a xebia-workload-myworkload S3 bucket using the “Developer” role. You will be able to create the bucket. When you have a closer look at the policy you will see that we set a Deny on the s3:CreateBucket action. For buckets that match the name xebia-workload-* when the ARN of the principal does not match the Developer role. You can translate this to only the Developer role is not denied to create a bucket with the xebia-workload- prefix. This is a simple example but it illustrates the power of a SCP. From an organizational point you can prevent developers from creating platform buckets. And you prevent administrators from creating workload buckets. This also creates a problem for the developer role. An action is denied but from the account perspective the developer role should be able to create a xebia-platform-workload bucket. The solution to this is using the IAM Policy Simulator. You can select a role, action and the resource and simulate what would happen.

As you can see the action was denied. But it also states that it is denied by AWS Organizations. Now the developer knows that the action is blocked due to a SCP.

Permission Boundaries: Why do you need to start using them?

Imagine this scenario, you are the platform admin, and you need to create a policy for a developer that works on serverless applications. The developer needs a role for each application created, which means you need to create new roles every time there is a new application. To reduce the overhead, you want to permit the developer to independently create the roles, but you are worried if the developer decides to create a role that can do more than what is needed! You can create a policy that allows the developer to create roles only if they attach permission boundaries to the role. Then you can define the maximum permission in the permission boundaries. For our above scenario, permission boundaries can only allow AWS S3 and AWS Lambda function actions. If the developer decides to create a role with administrator access the policy boundary will limit this to only what is allowed within the boundary.

This is what AWS calls the “Effective permissions”. From the organizational point of view, you manage the permission boundaries. The developers can create their own roles but only when they attach one of the boundaries you made available.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRolesWithBoundary",
      "Action": [
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Effect": "Deny",
      "Condition": {
        "StringNotEquals": {
          "iam:PermissionsBoundary": [
            "arn:aws:iam::111122223333:policy/xebia-default-boundary"
          ]
        }
      },
      "Resource": "*"
    }
  ]
}

As you can see in this example policy, we deny the actions when there is no permission boundary called xebia-default-boundary.

How to Debug Permission Errors

As a developer, you might run into permission errors. These errors might not make sense because from the developers perspective all policies are set correctly. In these cases, you might be running into a SCP that has blocked you from performing the action. For this reason, it’s useful to use the policy simulator. The simulator will allow you to select a role that you created. Followed by the service and action you want to simulate. This will tell you if the action is allowed or not. But more importantly, it will tell you why it is denied.

Conclusion

When you are working in larger organizations it is important to have a good vision of how you are handling your permission management. As you could read in this paper there are different places where you can apply your policies. Write down how you are handling your permission management and look at it before you make future changes to your policies. The best practice is to document functions for each role, define permission according to a function with the least privileges using the “allow” action, and avoid using the “deny” action.