Cross account deployments intro

Author: ferdingler

workshop/config.toml

@@ -14,7 +14,7 @@ pygmentsCodeFences = true
 pygmentsStyle = "monokai"
 
 [params]
-  editURL = "https://github.com/aws-samples/serverless-workshops"
+  editURL = "https://github.com/aws-samples/aws-serverless-cicd-workshop/tree/master/workshop/content/"
   description = "Building a CI/CD pipeline for Serverless applications"
   author = "Fernando Dingler <fdingler@amazon.com>"
   disableBreadcrumb = false

workshop/content/crossaccount/_index.en.md

@@ -0,0 +1,12 @@
++++
+title = "Cross Account Deployments"
+date = 2019-10-02T16:10:44-07:00
+weight = 40
+chapter = true
+pre = "<b>6. </b>"
++++
+# Cross Account Deployments
+
+Cross-account deployments are useful for customers who separate their environments (Dev, Test, Prod) into different AWS accounts. In this chapter you will learn how to deploy across multiple accounts using AWS Code Pipeline.
+
+![DevWorkflow](/images/cross-account-chapter.png)

workshop/content/crossaccount/howitworks/_index.en.md

@@ -0,0 +1,17 @@
++++
+title = "How does it work"
+date = 2019-11-11T14:46:02-08:00
+weight = 20
++++
+
+Before jumping to the implementation, we need to understand the different pieces that allow Code Pipeline to deploy across a different account. The following diagram shows a zoomed-in view of the services and roles involved in this process. 
+
+![CrossAccountDeploy](/images/cross-account-deploy.png)
+
+#### Explanation
+
+The diagram above illustrates what happens when CodePipeline begins a deployment to the Production account. The first step is to assume the **IAM Pipeline Role** that exists in the Production account; This is possible because the role has a Trust Policy that allows the Development account to assume it. The second step is CodePipeline uses that role to trigger a deployment in CloudFormation by passing the **IAM Deployer Role**. This action is called [PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) and is needed for CloudFormation to create resources on your behalf. Finally, as you learned in previous chapters, CloudFormation gets the deployment artifacts from S3 and decrypts them by using the KMS Customer Managed Key. 
+
+#### Why encrypt the artifacts?
+
+AWS CodePipeline *always* stores artifacts on S3 with encryption enabled and there is no way to disable it. The default behavior is to use the AWS Managed Key to encrypt them, but this approach doesn't work for granting access to S3 buckets across accounts. Therefore you must create a KMS Customer Managed Key and then give the IAM role in the Production account permissions to use it to decrypt the artifacts. 

workshop/content/crossaccount/intro/_index.en.md

@@ -0,0 +1,16 @@
++++
+title = "Introduction"
+date = 2019-11-11T14:46:02-08:00
+weight = 15
++++
+
+### Environment separation
+
+Separating environments (Dev, Test, Prod) into different AWS accounts is a very common practice among AWS customers. And the main motivation being the ability to give developers full administrative access to the Dev environment, so that they can innovate and iterate quickly, but give them _limited_ access to higher environments, like Production. There are other motivations as well, like managing [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) separately and having billing details broken down per environment. 
+
+The following diagram illustrates a simple account setup that many customers start with. And we will also be using it throughout this chapter. But the concepts that you will learn here can be applied to any form of multi-account setup. 
+
+![EnvironmentSeparation](/images/environment-separation.png)
+
+As you can tell from the diagram, the Dev account hosts the Code Pipeline, Artifacts Bucket and the Code Repository. The CodePipeline then deploys across the Production account using an [assumed role](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html). 
+