Initial Impressions of Governing Delegated Administration for CloudFormation StackSets

I saw a conversation happening on LinkedIn after the announcement of Delegated Administration for CloudFormation StackSets accompanied with concerns about governance of the solution. With a little too much hubris I threw down how IAM guardrails could solve all the problems…then I got around to actually digging into how they implemented the solution. What follows is the first impressions of the solution and attempts at providing guardrails.

Delegating administration for StackSets enables the delegation of the use of Service-managed and Self-service permissions from the new delegated admin account.

Two very different governance approaches need to be considered in these two circumstances.

Self-service guardrails can be implemented using a method I’ve described in another post about Enabling Teams Using CloudFormation with Centrally Managing StackSet Deployments. This article combines great with the new delegated administration using service-service permissions.

The service-managed permission requires additional consideration. By using AWS CloudFormation StackSets for multiple accounts in an AWS Organization, AWS explains that “Service managed permissions allows StackSets to automatically configure the necessary IAM permissions required to deploy your stack to the accounts in your organization.” This does not seem to be consistent with the Delegated Administration implementation of the service-managed option.

Let’s walk through the components that make up the use of StackSets with Delegated Administration:

1. From the Delegated Admin account, a StackSet is created or updated.
2. The CloudFormation service assumes a role in the Organizations admin account which is created at the time a delegation is created for another account.
3. The role in the Organizations admin account assumes into a role deployed in all accounts which appears to be created at the time of registration of the delegated account.
4. A stack is deployed in the member account to build the resources described in the original CloudFormation template in the Delegated Admin account.

Note that the stackset-exec-<RNG> role seems to differ when using service-managed permissions with Delegated Administration. Unlike when deployed from the Organizational admin account, this role is not ephemeral as it’s identified in the trust policy of the AWSServiceRoleForCloudFormationStackSetsOrgAdmin role in the Org admin account.

This role is granted with AdministratorAccess policy.

Attempting to Implement GuardRails

Unlike managing the permissions for service-managed deployments outside of the use with delegated administration, the stackset-exec- role does not appear to be ephemeral. I see two immediate points for integration of guardrails…

1. Deploy a permission boundary to the stackset-exec- roles in all accounts that are deployed as a part of the targeted delegated admin infrastructure.
2. Implement Service Control Policies that act as an explicit allow or explicit deny list for the permissions desired and specify the arn of the stackset-exec- role as the resource.
3. Remove the AdministratorAccess policy from the role and instead replace with a managed policy crafted to grant only the permissions required to accomplish the expected deployments.

Conclusion

Despite how I personally feel about how some confusion is going to stem from the similarities and differences, I think this is a solution that can be secured and governed effectively.

To accomplish the empowerment that this could bring to organizations, a deliberate approach to how these components work together should be a priority before rolling out this new feature set.

If I’ve misrepresented how this solution functions or missed an obvious control to limit negative impacts, please provide feedback. Otherwise, I hope some trial and error, as well as some flipping through CloudTrail events saved you some time in your evaluation.