An overview of AWS Policies

In this post, we are examining a few important AWS policies such as service control policies and IAM policies.

I am investigating the use of different AWS policies to manage permissions in our AWS environment. There are various policy types available in AWS. In this post, we will concentrate on IAM policies and Service Control Policies (SCPs).  

Service Control Policies (SCPs) 

Before explaining service control policies, we need to get familiar with AWS Organization service.  

To build a multi-account AWS environment which supports agility and compliance, there are a handful of AWS tools and services to use. AWS Organization is one of those services.

AWS Organization 

We need a central way of managing governance of the AWS environment. AWS Organization is one of the tools which helps us meet our requirements. AWS Organization is an account management service which enables multi-account management centrally. An Organization can have several Organizational Units (OU) to group AWS accounts based on their workload and function.  

Example of AWS Organization hierarchy

What is an SCP 

Service Control Policy (SCP) is a type of organization policy only available in AWS Organization service with all features enabled. SCPs can define the maximum available permissions for all the accounts in the organization in a centralized way. SCPs can be applied to the whole organization, or OUs (organizational units) or an AWS account directly. Usually, the SCPs are applied to OUs based on the nature of the workload.  

Why to use SCP 

Defining SCPs is a handy way to manage compliance centrally for all the existing and future AWS accounts. Cloud administrators define the maximum permission boundaries for the whole organization or a group of accounts (grouped in OU). SCPs associated with an OU are inherited by all the AWS accounts in that OU and the SCPs affect all the IAM identities including the root user of the member accounts.

SCP example

The following policy blocks use of the LeaveOrganization API operation so that administrators of member accounts can’t remove their accounts from the organization.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization"
            ],
            "Resource": "*"
        }
    ]
}

IAM Policies  

IAM policies are the most frequently used polices on AWS. Before jumping to policies, let us review what is IAM service?  

What is IAM 

AWS Identity and Access Management (IAM) is in Security, Identity, & Compliance category of services. IAM is a web service that enables us to securely control access to AWS resources. IAM can be used to control authentication (signed in) and authorization (has permissions) to use resources. 

Access management 

Access in AWS is managed by creating IAM policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. IAM policies cannot restrict the AWS account root user. IAM policies are used to give fine-grained permissions to AWS principals following the least privilege best practice.  

IAM policy example

The following identity-based policy allows IAM users to perform any IAM action that begins with the string Get or List.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "iam:Get*",
            "iam:List*"
        ],
        "Resource": "*"
    }
}

Policy types 

Identity-based policies – Attach to an identity to grant permissions. 

  • Attach managed or inline policies to IAM identities (users, groups to which users belong, or roles).  

Resource-based policies – Attach inline policies to resources.  

  • Attach to a resource such as an Amazon S3 bucket.  
  • Resource-based policies grant permissions to the principal specified in the policy.  
  • Principals can be in the same account as the resource or in other accounts. 

Permissions boundaries – Defines maximum permissions.  

  • Use a managed policy as the permissions boundary for an IAM entity (user or role).  
  • That policy defines the maximum permissions that the identity-based policies can grant to an entity but does not grant permissions.  
  • Not applied to resource-based policy 

Policy effects and evaluation 

SCPs 

SCPs affect 

  • SCPs affect only IAM users and roles managed by member accounts that are part of the organization.  
  • Also affect member account root user 

SCPs do not affect 

  • Resource-based policies directly.  
  • Users or roles from accounts outside the organization. 
  • Users or roles in the management account (only member accounts are affected) 

SCPs in higher-levels override lower-levels 

  • An account which has several parents (several OUs above), will have permissions permitted by all the parents above it. This means if a permission is denied in any level above the account, the account is denied of that permission. Even IAM policies cannot override the deny.  

SCPs do not grant permission 

  • Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions. 

IAM 

Evaluating identity-based policies with resource-based policies 

  • If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action.  
  • An explicit deny in either of these policies overrides the allow. 

Evaluating identity-based policies with permissions boundaries 

  • The resulting permissions are the intersection of the two categories. 
  • An explicit deny in either of these policies overrides the allow. 

Evaluating identity-based policies with Organizations SCPs 

  • Resulting permissions are the intersection of the user’s policies and the SCP.  
  • An explicit deny in either of these policies overrides the allow. 

Resources 

AWS Policy types 

Least Privilege Permission 

AWS SCPs