Power of AWS Organization ID in controlling access to AWS resources
If you are using a single or multiple AWS Accounts then you may already be aware of the AWS Organizations service. It is a service which is used to centrally manage the AWS Accounts. It gives a unique ID called ‘Organization ID’ per master AWS Account.
If you are not familiar with AWS Organizations, please read it here
Different companies use different strategy to use and manage the AWS Accounts. AWS Organizations provide several features, which not only helps managing the AWS Accounts but also gives power to central cloud COE/Ops teams restricting permissions, apply security guardrails, managing cost across AWS Accounts within one AWS Organization.
One of the ways to restrict access to only certain AWS services & principals is using the policies. AWS offers different policy types, but two most commonly & widely used policies are Identity-based policies and Resource-based policies.
As per official AWS documentation, Identity-based policies are JSON permissions policy documents that control what actions an identity (users, groups of users, and roles) can perform, on which resources, and under what conditions while, Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket.
While using the resource based policies, AWS provides ‘condition keys’, which can be used to apply more granular control over actions allowed, to be performed by AWS service or principal.
The condition key — aws:PrincipalOrgID is very useful in this context. It verifies the organization id, in the AWS Organization, belongs to the principal who is making the request to use the resource such as S3 bucket, VPC endpoint, KMS keys etc. One of the examples is, restricting access of the S3 bucket to the principals belong to one specific AWS Organization.
The above policy explain that, all the users from the member AWS Accounts under Organization ID ‘o-fgxx1zr’ are allowed to put objects in the mentioned S3 bucket resource. Here the aws:PrincipalOrgID under the condition block will be matched against the key & value in request context. If it is evaluated as true, then only the permission will be granted to take mentioned actions on the given resource(s).
Another good use of the aws:PrincipalOrgID is with the policy attached to VPC Endpoints, I have used it in many of the scenarios. Most of the big enterprises whether it is Financial service or any other, use the controlled AWS environment to make it secure.
One of the examples from the actual customer use case is, where customer wanted to allow internal AWS accounts only (belong to customer’s organization) to retrieve & update secrets from the central Secrets Manager store.
The solution I provided was to 1. create a secret in AWS Secrets Manager and 2. attach a resource policy to the Secret which allows users to retrieve & update secrets only when the request comes through the VPC endpoint — vpce-03aa191527a0d1dfc
3. Next step was to, create a VPC Endpoint policy for AWS Secrets Manager service, so that service can be accessed from within a VPC only, (since this VPC was acting as a Hub VPC and principals from the other AWS Accounts were able to access this Hub VPC) and attach a resource-based policy which allows principals from the AWS Accounts but only if they are a member of Organization ID — o-fg6xxx1zr.
Below policy Deny mentioned permissions on any Secrets from any Principal if they don’t belong to the member AWS account falls under Organization ID — ‘o-fgxx1zr’.
You can use the aws:PrincipalOrgID in any resource-based policy to control access (if supported) to that resource. It is specially useful when you have 100s of 1000s of AWS Accounts to manage.
In this blog post, I have shown how you can control access of resources to the member AWS Accounts of an AWS Organization with the help of the condition key — aws:PrincipalOrgID.
Recently, AWS announces support of PrinciplaOrgID in Lambda function resource-based policies, read it here. A blog is also available here.
Hope this blog post will help you securing your resources. I’ll write another blog on another real world use case very shortly.
Till then Happy Learning!
