0

I am setting up aws CDK for a new stack on aws, and the docs say essentially "use the root account to start up, but then set up a policy for a new account":

aws cdk advice on policy creation

However, using their recommended assume/* policy almost immediately leads to errors when trying to cdk deploy. So what is a mechanism for determining a policy useful and applicable to setting up a full cloudformation stack deployment?

For one example use case, when setting up continuous integration to deploy multiple stacks how can we avoid giving it the keys to the kingdom?

Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • 1
    What errors do you run into? Are you able to assume the cdk deployment roles from your principal? As long as you have bootstrapped the account (with `cdk bootstrap`) and your user or role has permission to assume the cdk-created roles, you shouldn't run into errors. – sytech Jan 10 '23 at 03:25

1 Answers1

0

Since I am part of the aws community builders community, I asked there as well. Suffice it to say that this is a known problem, and not a trivial one to solve. I will try to distill what I learned into an answer here in broad strokes:

  • Set up permission boundaries. These can forbid an agent from creating new users and privilege escalation. https://aws.amazon.com/blogs/devops/secure-cdk-deployments-with-iam-permission-boundaries/
  • Walk your shots/walk your permissions. In other terms, give scant few permissions, then try to deploy, find where additional permissions are needed and add those, try to deploy again, rinse and repeat. This is most applicable if you expect the services of a stack to rarely change.
  • Draft a permission policy of Allow all... ...then deny in particular. In other words, set a policy on the deploying agent that allows * access to all services... ...and then deny permission to create users, change other users, etc etc. Contained within this approach is: bootstrap, then customize https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing
  • Consider a multi-account strategy, where you would add a new aws account for a different project. Because AWS is usage based payment, they allow for multi-accounting in this way where other services might have policies against multiple accounts. Control tower can help with this.
Kzqai
  • 22,588
  • 25
  • 105
  • 137