Deploy Anthos on GKE with Terraform Part 2: Guardrails via Policy Controller

This is the second part of a series of articles on using Anthos Config Management (ACM) with Terraform. In the previous article and example, we explained how to use Terraform to create a cluster and manage its configuration from Git via Config Sync. This article will build on that to add guardrails for the cluster via Policy Controller, a product within Anthos Config Management which enables the enforcement of fully programmable policies for your clusters. As we will see, these policies can audit and/or prevent changes to the configuration of your clusters to enforce security, operational, or compliance controls. 

In this case, we will enable an ongoing audit of Kubernetes cluster resources using the Policy Controller's built-in Constraint Template Library as well as bundle of constraints enforcing CIS Kubernetes Benchmark v.1.5.1. Briefly, a Constraint Template provides the mechanism for describing policy declaratively and Policy Controller provides a built in library with Constraint Template implementations for some important best practices in Kubernetes. 

In the interest of simplicity, we will just be auditing the cluster via Policy Controller’s dryrun enforcement action. True to name, this is a “dry run” that only records violations and does not otherwise affect the cluster. However, once you are familiar with these constraints and how they would coexist with production workloads, you should consider using Policy Controller’s deny enforcement action which actively blocks config that violates policy from modifying the cluster. This gives you guardrails to prevent teams from drifting off road, automating centralized review to keep them moving safely.

If you take a look at the part2 example content, the main difference you will see relative to part1 occurs in the Terraform config which manages our cluster. Specifically, the following concise block is now added:

This is all that is needed to enable Policy Controller and also install the Constraint Template Library on your cluster. 

One other difference you may notice from part1 is the config-root/cis-k8s-1.5.1 directory which appears in the config root directory that is synced to the cluster via part1’s Config Sync. This is a bundle of Policy Controller constraints that were pulled into the repo from acm-policy-controller-library repo using the handy kpt tool.

The goal of this bundle is to audit and enforce CIS Benchmarks for Kubernetes. As mentioned above, the constraints have been deployed in dryrun mode so we can use them to audit the cluster.  We can inspect the respective Constraints directly to see any applicable violations, and in this example we’re using the also very handy tool jq to filter output to focus on the violation information:

This command groups the violations with the constraints that enforce them, and one such example is the following which warns abouts containers gaining elevated privileges:

Using Policy Controller, it’s clear that a vanilla Wordpress installation was not really put together with security as a top level concern. In the example, you can see unnecessary privilege escalations, something that is all too common among applications. But with new support for Policy Controller in the Terraform Provider for Google Cloud Platform, it is now very simple to get audit and enforcement for best practices like CIS Benchmarks and the custom policies you require. 

This example repo provides a complete example and step by step instructions you can use to get started customizing and enforcing your own policies. We also encourage you to explore other best practices in the Policy Controller Constraint Library and this tutorial explains how you might go about validating apps against company policies in a CI pipeline.

As we learned in part1, this can all be driven via Git through Config Sync, a manageability plus that’s also a boon for attestation requirements of your security posture. In the next, and final part of the series, we will see how to use Config Connector to provision GCP cloud resources following the same Kubernetes-native model and tools.