The night before the AWS re:Invent conference is referred to as midnight madness, as AWS makes many announcements all at once. This year, AWS announced delegated administrator for AWS Organizations. In this post I discuss what this feature is, explore some example use cases it allows, and what we think could be concerns in the future as a result of this. 

What does it do?

Delegated administrator for AWS Organizations allows a limited set of Org capabilities to be delegated to one or more accounts within the Org. You cannot delegate them to an account in another Org, and (thankfully) cannot make them publicly accessible. These capabilities are generally of two types: 

• Visibility into the account tagging, naming, and Organizational Unit (OU) structure 

• Management of policy features: backup policies, service control policies (SCPs), tag policies, and AI services opt-out policies 

This does not let you delegate creating or deleting accounts, setting up the Org CloudTrail, enabling or disabling other delegated admin features, or a number of other Organization features (see the full list of supported actions). 

This new functionality is not a delegated admin in the same sense that other services support, in which a single account is designated as the admin with full capabilities over a service. Instead, delegated administrator for AWS Organizations works as a resource policy applied to the Org, and is referred to as resource-based delegation policy. This is important because it means you can apply multiple statements that each grant a different capability to a different account or group of accounts. For example, you could grant one account the ability to modify an SCP attached to one OU, another account the ability to modify an SCP for a different OU, and yet another account the ability to manage the backup policy for the first OU. It also means you could (but should NOT) grant all accounts in your Org all available Organization features to modify their own SCPs and other policies. 

Use Cases

Visibility into the names and tags of the other accounts in the Org 

Security teams often struggle to determine whether a referenced account ID refers to an account within their Org and, if so, what that account is used for. Such unknown account IDs can pop up in many places: a trust relationship in an S3 bucket policy, an ARN referenced in an IAM policy, or in a finding generated by GuardDuty. Different teams tackle this problem in different ways: 

• Maintaining spreadsheets that describe the accounts across the Org—This approach is highly manual, so the spreadsheets frequently get out of sync. 

• Creating an IAM role in the AWS Organization Management account that needs to be assumed to gain access to the organizations:ListAccounts API. 

• Creating a service that uses the IAM role technique or runs directly in the Organization Management account. 

Delegated administrator for AWS Organizations solves this visibility problem much more elegantly than any of these approaches. It lets you grant an account the ability to see the other accounts in the Org and the tags applied to them directly by creating an Org delegation policy as follows: 

Note that when the member account calls aws organizations list-accounts it does not need a new version of the CLI and does not pass the Org ID, because again, you cannot delegate these calls to an account outside of your Org. 

Using this capability, if you tag all the accounts in your Org with an Owner, such as a Slack channel, you can now respond to a GuardDuty alert by looking up the “Owner” with aws organizations list-tags-for-resource --resource-id 222222222222 and automatically relaying the alert to their Slack channel. 

Visibility into SCPs applied to your account 

A common grievance from developers when SCPs are deployed is that they don’t know what the SCPs are that are impacting them. Some security teams want to keep their SCPs secret because they worry that their policies could be bypassed, or that this knowledge could be beneficial to an attacker who compromised an account. However, many organizations still would like this visibility, so the following shows how to delegate this ability to all accounts in the Org: 

In this example, I’ve added a condition that restricts the principals that can call this to only those within the Org. This is currently unnecessary as only member accounts can be granted these privileges, but it makes me uncomfortable to have a Principal of * without a condition, and this future proofs against possible expansion of the capabilities of this feature. 

A simple script can be written to print out the SCPs applied to an account using these privileges:

Control an SCP for an OU 

In large companies with multiple business units, many AWS accounts may reside in one AWS Organization, but different business units may wish to control the SCPs applied to their AWS accounts. It is now possible to accomplish this without needing access to the Organization Management account via an IAM role. The following statement, which can be attached to the delegation policy above, grants an account the ability to modify a specific SCP: 

Be aware that if this SCP is applied to the OU that this delegated account lives inside, then the delegated account can lock itself out. The Organization Management account, which used to be the only account that could modify SCPs, could never lock itself out because the SCPs did not apply to it. 

This sample statement grants access to only a single policy. Granting access to all policies associated within an OU in a generic way is more difficult than it might seem. The conditions available are limited, the organizations:UpdatePolicy privilege oddly does not support tag conditions, and unlike the aws:PrincipalTag key, there is no key associated with a principal to specify the tags of the account they are in. For these reasons, typical Attribute Based Access Control (ABAC) strategies of AWS cannot be used. A resource naming strategy where naming prefixes are used for policies and OUs may be sufficient for some needs. However, as AWS continues to develop delegated administrator for AWS Organizations, some of these restrictions may be eliminated. 

Looking forward

The capabilities that delegated administrator for AWS Organizations allows—delegating control of SCPs and other policy types to different parts of an AWS Organization—will likely encourage more security teams to utilize SCPs, increase flexibility, and allow some use cases that previously required IAM role assumption to the Organization Management account. However, this increased use could result in more deviations and increase the likelihood of protection gaps. 

Different teams may apply different exception conditions to the policies making it difficult to compare and ensure protection parity across an organization. The deny-list strategy used by SCPs is also more difficult to apply effectively than the already difficult allow-list strategy commonly used in IAM policies. Gaps in protection can occur in deny-list strategies when AWS adds new privileges, or they can arise simply due to the difficulty in effectively identifying all potentially problematic privileges that should be denied. 

As with many new features, there are dangers and benefits. I believe this functionality will be most useful for larger companies to distribute access to the different Org policy types, and to avoid IAM role access into the Org Management account.  

I'm always interested in learning about the strategies companies use to manage their Organizations, so feel free to reach out on Twitter if you have interesting use cases with this new feature!