Service Control Policy and IAM Policy with AWS Organization
This Blog has moved from Medium to blogs.tensult.com. All the latest content will be available there. Subscribe to our newsletter to stay updated.
IAM or SCP or both? Well, we know that the visibility of AWS Identity and Access Management (IAM) is within an AWS account. In AWS Organization (multi AWS account environment) it is not IAM, but an SCP (Service Control Policy) that is handy. Now let us combine SCP and IAM to gain fine-grained control of AWS resources company wide. Before we start with the actual experiment let us be familiar with some of the AWS related terms.
Organization, Organization Unit and Service Control Policies
Organization: AWS Organizations is the administrative boundary that represents a collection of AWS accounts. The account where an AWS Organization is created is called the AWS master account. Other accounts added to the Organization are called linked accounts. So an Organization can have one master account and several linked accounts. We create Organization in which root admin of the master account can control all the AWS resources belongs to the company.
Organization Unit: An Organization can be further divided into Organization Units (OU) which acts as the container for multiple AWS accounts, which represents environments like Production or Development.
Service Control Policy: OUs can be attached with a set of policies called Service Control Policies(SCP) which can control the access of services residing in multiple accounts. So the root of the master account in an AWS Organization can decide the access of all services in any set of linked accounts. It sounds good. We have a small experiment on that in this document.
IAM and Terminology
IAM Policy: Policies are JSON based documents that can describe multiple sets of permissions. You can attach this policy to an IAM identity group, user, or role. As I mentioned IAM policy is visible only within the AWS account.
Users: Users are entities that can be authenticated to the AWS console and are assigned with unique ARN within the AWS account. Users can be assigned a set of permissions called IAM policy.
Groups: Multiple users are organized into groups for easy administration. Groups can be assigned with IAM policies so that they can be inherited from all the member users.
Roles: Many times an AWS service require to access another AWS service. For example, unless CloudWatch gives the write permission to EC2, the logs cannot be sent to CloudWatch. In this scenario, we create a policy with required write permission to CloudWatch.Then create the role of type EC2 and link the policy to the role. Consequently, this role is attached to an EC2 instance so that the instance can write logs to CloudWatch.
IAM Policy structure
IAM allows you to create policy either through user-friendly Visual Editor or character-based JSON editor. Most of the time you will be using Visual Editor because of its user interface. Let us also understand the structure of JSON policy, which is a document that defines permissions. The policy document consist of the following elements:
Effect –allow or deny access to the resource is decided by Effect
Action — the set of service-specific parameters to allow/deny access.
Resource — upon which resource access is allowed on denied
Condition (Optional) –policy grants conditions
IAM Policy an Example:
Let us see simple policy which can send the log from EC2 instance to CloudWatch. Create a policy like below.
{"Version": "2012-10-17","Statement": [{"Sid": "VisualEditor0","Effect": "Allow","Action": ["logs:CreateLogStream","logs:DescribeLogStreams","logs:CreateLogGroup","logs:PutLogEvents"],"Resource": "*"}]}
How you link an above policy?
- Create a role of type EC2 instance
- Attach the created role to EC2 instance
- Now the EC2 instance has the privilege to write logs to CloudWatch
IAM and SCP Act Together: An Experiment
It is assumed the Organization and one OU exist and linked account is part of the OU.
Specification: The experiment is meant for fulfilling the following requirements. the root of the linked account should have full IAM access for the AWS account. IAM user testuser1 should have access to EC2 start/stop/monitor access of EC2 instances in the linked accounts. And the user testuser2 can only view and monitor EC2 instances, not start/stop of them.
Configuration steps:
- Create an SCP like below and attach it to the OU, make sure that default SCP is detached from the OU. EC2 Actions and other parameters in the policy are self-explanatory. “Sid” may vary in the policy.
{"Version": "2012-10-17","Statement": [{"Sid": "Stmt1524993529000","Effect": "Allow","Action": ["iam:*"],"Resource": ["*"]},{"Sid": "Stmt1524993570000","Effect": "Allow","Action": ["ec2:DescribeInstances","ec2:DescribeInstancestatus","ec2:StartInstances","ec2:StopInstances","cloudwatch:DescribeAlarms","cloudwatch:GetMetricStatistics"],"Resource": ["*"]}]}
2 Login as root in the linked account and create testuser1 and testuser2. testuser1 is assigned with AmazonEC2FullAccess and testuser2 is assigned with AmazonEC2ReadonlyAccess.
Don’t worry testuser1 will not get EC2 full access, since permission inherited from SCP from the OU is only to start/stop and monitor the Ec2 instances. He cannot even attach a volume to instance or terminate an instance. Now you see permission testuser2 will get. He can only view and monitor the instance. Though permission inherited from SCP is EC2 start/stop access, IAM permits him to only read access to EC2 instance, not to stop/start it.
Testing
- Login as IAM user testuser1 in the AWS console of the linked account and try to access any volume, he cannot!!!. Try to terminate the instance, he cannot !!!. But he can start/stop the instance.
2) Login as IAM user testuser2 in the linked account and try to start/stop an instance, he cannot!!!. but can view/monitor EC2 instance.
Conclusion
We have studied how an IAM and SCP work together in an AWS environment. We know how to get fine-grained permission for the Organization by combining IAM & SCP. You would have seen that I have done some level of administrative operations in the linked account like creating IAM users assigning policies etc. This administrative operation in the linked account can be avoided by using Cross Account Roles see the blog:
