OrgPipelineRole Permissions

[mbarneyjr]

I started using org-formation in my organization with the init-pipeline command. I recently noticed however that the pipeline service role's permissions seem to be really open and not scoped down to what org-formation needs (for instance, I wouldn't expect org-formation needs devicefarm or opsworks permissions, correct me if I'm wrong!).

I think these permissions should be scoped down, and we should also have the permissions org-formation needs to execute documented somewhere.

[OlafConijn]

hi @mbarneyjr

Would be happy to document what the pipeline needs. indeed!

The pipeline role is also used to deploy resources to the master account (for other accounts this is the OrganizationAccountAccessRole). I am all for least-privilege, though the tool could be used to deploy virtually anything (including services not released today) i think administrator would still be a fair default.

Will give it some more thought... in any case will get back to you with what permissions it needs for doing the build process.

[OlafConijn]

I @mbarneyjr, others,

The best way to think about the IAM policies is in relation to command. The permissions needed for the perform-tasks command are most interesting (and most complex). This write-up assumes you run perform-tasks in your organization master account - the only way you can run org-formation 0.9.13.

to anyone: Please do let me know if permissions are missing or you have additional questions or you believe that writing/structuring this documentation in a different way would be better. 🙏 thanks in advance.

1. if you run within the context of a codebuild project you will need some basic access to S3, CWL and e.g. CodeCommit. these permissions you can find here

2. In order to run perform-tasks you will also need the following policy:

Version: '2012-10-17'
Statement:
- Sid: AssumeRoleInOtherAccounts
  Effect: Allow
  Action: sts:AssumeRole
  Resource: arn:aws:iam::*:role/OrganizationAccountAccessRole
- Sid: StateRW
  Effect: Allow
  Action:
  - s3:PutObject
  - s3:GetObject
  - s3:CreateBucket # this will not be needed anymore in 0.9.14
  Resource:
  - arn:aws:s3:::organization-formation-${AWS::AccountId}/*
  - arn:aws:s3:::organization-formation-${AWS::AccountId}
- Sid: GetRegions # as of v1.0.0
  Effect: Allow
  Action:
  - ec2:describeRegions
  Resource: "*"

These permissions assume default settings for cross account access role and state bucket. If you are after least privilege you could consider deviating from the use of OrganizationAccountAccessRole, however, an possibly easier way to enforce security policies in member accounts is through SCP.

3. In order to use expressions like !CopyValue both the buildprocess and the cross account access role need to have the following permission:

Version: '2012-10-17'
Statement:
- Sid: AllowCopyValue
  Effect: Allow
  Action: cloudformation:ListExports
  Resource: '*'

Executing a task of type update-organization will need the following permissions (in the master account)

Version: '2012-10-17'
Statement:
- Sid: OrganizationAll
  Effect: Allow
  Action: organizations:*
  Resource: '*'
- Sid: PublishEventBridgeEvents
  Effect: Allow
  Action:
  - events:PutEvents
  Resource:
  - arn:aws:events:us-east-1:${AWS::AccountId}:event-bus/default
- Sid: CreateCaseForEnterpriseSupport
  Effect: Allow
  Action:
  - support:CreateCase
  Resource: '*'
- Sid: PwdPolicyRW
  Effect: Allow
  Action:
  - iam:GetAccountPasswordPolicy
  - iam:DeleteAccountPasswordPolicy
  - iam:UpdateAccountPasswordPolicy
  Resource: '*'
- Sid: AliasRW
  Effect: Allow
  Action:
  - iam:CreateAccountAlias
  - iam:DeleteAccountAlias
  - iam:ListAccountAliases
  Resource: '*'
- Sid: SupportLevelRead # used to determine support level 
  Effect: Allow
  Action:
  - support:DescribeSeverityLevels
  Resource: '*'

Permissions with Sid SupportLevelRead, AliasRW & PwdPolicyRW must also be granted to the cross account access roles (if not using the organization service created default roles).

Other task types will allow you to specify a specific TaskRoleName (see the documentation on task types).

The update-stacks task will require the following permissions:

Version: '2012-10-17'
Statement:
- Sid: UpdateStacks
  Effect: Allow
  Action:
  - cloudformation:SetStackPolicy
  - cloudformation:ListExports
  - cloudformation:DescribeStackEvents
  - cloudformation:CreateStack
  - cloudformation:UpdateStack
  - cloudformation:DescribeStacks
- Sid: PassToServiceRole
  Effect: Allow
  Action: iam:PassRole
  Resource: arn:aws:iam::${AWS::AccountId}:role/my-cfn-service-role #example service role, can also by "*"

Above assumes you are specifying a CloudFormation Service Role. Otherwise the policy will need to contain all permissions needed to create/modify the resources you would want to manage through CloudFormation.

The register-type task will need the following permissions (again in master and applicable target accounts)

Version: '2012-10-17'
Statement:
- Sid: RegisterType
  Effect: Allow
  Action:
  - cloudformation:DescribeType
  - cloudformation:DescribeStacks
  - cloudformation:DescribeTypeRegistration
  - cloudformation:DescribeStackEvents
  - cloudformation:ListExports
  - cloudformation:CreateStack
  - cloudformation:UpdateStack
  - cloudformation:RegisterType
  - cloudformation:DeregisterType
  - cloudformation:SetTypeDefaultVersion
  - cloudformation:ListTypeVersions
- Sid: DownloadType
  Effect: Allow
  Action: s3:GetObject
  Resource: arn:aws:s3:::community-resource-provider-catalog/*

For update-serverless.com and update-cdk i would like to refer to the serverless.com and cdk documentation. Here too you can specify a specific TaskRoleName - if desired.