CloudFormation Setup

We recommend using the Wut.Dev-provided CloudFormation templates, which will configure the correct roles, policies, and trust relationships for Wut.Dev to work properly and securely.

1. Deploy the Management Template

This step will create an IAM role in your management account, called WutDotDev-Mgmt and give it the permissions necessary to assume other Wut.Dev roles deployed in your member accounts, as well as call read-only organizations APIs.

Click the link below to open the CloudFormation Stack creation wizard
The following parameters are required:
1. AssumeRolePrincipalArn
  1. The WutDotDev-Mgmt role needs to be assumed by (human) engineers in your organization. Because every company manages AWS access differently, we can’t pre-populate this for you.
  2. You should set this to the role name associated with human engineers that you want to grant access to Wut.Dev.
  3. You can use wildcards if engineers in multiple accounts should be granted access. Example: arn:aws:iam::*:role/engineers.
  4. Security Note: the template already includes a condition statement that limits assume role access to entities in your organization only (see the next parameter).
2. OrganizationUnitId
  1. The trust policy for the WutDotDev-Mgmt is configured to only trust IAM entities that match the pattern defined in AssumeRolePrincipalArn. Because this can include wildcards, the OrganizationUnitId is used to provide an added layer of security.
  2. You can find your Organization ID in the Organizations AWS console. It should look like o-abcdef1234.
3. IncludeSecurityAudit
  1. Whether the SecurityAudit policy should be attached to the WutDotDev-Mgmt role. This is useful if you’re debugging access issues in the management account but otherwise can be set to false if you’re only debugging member accounts.

Create CloudFormation Stack

2. Use the Role

When you’re done, the IAM entities defined in AssumeRolePrincipalArn can now assume and use this role in Wut.Dev by running:

aws sts assume-role --role-arn arn:aws:iam::{AccountId}:role/WutDotDev-Mgmt --role-session-name WutDotDev

The access key ID, secret ID, and session token can then be copied into Wut.Dev.

You’ll need to provide the above command/instructions to your engineers to whom you want to grant access to the Wut.Dev interface. We recommend creating an alias, like wut on the CLI to do so.

3. Deploy the Member Templates

If you haven’t used CloudFormation StackSets in your Organization you may need to configure the initial access.

This step will create an IAM role in each of your member accounts, called WutDotDev-Member and give it the permissions necessary to call read-only APIs required for debugging and policy management (using the SecurityAudit policy). Its trust relationship will be configured to trust the WutDotDev-Mgmt role we created above.

Open the CloudFormation StackSet creation wizard
Use the following options:
1. Permissions: Service-managed permissions
2. Prerequisite - Prepare template: Template is ready
3. Specify template: Amazon S3 URL
  1. Paste the following URL: https://wut-dev-templates.s3.amazonaws.com/cfn-wut-dot-dev-member-role.json
4. StackSet name: WutDotDev-Members
5. StackSet description: Member account access for Wut.Dev
6. Parameters: OrganizationMgmtAccountId: Enter the AWS account ID of your AWS Organization management account
7. Execution configuration: Inactive
8. Add stacks to stack set: Deploy new stacks
9. Deployment targets: Deploy to organization
  1. Note: If you prefer to only enable Wut.Dev on certain OUs, you can specify those here instead
10. Auto-deployment options:
  1. Automatic deployment: Activated
  2. Account removal behavior: Delete stacks
11. Specify regions: us-east-1 (or your choice; only specify a single region)
12. Deployment options
  1. Maximum concurrent accounts - optional: 1
  2. Failure tolerance - optional: 0
  3. Region concurrency: Sequential
  4. Concurrency mode: Strict failure tolerance
Review and deploy the template