Simplifying AWS IAM: Part 3 (More about policies and permissions)

Image Source

In this blog, we will discuss Service Control policies and Session policies as well as the overall IAM Policy evaluation logic. We will also try to decipher the surprisingly easy JSON policy document structure (yes, it does look a bit intimidating initially). To understand the basic concepts and working of AWS IAM, read part 1 of my AWS IAM series of blogs. Read part 2 to further understand authorisation in IAM.

If you manage permissions across multiple accounts, you can use IAM roles, resource-based policies, or access control lists (ACLs) for cross-account permissions. However, if you own multiple accounts, AWS recommends using the AWS Organizations service to help you manage those permissions.

AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage.The management account is the account that you use to create the organization. The rest of the accounts that belong to an organization are called member accounts. To understand more about the terminology of organisations, read this.

Service Control Policies (SCP’s)

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization.

• SCP’s do not grant any permissions, they set limits on the actions that the account’s administrator can delegate to the IAM users and roles in the affected accounts. Users and roles must still be granted permissions with appropriate IAM permission policies (identity-based or resource-based policies). The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the identity and resource-based policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.
• SCPs affect only member accounts (entities including each AWS account root user) in the organization. They have no effect on users or roles in the management account.
• Any account in the organisation has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can't use that permission, even if the account administrator attaches the AdministratorAccess IAM policy with */* permissions to the user.
• If both permissions boundary and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action.
• Service-linked roles enable other AWS services to integrate with AWS Organizations and can’t be restricted by SCPs.

AWS Organizations has two available feature sets: All features (which is default as well as preferred) and consolidated billing features. SCPs are available only in an organization that has all features enabled. SCPs aren’t available if your organization has enabled only the consolidated billing features.

Session policies

Session policies are advanced policies that you pass in a parameter when you programmatically create a temporary session for a role or federated user.

• When a federated user signs in to AWS, the user is associated with a role and is granted the permissions that are defined in the role. Multiple users in an organization can assume the same IAM role. By default, all users assuming the same role get the same permissions for their role session.
• To create distinctive role session permissions or to further restrict session permissions, users or systems can set a session policy when assuming a role. If you have an identity broker configured in your environment, you can also configure your broker to insert the sessions policy. This allows your administrators to reduce the number of roles they need to create, since multiple users can assume the same role yet have unique session permissions.

Session policies limit the permissions that the role or user’s identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions.

• You can use managed policies (AWS managed or customer managed policies) as session policies in role sessions and federated sessions to create fine-grained session permissions. You can now pass up to 10 IAM managed policies as session policies.

Permission policies and session policy evaluation logic:

Resource based policy can specify the ARN of the user or role or even the session as a principal.

• When resource-based policy specifies the user or role as a principal, the permissions from the resource-based policy are added to the role or user’s identity-based policy before the session is created. The session policy limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session’s permissions are the intersection of the session policies and either the resource-based policy or the identity-based policy.
• When resource-based policy specifies the session as a principal, the permissions from the resource-based policy are added after the session is created. The resource-based policy permissions are not limited by the session policy. The resulting session has all the permissions of the resource-based policy plus the intersection of the identity-based policy and the session policy.
• A permissions boundary can set the maximum permissions for a user or role that is used to create a session. It does not limit permissions granted by a resource-based policy that specifies the ARN of the resulting session.In that case, the resulting session’s permissions are the intersection of the session policy, the permissions boundary, and the identity-based policy.

Evaluation logic after gathering all of the policies that apply to a request context:

• By default, all requests are implicitly denied. (The root user has full access)
• An explicit allow in an identity-based or resource-based policy overrides this default.
• If a permissions boundary, Organizations SCP, or session policy is present, it might override the allow with an implicit deny.
• An explicit deny in any policy overrides any allows.

Image Source

Whenever a principal sends a request to AWS to access a resource in the same account, AWS decides whether the request should be allowed or denied. The code evaluates all policies within the account that apply to the request. These include AWS Organizations SCPs, resource-based policies, IAM permissions boundaries, role session policies, and identity-based policies.

1. Evaluating Deny: If there is no explicit deny, the code continues. If the code finds even one explicit deny that applies, the code returns a final decision of Deny.
2. Organizations SCPs: The code evaluates if the principal is a member of AWS Organizations with an applicable service control policy(SCP). If it is and if there is no Allow statement in the SCPs, then the request is implicitly denied. The code returns a final decision of Deny. If there is no SCP, or if the SCP allows the requested action, the code continues.
3. Resource-based policies: If the requested resource has a resource-based policy that allows the principal to perform the requested action, then the code returns a final decision of Allow. If there is no resource-based policy, or if the policy does not include an Allow statement, then the code continues. Note: This logic can behave differently if you specify the ARN of an IAM role or user as the principal of the resource-based policy as discussed in the session policy evaluation logic above.
4. IAM permissions boundaries: The code then checks whether the IAM entity that is used by the principal has a permissions boundary. If the permissions boundary policy does not allow the requested action, then the request is implicitly denied and the code returns a final decision of Deny. If there is no permissions boundary, or if the permissions boundary allows the requested action, the code continues.
5. Session policies: The code then checks whether the principal is using a session that was assumed by passing a session policy. If the session policy is present and does not allow the requested action, then the request is implicitly denied. The code returns a final decision of Deny. If there is no session policy, or if the policy allows the requested action, the code continues.
6. Identity-based policies: The code then checks the identity-based policies for the principal. If any statement in any applicable identity-based policies allows the requested action, then the enforcement code returns a final decision of Allow. If there are no statements that allow the requested action, then the request is implicitly denied, and the code returns a final decision of Deny.

For cross-account requests, the requester in the trusted account must have an identity-based policy and the trusting account must have a resource-based policy. AWS evaluates both the permission policies and other policies that limit them. AWS allows the request only if both account policy evaluations allow the request.

Understanding JSON policies

Most policies are stored in AWS as JSON documents. If you do to understand the JSON syntax, you can use the visual editor in the AWS Management Console to create and edit customer managed policies without using JSON ever. However, if you use inline policies for groups or complex policies, you must still create and edit those policies in the JSON editor using the console.

The JSON policy document consists of 2 main sections: a version and one or more individual statements. Statement consists of elements like Effect, Action, Resource, etc. Read the IAM JSON policy reference for more details.

• Version: language syntax rules used to process the policy. version of the policy language that you want to use. As a best practice, use the latest 2012-10-17 version.
• Statement: main element of the policy, it acts as a container for the following elements. You can include more than one statement in a policy. For multiple statements, the array must be enclosed in square brackets [ ]. Each individual statement block must be enclosed in curly braces { }.
• Sid (Optional): statement ID to differentiate between your statements.
• Effect: required element which specifies whether the statement results in an allow or an explicit deny.
• Principal: required if you create a resource-based policy - you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you create an IAM permissions policy to attach to a user or role, the principal is implied as that user or role.
• Action/ NotAction: Statements must include an Action or NotAction element. Action describes the specific action or actions that will be allowed or denied. NotAction is an advanced policy element that explicitly matches (allows) everything except the specified list of actions.
• Resource/ NotResource: specifies the object or objects that the statement covers. Statements must include a Resource or NotResource element. You specify a resource using an ARN. Resource is required if you create an IAM permissions policy - you must specify a list of resources to which the actions apply. If you create a resource-based policy, this is optional. If you do not include Resource, then the resource to which the action applies is the resource to which the policy is attached.
• Condition (Optional): specify the circumstances under which the policy grants permission.

Example of a policy:

1. PowerUserAccess policy :

2. Start or stop EC2 instances based on tags

Conclusion:

That concludes our AWS IAM series of blogs. We understood the working of AWS IAM, the policies and permissions, the IAM policy JSON syntax and also saw some example policies. If you have any questions or suggestions, please comment below.