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:

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…

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.

Modernizing companies’ AWS security and governance programs at scale.