More progress on cross account deployments

Author: ferdingler

workshop/content/crossaccount/_index.en.md

@@ -3,12 +3,12 @@ title = "Cross Account Deployments"
 date = 2019-10-02T16:10:44-07:00
 weight = 40
 chapter = true
-draft = true
-hidden = true
+draft = false
+hidden = false
 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.
+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 a Serverless application across multiple accounts using Code Pipeline.
 
-![DevWorkflow](/images/cross-account-chapter.png)
+![DevWorkflow](/images/chapter6/cross-account-chapter.png)

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

@@ -0,0 +1,43 @@
++++
+title = "CDK prod environment"
+date = 2019-11-11T14:46:02-08:00
+weight = 35
+draft = false
+hidden = false
++++
+
+Before we define any resources in the stack, we need to configure the CDK project to deploy this stack in the Production account. For this, the CDK has the concept of [Environments](https://docs.aws.amazon.com/cdk/latest/guide/environments.html), which allows you to deploy Stacks in different AWS accounts from within the same CDK project. 
+
+Open the file `bin/pipeline.ts` and replace its content with the following snippet:
+
+{{< highlight js "hl_lines=11 17" >}}
+#!/usr/bin/env node
+import 'source-map-support/register';
+import * as cdk from '@aws-cdk/core';
+import { PipelineStack } from '../lib/pipeline-stack';
+import { ProdIAMStack } from '../lib/prod-iam-stack';
+
+const app = new cdk.App();
+
+new PipelineStack(app, 'sam-app-cicd', {
+    env: {
+        account: '0123456789', // dev account
+    }
+});
+
+new ProdIAMStack(app, 'sam-app-iam-cross-account', {
+    env: {
+        account: '9876543210', // prod account
+    }
+});
+{{< / highlight >}}
+
+**NOTE**: Replace the account IDs corresponding to your dev and production AWS accounts.
+
+{{% notice tip %}}
+The command `aws sts get-caller-identity` is an easy way to get your AWS Account ID. You can also check here for other forms to find it: https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html.
+{{% /notice%}}
+
+### Configure prod credentials
+
+

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

@@ -1,22 +1,22 @@
 +++
-title = "How does it work"
+title = "How it works"
 date = 2019-11-11T14:46:02-08:00
 weight = 20
-draft = true
-hidden = true
+draft = false
+hidden = false
 +++
 
 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)
+![CrossAccountDeploy](/images/chapter6/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. 
+The diagram above illustrates what happens when CodePipeline begins a deployment to the Production account. The first step is to assume the **IAM Cross Account Role** that exists in the Production account; This is possible because the role has a Trust Policy that allows the Dev 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 [3] must create a KMS Customer Master Key and then give the IAM role in the Production account permissions to use it to decrypt the artifacts. 
+AWS CodePipeline *always* stores artifacts on S3 with encryption-at-rest 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 [3] must create a KMS Customer Master Key and then give the IAM role in the Production account permissions to use it to decrypt the artifacts. 
 
 #### Additional reading
 

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

@@ -2,16 +2,16 @@
 title = "Introduction"
 date = 2019-11-11T14:46:02-08:00
 weight = 15
-draft = true
-hidden = true
+draft = false
+hidden = false
 +++
 
 ### 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. 
+Separating environments into different AWS accounts its a common practice among AWS customers. The most basic form of separation is to have 2 AWS accounts, one for non-production environments and one dedicated to Production. This gives developers the ability to have full admin permissions in the Dev environment, to iterate and experiment quickly, and have _limited_ permissions in the Production account.
 
-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. 
+The following diagram illustrates a simple setup of 2 accounts, one for Dev and one for Prod. This is the setup we will be using as reference throughout this chapter, but the concepts learned can be applied to any form of multi-account setup. 
 
-![EnvironmentSeparation](/images/environment-separation.png)
+![EnvironmentSeparation](/images/chapter6/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).
+As you can see from the diagram, the Dev account hosts the Code Pipeline, S3 bucket for artifacts and the code repository. The pipeline then deploys across the Production account using IAM [assumed roles](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html).

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

@@ -0,0 +1,36 @@
++++
+title = "Prod account setup"
+date = 2019-11-11T14:46:02-08:00
+weight = 30
+draft = false
+hidden = false
++++
+
+Let's get started creating the necessary IAM roles in the Production account to grant cross account access. We will do this as a separate stack within the same CDK project created in Chapter 4.
+
+Run the following command to create a new file named _prod-iam-stack.ts_ inside the _lib_ drectory. 
+
+```
+cd ~/environment/sam-app/pipeline
+touch lib/prod-iam-stack.ts
+```
+
+Paste to following content inside the file: 
+
+```js
+import * as cdk from '@aws-cdk/core';
+import iam = require('@aws-cdk/aws-iam');
+
+export class ProdIAMStack extends cdk.Stack {
+    constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
+      super(scope, id, props);
+
+      // Resource definition goes here
+    }
+}
+```
+
+It should look like this: 
+
+![NewIamProdStack](/images/chapter6/new-file-prod-stack.png)
+