feat(code pipeline): basic cross-account support

[rsmogura]

Support for cross-account deployments, and cross-account artifacts replication.

Overview

The work should enable to construct stacks simillar to one described in
reference architecture
https://github.com/awslabs/aws-refarch-cross-account-pipeline

In such a case foreign role have to have access to stored artifacts
in S3 buckets. However in order to achieve this two things must be achieved

• foreign account (role) has to be whitelisted on artifacts' bucket policy; and
• foreign account (role) has to be whitelisted on KMS keys used to encrypt
  artifacts in above bucket (which is impossible to do with AWS managed
  one).

Because names of buckets and KMS key aliases have to be known upfront to pass
those in cross region fashion between underlying Cloud Formation
templates, those are derived from pipeline name (similarly as it's right
for scaffold buckets).

As KMS keys doesn't have name the alias to key is used and it's passed
as configuration to pipeline artifact store, so replicated
artifacts will be encrypted with those keys.

Pipeline tries to whitelist foreign accounts on artifacts stores (buckets
and KMS keys), by adding foreign account root principal to resource
policy.

Changes

Add account attribute to action, and treat it in similar way
as it's right now for region.

Introduced new constructs ArtifactsStore and ImportedArtifactsStore
to encapsulate artifact store (S3 bucket and KMS key), and simplify
managing of stores.

When action is attached to pipeline, check if it's from foreign account,
check if artifact store exists for this region and account. If it doesn't
than create new scaffold stack. Each artifact store created by pipeline
is considered pipeline managed.

If artifact store is pipeline managed whitelist foreign account (add
appropriate resource policy to S3 bucket and KMS key).

When granting permissions to pipeline's artifact bucket
(grantBucketRead/Write), store those n list and grant when pipeline
is rendered. It's driven by two factors:

• actions may ask (i.e. project build one) for permission before
  all stores has been created;
• in case of cross region / account calls, such calls have to be
  performed only on imported store to add grants in IAM principal
  policy, and not in resource policy (scaffold stacks are deployed
  before actual role can be deployed)

Changes to S3 allowing grant to ArnPrincipal (would updated only
resource policy)

Sample workflow

Together with #1449 customers should be able
to create on their own roles, and import those in pipeline stack. When

Some parts of this workflow could be automated, however even without it users would
be enabled to create cross-account pipelines.

• Create stack for deployments in foreign account
  • create jump role which would be set on action
    (feat(aws-codepipeline): support for pipeline action’s service role #1449) this role would mainly allow
    passing Cloud Formation deployment role;
  • grant jump role read / write (as required) permissions to S3 buckets and KMS keys (right now whole foreign account is whitelisted)
  • create deployment role;
• In pipeline account
  • import both roles (require role ARNs to be known)
  • set imported jump role on Cloud Formation actions;
  • set imported deployment role as Cloud Formation role
  • user may be required to get encryption key for pipeline's
    artifact store and pass it to Project Build action,
    as Project Build by default encrypts output
    with aws/s3 key (even if default key is set on bucket)

TODO

In many places kms:* actions are allowed (those should be narrowed to only
those required for encryption, decryption and alias dereference).

Eventually, use tags and conditional statements to widen access to KMS keys;
Right now all KMS keys are granted for principals (in order to allow
principal access to particular key it's UUID has to be known, alias
can't be used in-place)

Project build action requires passing key from pipeline, otherwise artifacts will not get
replicated, as build action will use default aws/s3 key.

[eladb]

@skinny85 can you please take a look?

[skinny85]

@eladb yep, I'm in communications with @rsmogura on this one

[rsmogura]

I would like to split this PR in following tasks (commits), it will make all work more transparent, and better organized

• add ArtifactsStore with KMS support and pass KMS ARNs to CFN templates - ArtifactsStore will encapsulate bucket and KMS key and it's minimum for us, as we will be enabled to start cross-account deployments;
• add support for account attribute on action;
• add support for generating and managing KMS keys and S3 buckets, by whitelisting foreign accounts in resource policies;
• narrowing access to KMS keys (probably using KMS key tags).