AWS Security Blog
Extend your pre-commit hooks with AWS CloudFormation Guard
Git hooks are scripts that extend Git functionality when certain events and actions occur during code development. Developer teams often use Git hooks to perform quality checks before they commit their code changes. For example, see the blog post Use Git pre-commit hooks to avoid AWS CloudFormation errors for a description of how the AWS Integration and Automation team uses various pre-commit hooks to help reduce effort and errors when they build AWS Quick Starts.
This blog post shows you how to extend your Git hooks to validate your AWS CloudFormation templates against policy-as-code rules by using AWS CloudFormation Guard. This can help you verify that your code follows organizational best practices for security, compliance, and more by preventing you from commit changes that fail validation rules.
We will also provide patterns you can use to centrally maintain a list of rules that security teams can use to roll out new security best practices across an organization. You will learn how to configure a pre-commit framework by using an example repository while you store Guard rules in both a central Amazon Simple Storage Service (Amazon S3) bucket or in versioned code repositories (such as AWS CodeCommit, GitHub, Bitbucket, or GitLab).
Prerequisites
To complete the steps in this blog post, first perform the following installations.
- Install AWS Command Line Interface (AWS CLI).
- Install the Git CLI.
- Install the pre-commit framework by running the following command.
pip install pre-commit - Install the Rust programming language by following these instructions.
- (Windows only) Install the version of Microsoft Visual C++ Build Tools 2019 that provides just the Visual C++ build tools.
Solution walkthrough
In this section, we walk you through an exercise to extend a Java service on an Amazon EKS example repository with Git hooks by using AWS CloudFormation Guard. You can choose to upload your Guard rules in either a separate GitHub repository or your own S3 bucket.
First, download the sample repository that you will add the pre-commit framework to.
To clone the test repository
- Clone the repo to a local directory by running the following command in your local terminal.
git clone https://github.com/aws-samples/amazon-eks-example-for-stateful-java-service.git
Next, create Guard rules that reflect the organization’s policy-as-code best practices and store them in an S3 bucket.
To set up an S3 bucket with your Guard rules
- Create an S3 bucket by running the following command in the AWS CLI.
aws s3 mb s3://<account-id>-cfn-guard-rules --region <aws-region>
where <account-id> is the ID of the AWS account you’re using and <aws-region> is the AWS Region you want to use.
- (Optional) Alternatively, you can follow the Getting started with Amazon S3 tutorial to create the bucket and upload the object (as described in step 4 that follows) by using the AWS Management Console.
When you store your Guard rules in an S3 bucket, you can make the rules accessible to other member accounts in your organization by using the aws:PrincipalOrgID condition and setting the value to your organization ID in the bucket policy.
- Create a file that contains a Guard rule named rules.guard, with the following content.
This rule will verify that public endpoints are disabled by checking that resources that are created by using the AWS::EKS::Cluster resource type have the EndpointPublicAccess property set to false. For more information about authoring your own rules using Guard domain-specific language (DSL), see Introducing AWS CloudFormation Guard 2.0.
- Upload the rule set to your S3 bucket by running the following command in the AWS CLI.
aws s3 cp rules.guard s3://<account-id>-cfn-guard-rules/rules/rules.guard
In the next step, you will set up the pre-commit framework in the repository to run CloudFormation Guard against code changes.
To configure your pre-commit hook to use Guard
- Run the following command to create a new branch where you will test your changes.
git checkout -b feature/guard-hook - Navigate to the root directory of the project that you cloned earlier and create a .pre-commit-config.yaml file with the following configuration.
You will need to replace the <account-id> placeholder value with the AWS account ID you entered in the To set up an S3 bucket with your Guard rules procedure.
This hook configuration uses local pre-commit hooks to download the latest version of Guard rules from the bucket you created previously. This allows you to set up a centralized set of Guard rules across your organization.
Alternatively, you can create and use a code repository such as GitHub, AWS CodeCommit, or Bitbucket to keep your rules in version control. To do so, replace the command in the Download Organization rules step of the .pre-commit-config.yaml file with:
bash -c ‘if [ -d guard-rules/org-rules ]; then cd guard-rules/org-rules && git pull; else git clone <guard-rules-repository-target> guard-rules/org-rules; fi’
Where <guard-rules-repository-target> is the HTTPS or SSH URL of your repository. This command will clone or pull the latest rules from your Git repo by using your Git credentials.
The hook will also install Guard as an additional dependency by using a Rust hook. Using Guard, it will run the code changes in the repository directory against the downloaded rule set. When misconfigurations are detected, the hook stops the commit.
You can further extend your organization rules with your own Guard rules by adding them to the cfn-guard-rules folder. You should commit these rules in your repository and add cfn-guard-rules/org-rules/* to your .gitignore file.
- Run a pre-commit install command to install the hooks you just created.
Finally, test that the pre-commit’s Guard hook fails commits of code changes that do not follow organizational best practices.
To test pre-commit hooks
- Add EndpointPublicAccess: true in cloudformation/eks.template.yaml, as shown following. This describes the test-only intent (meaning that you want to detect and flag errors in your rule) of adding public access to the Amazon Elastic Kubernetes Service (Amazon EKS) cluster.
- Add your changes with the git add command.
git add .pre-commit-config.yaml
git add cloudformation/eks.template.yaml
- Commit changes with the following command.
git commit -m “bad config”
You should see the following error that disallows the commit to the local repository and shows which one of your Guard rules failed.
- (Optional) You can also test hooks before committing by using the pre-commit run command to see similar output.
Cleanup
To avoid incurring ongoing charges, follow these cleanup steps to delete the resources and files you created as you followed along with this blog post.
To clean up resources and files
- Remove your local repository.
- Delete the S3 bucket you created by running the following command.
- (Optional) Remove the pre-commit hooks framework by running this command.
Conclusion
In this post, you learned how to use AWS CloudFormation Guard with the pre-commit framework locally to validate your infrastructure-as-code solutions before you push remote changes to your repositories.
You also learned how to extend the solution to use a centralized list of security rules that is stored in versioned code repositories (GitHub, Bitbucket, or GitLab) or an S3 bucket. And you learned how to further extend the solution with your own rules. You can find examples of rules to use in Guard’s Github repository or refer to write preventative compliance rules for AWS CloudFormation templates the cfn-guard way. You can then further configure other repositories to prevent misconfigurations by using the same Guard rules.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the KMS re:Post or contact AWS Support.
Want more AWS Security news? Follow us on Twitter.