Restricting Policies
In this tutorial, we are going to discuss about the AWS Restricting Policies and how to set an upper bound on the IAM policies. AWS Restricting Policies are IAM policies designed to limit access to AWS resources, typically by denying certain actions, even if other policies grant permissions. These policies can enforce strict security controls, prevent unintended actions, and are crucial in adhering to the principle of least privilege.
Now we’ll discuss 2 other types of policies that act as upper limits for the IAM entity’s permissions. These advanced optional policies are used when we want to restrict the maximum permissions of an IAM entity.
Permission boundary
A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity. When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role as the principal are not limited by the permissions boundary. However, if resource-based policies specify the role as the principal, then they are limited by the permissions boundary.
Permission boundaries are policies that act as an upper bound on the IAM entity permissions. Any AWS-managed or customer-managed identity-based policy can be used as a permission boundary. When a permission boundary is attached to an IAM entity, it is only able to perform the actions that are allowed in both the attached identity-based policy and the permission policy set for that entity.
When do we need a permission boundary?
Permission boundaries are mostly useful when we want to limit the permissions of an IAM entity created by using an IAM user account. Consider a scenario where we’ve created an IAM user account with permission to create other IAM users or IAM roles and provided the credentials to our admin so they can manage the account. There is a sensitive document stored in one of the S3 buckets, and we don’t want anyone, including the admin, to access that document. So, we’ve not included the permissions required to access that document in the policy attached with the IAM user for the admin. We would think that our document is secure as the admin doesn’t have permission to access it, but in reality, it is not secure. The admin can create another IAM user account with permission to access that document and then use that account to access it.
What we need here is a tool that we can use to set an upper bound on the permissions the admin can provide to other IAM entities. This is where the permission boundary comes in. We can attach a permission boundary with the admin that denies access to the S3 bucket, and in that same permission boundary, we can add a condition that the admin should not be able to create a role or a user unless they add the same permission boundary with them. This closes all avenues of access to the S3 bucket, giving us the protection that we require.
Similarly, we can enforce other policy statements as per our needs.
Session policy
Session Restricting policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies.
Similar to permission boundaries, a session policy is a restricting policy. Its application is however different from that of permission boundary. Session policies are used to set an upper bound on the permissions of a session which is created when a role is assumed. It can only be attached when a role is assumed programmatically. The session policy is sent as an argument along with the request to assume the role. It can be both an inline policy or a managed policy. When a session policy is attached with a session, the effective permissions are the ones allowed by both the session policy and the IAM policy attached with the IAM role using which the session has been assumed.
When do we need a session policy?
An IAM role can be used to create multiple sessions at once. By default, the permissions of each session are the ones allowed by the IAM policy attached with the role. Consider a scenario where we’ve created a role to provide temporary access to external individuals in different roles. We have an admin access policy attached with the role that allows the assuming entities to perform all the actions within that account. What we want next is a tool to limit the permissions of each session based on the role of the individuals assuming the role. This is where session policy comes in. We can attach a session policy with each session, based on the role of the individual allowing them to perform only the actions that should be allowed to that entity.
So if we’re creating a session for an entity to manage DynamoDB operations, we’ll attach a session policy that’ll restrict that entity from doing anything out of the scope of their role.
Effective policy
Now let’s look at what would be the effective policy in case an entity has both the permission boundary policy and session policy attached with it. The diagram below depicts the effective permissions for such a scenario:
For denials, an explicit deny in any of these policies overrides the allow. The diagram below depicts the effective permissions for such a scenario:
To summarize, both permission boundary and session policies are very useful when defining and enforcing access controls within an AWS environment, especially when there is a need to manage and limit permissions for IAM entities in a granular and controlled manner.
Service Control Policies (SCPs)
- 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 the IAM users and IAM roles in your organization.
- SCPs are part of AWS Organizations and act as permission boundaries for accounts within an organization. They control what actions can (or cannot) be performed, regardless of the IAM policies attached to users or roles within those accounts.
- Example: An SCP might deny all users in a development account from launching certain expensive resources like GPU-powered EC2 instances.
- Important Note: SCPs apply account-wide and only affect IAM entities in member accounts (not the management account). They do not grant permissions but instead limit what can be allowed.
Benefits of Using Restricting Policies
- Enhanced Security: Explicit deny policies prevent accidental or unauthorized actions.
- Reduced Costs: SCPs can prevent launching costly resources in development environments.
- Controlled Access Management: Permissions boundaries limit IAM entities from receiving excessive permissions, even by error.
- Regulatory Compliance: These policies help enforce access controls required by regulatory frameworks.
Restricting policies are an essential part of AWS security, providing fine-grained, enforceable limits on what users and services can do within an AWS environment. Properly used, they offer an additional layer of protection, helping to prevent misconfigurations, limit access, and secure critical resources.
That’s all about the AWS Restricting Policies. If you have any queries or feedback, please write us at contact@waytoeasylearn.com. Enjoy learning, Enjoy AWS Tutorials.!!