Skip to content

v3.0.0
Compare
Choose a tag to compare
@bundyfx bundyfx released this 14 Jan 20:25
· 323 commits to master since this release
v3.0.0
8a73568

v3.0.0 🏎

This release is specifically focused two main topics: Security and Account provisioning

Security:

In this release we are limiting default IAM policies to ensure pipeline phases such as custom deployments or build phases cannot be used to elevate ones own permissions. To ensure strict separation of concerns and enforce high standards around IAM we have created two new IAM Role that lives on each AWS Account within the organization. These role are created in the global.yml (base stack) of each account and are used for the following purposes:

  • adf-automation-role:

When creating pipelines in ADF there are certain things that are required to be setup on multiple different accounts. For example, the source account requires a repository on it, and also a CloudWatch event. Previously the codebuild role would assume the adf-cloudformation-deployment-role in the target account and create the required cloudformation stack. This pattern allowed the adf-codebuild-role to much power and thus we have removed this link. This new role (adf-automation-role) is assumed by codebuild in the aws-deployment-framework-pipelines pipeline exclusively and cannot be assumed by the standard (other) deployment pipelines.

  • adf-readonly-automation-role:

When codebuild runs as part of a standard deployment pipeline (anything other than aws-deployment-framework-pipelines) it uses the role: adf-codebuild-role by default. The adf-codebuild-role has access to assume this new role (adf-readonly-automation-role) on each account within the organization. It assumes this role when running certain intrinsic functions such as import or resolve which allow values to be retrieved from other AWS Accounts within the organization. Previously, codebuild would assume the adf-cloudformation-deployment-role to retrieve these values which can have many actions allowed making it inappropriate to assume.

This change effectively lowers the amount of permissions the default adf-codebuild-role has. Prior to this release, using codebuild as a deployment stage would also default to the adf-codebuild-role which would allow the deployment stage more accesses than intended. From this release onwards, codebuild stages will default to the adf-codebuild-role. However, since this role has very limited access, it will most likely require the user to define a custom role in order to assume and deploy resources into other accounts. For example, if you wanted to deploy some resources with Terraform, or run "cdk deploy" you would need to provide an IAM role that has been created which has the required permissions to do so. For more information on how to create such as role, see the commented out adf-custom-deploy-role in the example-global-iam.yml.

Account Provisioning:

Until this release ADF has not had a streamlined automated way to create and move AWS accounts into organizational units. With 3.0.0 we are introducing an account provisioner concept that handles the creation and OU location of AWS Accounts in a declarative format. As part of the bootstrap repository we have created a new root folder titled adf-accounts, this folder contains definition files (yaml) that describe AWS accounts along with an assortment of properties. The bootstrap pipeline automation component (in codebuild) will parse the files and create or move the accounts into their defined state. This allows for end to end creation, bootstrapping and pipeline generation of an AWS account (all from code!). For more information on this process and a breakdown of the file properties and syntax itself see the admin guide (also see readme.md in adf-accounts folder). A huge thank you to @thiezn and team for this work!

Inter OU Moving of AWS Accounts

Moving accounts between two OU's will now trigger the previous base stack to be removed and the new base stack aligned with that Organizational Unit to be applied.

Tagging Policies

With this release, ADF enables streamlined automation and management of Tagging Policies via AWS Organizations. Tagging Policies can now be applied to OU's in the same manner as Service Control Policies could be in prior versions. Using a tagging-policy.json file in a specific folder of the bootstrap repository that matches to your organization structure enables the tagging policy for the specific OU. Read more about how tagging policies work here and see the example-tagging-policy.json in the bootstrap repo for a simple reference.

Seperation of adf-cloudformation-deployment-role IAM Policy

Moving forward we have decided to move the adf-cloudformation-deployment-role policy out of the global.yml and into a new file called global-iam.yml, this change hopes to simplify and create a separation between the global.yml which contains resources related to ADF in general as opposed to the new file (global-iam.yml) which relates to what can and cannot be deployed into the account that applies that specific base stack. the new global-iam.yml file is searched for recursively in the same fashion other global.yml or regional.yml files.

Other Changes:

  • Resolved #196 - Support for custom codebuild images (You can now use custom build images in your build or deploy actions with CodeBuild. See user-guide for more information and examples.)
  • Resolved #198 - Parameter Store is no longer used for the state of the pipeline definition, this has been moved to S3.
  • Resolved #191 - Simple check tp determine region is correct when deploying from SAR.
  • Resolved #189 - Enable flag for build stage bug fixed, now works as intended.
  • Resolved #180 - error handling has been fixed to correct this.
  • Resolved #178 - ADF Account provisioning is here!
  • Resolved #177 - Upgrades will not touch the global-iam.yml file which holds the cloudformation-deployment-role-policy.
  • Resolved #188 - Removed hardcoded "master" from source account cloudwatch event.
  • Resolved #148 - Base stack (iam and bootstrap) are removed and re-added based on inter OU account moves.
  • cdk version bumped to 1.2.0
  • removed hard coding of master branch on PR event action on source accounts.

Upgrading from 2.x to 3.x

With the change to 3.0 we have decided to move the bootstrap content (templates/scps) in the bootstrap repository into its own folder (adf-bootstrap). Since the bootstrap folder path is changing from the root of the repository into the adf-bootstrap folder, you will need to move your existing folder structure (.yml/scp files) into the new format. When deploying ADF 3.x from the SAR a Pull Request will get made against the bootstrap repository as per normal upgrade process. The 3.0 PR will move the ADF specific content including the deployment folder into the new structure, if you have significantly altered the global/regional.yml for the deployment account be sure to adjust this as intended prior to merging to master. If you require to make alterations to the structure of the folders/templates simply pull the 3.0 branch down and add in your existing folder/OU structure as desired with the adf-bootstrap folder as the new root and push back into the branch.

With the 3.0 change there is also an example-global-iam.yml file that is included in the root of the adf-bootstrap folder. This file should be renamed to global-iam.yml and distributed into the folders/OUs that you intend to have Cloudformation deploy resources into. This is required in order to define what actions the role on the target accounts will have access to when deploying Cloudformation resources via CodePipeline.

Steps to perform for the upgrade process:

  • Open SAR from us-east-1 in the master account.
  • Navigate to ADF, tick "I acknowledge that this app creates custom IAM roles and resource policies." and hit Deploy.
  • Once deployed, navigate to CodeCommit, pull down the branch for 3.0. In your editor, update your folder organizational structure (if you have one) into the adf-bootstrap folder. (this folder is the new "root" for bootstrapping). Ensure you are getting the new content from the deployment folder.
  • Ensure you are bringing in the new content from the global.yml file in 3.0 release, the two roles and their associated policies (adf-automation-role, adf-readonly-automation-role).
  • Rename the example-global-iam.yml to global-iam.yml and ensure its policy suits your needs and that it is in the correct folder structure that suits your organization security requirements. (this file now holds the policy for what CFN can do on target accounts)
  • Push the updated content back to the branch and merge if all looks to be correct.
Assets 3
Loading