Cyber Defense Advisors

Delegating SCP Management to Governance Team via AWS Organizations

ACM.141 Delegated AWS Organizations Administrator — Policy as Code

This is a continuation of my series on Automating Cybersecurity Metrics.

I’ve been writing about how to delegate permission to manage SCPs to our governance team. One way to do that is via a delegated administrator.

Delegated Administrator for AWS Organizations

In the last post I reverse-engineered the information that I hope will work in that policy:

Analyzing CloudTrail Requests Related to SCPs

Now let’s see if we can get it working.

Grant access to organization resources

We’re going to need to first of all grant access to the governance account to manage organizational resources:

Grant access to manage SCPs

Next we want to create a policy like this but we need to change the condition to our SCPs and the resource to our organizational SCPs.

In the above policy we need to change the relevant bits to match SCPs instead of backup policies. In the last post we figured out that the condition for BACKUP_POLICY might relate to this snippet — though it doesn’t have the bit about organizations.

Note the location of the condition above and to which actions it applies. I think this policy may have an issue. the condition seems like it is extraneous and might not correctly apply to those actions. In the sample policy below on another page in the AWS documentation, the condition is in a different location and applies to different actions.

I doubt any tool is going to discover all these nuances for you.

A Security Tool Won’t Save You

We also figured out that the ARN for a Service Control Policy is structured like this:

Well, we might not even need the condition, if we want to allow the governance team to manage Service Control Policies for the entire organization. The ARN itself has service_control_policy in it. So let’s try it without the condition first.

How to apply the delegated administrator policy to your AWS Organization

Note that I removed a rabbit hole I went down trying to mimic automating this in a new account. For reasons I’ll explain in a separate blog post, I’m going to do this manually for now in my existing account with a user who has the necessary permissions.

You can find both manual and automated instructions on this page:

Delegated administrator for AWS Organizations

Navigate to AWS Organizations. Click Settings.

Under Delegated administrator for AWS Organizations click Delegate.

Copy and paste in the policy that allows your new account to view organization resources from this page:

Example: View organization, OUs, accounts, and policies

I changed the SID (name or ID) to something that makes more sense to me.

Change the AccountId in the policy to whichever account number you wish to delegate access.

Notice that it’s granting access to the “root” user which doesn’t only mean the Account AWS actual root use but also administrators in the account. If you have concerns about how who has access you should do some testing to determine who has access and who doesn’t in that account.

In my case, I’m going to only create one role in this account for the governance administrators in this account and I’ll need to make sure that role has access when I get to it. As noted in a past post we can also apply restrictions on the root account in every AWS account using an SCP. More on that later.

Now here’s something I didn’t think would happen. We’re going to end up with a monolithic policy here because what happens is that single policy gets added to the Organizations’s settings. Instead of creating different policies for different types of access we’re going to have to apply it in one single policy like you do when you create an S3 bucket.

I guess I was expecting we could create different policies for different AWS Organizations delegated administrators. But it aligned with how S3 bucket policies work so it makes sense. In any case, let’s log into the governance account and see if we can view the organization information using a user that has admin access.

Yes I can, though I’m not exactly sure if this permission is granted by way of an AWS SSO role.

I navigate to another account with the same permission set, and in this case, I cannot view the policies, so this seems to work:

Now let’s see if we an edit an SCP, back in the governance account.

No, so our policy works as expected.

Now let’s add the permissions to manage the SCPs.

Notice the Governance account also cannot see the organization’s settings:

Return to the root account and edit the policy we created above.

We’re going to insert a new statement because the prior statement applies to all (*) resources in our organization. the new statement is only going to apply to SCPs (hopefully). Add a comma after the existing statement and a new open and close bracket. The text “#new policy here” shows you where we’re going to insert the new policy code.

Let’s use a modified version of this policy that grants permission to manage backup policies:

Example: Consolidated permissions to manage an organization’s backup policies

Now I looked at replacing the condition in the above policy but notice to which actions the condition applied above? What is that condition applicable to in the policy from in the sample code below? The two different examples from the AWS documentation have the condition in two different places.

The condition below appears to limit the delegated administrator to viewing the organizational resources related to backup policies. The code in the prior example was applied to the actions related to policies. For my purposes, I’m going to let my governance account view any organizational information so we don’t really need that condition. We don’t need a condition on policies because the ARN we are going to use only applies to service control policies.

We’ve already added the rest of the top portion of this policy, so we just need to insert the second statement in this policy into the policy we just added to our organization, but we want to replace the four ARNs with the service control policy ARN. You’ll need to set your account number in the statement below as well, to replace the X’s underlined in red.

When I tested my policy the above policy statement saved successfully but did not work. I tested first with a single ARN. Then I replaced the organization specific pieces one at a time with *.

Here’s my policy working:

(Remember to change the account numbers.)

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “ViewAWSOrganizationsResources”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::XXXXXXXXXXXX:root”
},
“Action”: [
“organizations:DescribeOrganization”,
“organizations:DescribeOrganizationalUnit”,
“organizations:DescribeAccount”,
“organizations:DescribePolicy”,
“organizations:DescribeEffectivePolicy”,
“organizations:ListRoots”,
“organizations:ListOrganizationalUnitsForParent”,
“organizations:ListParents”,
“organizations:ListChildren”,
“organizations:ListAccounts”,
“organizations:ListAccountsForParent”,
“organizations:ListPolicies”,
“organizations:ListPoliciesForTarget”,
“organizations:ListTargetsForPolicy”,
“organizations:ListTagsForResource”
],
“Resource”: “*”
},
{
“Sid”: “DelegatingAllActionsForServiceControlPolicies”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::XXXXXXXXXXXX:root”
},
“Action”: [
“organizations:CreatePolicy”,
“organizations:UpdatePolicy”,
“organizations:DeletePolicy”,
“organizations:AttachPolicy”,
“organizations:DetachPolicy”,
“organizations:EnablePolicyType”,
“organizations:DisablePolicyType”
],
“Resource”: “arn:aws:organizations::*:policy/*/service_control_policy/*”
}
]
}

With the above policy the governance account is able to manage service control policies, including those created by Control Tower and the ones created by the root user in the root account.

The governance team cannot change the organizational policy settings with these permissions or manage other types of policies.

Follow for updates.

Teri Radichel

If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me.

Medium: Teri Radichel
Email List: Teri Radichel
Twitter: @teriradichel
Twitter (company): @2ndSightLab
Mastodon: @[email protected]
Post: @teriradichel
Facebook: 2nd Sight Lab
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Buy me a coffee: Teri Radichel
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Request services via LinkedIn: Teri Radichel or IANS Research

Request services via LinkedIn: Teri Radichel or IANS Research

© 2nd Sight Lab 2023

All the posts in this series:

Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation

____________________________________________

Author:

Cybersecurity for Executives in the Age of Cloud on Amazon

Need Cloud Security Training? 2nd Sight Lab Cloud Security Training

Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.

Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts

Delegating SCP Management to Governance Team via AWS Organizations was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.