Add CodePipeline 'smoke-test-role'

[alexiswl]

In order to check stateless services are running correctly, we need a new cross-acct role that bastion can use to run the smoke-tests inside each of the respective accounts.

Related to OrcaBus/service-dragen-wgts-dna-pipeline-manager#122

Permissions would include:

• CloudFormationDiscovery

• LambdaInvocation (would be dryrun only but I don't think I can control that from a policy side)

• StepFunctions (Describe only)

• SSMParameter (Read only)

• IamRoleInspection

What I can't figure out is where to stick this:

https://github.com/umccr/infrastructure/tree/master/terraform/stacks/cdk_bootstrap is deprecated and uses the umccr-unimelb toolchain as the trusted account rather than the bastion account

https://github.com/umccr/infrastructure/blob/master/terraform/stacks/bootstrap is also deprecated

https://github.com/umccr/infrastructure/blob/master/scripts/aws_bootstrap/bootstrap-template.yaml seems like the right spot but then bootstrap-update-all.sh appears to only apply this to the unimelb accounts, not the umccr accounts?

[alexiswl]

Example role

  # ---------- Smoke Test Role ----------
  SmokeTestRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRole
            Effect: Allow
            Principal:
              AWS:
                Ref: AWS::AccountId
          - Fn::If:
              - HasTrustedAccounts
              - Action: sts:AssumeRole
                Effect: Allow
                Principal:
                  AWS:
                    Ref: TrustedAccounts
              - Ref: AWS::NoValue
      RoleName:
        Fn::Sub: cdk-${Qualifier}-smoke-test-role-${AWS::AccountId}-${AWS::Region}
      Policies:
        - PolicyDocument:
            Statement:
              - Sid: CloudFormationDiscovery
                Effect: Allow
                Action:
                  - cloudformation:ListStackResources
                  - cloudformation:DescribeStacks
                Resource: "*"
              - Sid: LambdaSmokeChecks
                Effect: Allow
                Action:
                  - lambda:InvokeFunction
                  - lambda:GetFunctionConfiguration
                Resource: "*"
              - Sid: StepFunctionsSmokeChecks
                Effect: Allow
                Action:
                  - states:DescribeStateMachine
                Resource: "*"
              - Sid: SSMParameterRead
                Effect: Allow
                Action:
                  - ssm:GetParameter
                Resource: "*"
              - Sid: IAMRoleInspection
                Effect: Allow
                Action:
                  - iam:ListRolePolicies
                  - iam:GetRolePolicy
                  - iam:ListAttachedRolePolicies
                  - iam:GetPolicy
                  - iam:GetPolicyVersion
                Resource: "*"
              - Sid: STSIdentity
                Effect: Allow
                Action:
                  - sts:GetCallerIdentity
                Resource: "*"
            Version: '2012-10-17'
          PolicyName: SmokeTestPolicy
      Tags:
        - Key: aws-cdk:bootstrap-role
          Value: smoke-test

[reisingerf]

If I understand this correctly, then this is a role that has to be present in the application accounts (dev/stg/prod) and is accessible from the bastion account, right?

Does the default CDK bootstrap not come with such roles (e.g. the CDK deploy or lookup roles)? Would those be suitable at all?

[alexiswl]

Would those be suitable at all?

Had a play around but no, they don't have the permissions I need. Both the lookup and deploy role have explicit denies on the following

cloudformation:ListStackResources
lambda:InvokeFunction
lambda:GetFunctionConfiguration
states:DescribeStateMachine
ssm:GetParameter

[reisingerf]

Well, I guess a dedicated test role is the better long term approach anyway.

The next question would be how generic / applicable the role should be and where to draw the line (if any).
If we want a generic test role that can be used for any and all tests, I agree, it should be part of the application account setup (unfortunately I don't think we have a dedicated "OrcaBus account setup" construct/place yet).
If we are aiming at very stack specific test scenarios with fine grained access control, then the test role could/should perhaps be part of the application deployment.

I guess we're after the first option?