Let Kubernetes Automate Your Configs And Policies With Anthos Config Management

As the famous adage goes “show, don’t tell.” In this post, I’ll show an example of how you can leverage a GitOps methodology using Config Sync to apply configuration consistently across clusters and environments with an auditable, transactional, and version-controlled deployment process. And we’ll use Policy Controller for the enforcement of programmable policies that represent constraints on the desired state.

First, follow the setup process in the Git Repo to build out the infrastructure and then deploy the services as per the directions.

In other words, as a platform admin, you really care about two things with the Kubernetes Resource Model (KRM) : 1) Consistency, and 2) Protecting the clusters from unsafe configuration. Let’s take a look at how using Anthos Config Management can help you achieve those two goals.

​​In this example, we will deploy a mock banking application called Cymbal-Bank.

For the purpose of this exercise, let’s assume that you have already installed Config Sync and Policy Controller in your clusters.

The first set of pods, in the config-management-system namespace, run Config Sync. These workloads periodically check your GitHub policy repo for any updates to the KRM source of truth stored there, and deploy those updated resources to the cluster. These workloads help ensure that any resources entering the cluster — both through CI/CD or through Config Sync — adheres with any policies we set.

The second set of workloads, in the gatekeeper-system namespace, run Policy Controller,  which is based on the open-source Gatekeeper project, which in turn grew out of the OpenPolicyAgent project, part of the Cloud-Native Computing Foundation (the same foundation that hosts Kubernetes).

Policy Controller is a Kubernetes dynamic admission controller that checks, audits, and enforces your clusters’ compliance with policies related to security, regulations, or arbitrary business rules. Policy Controller policies are broken up into two separate objects: Constraints and ConstraintTemplates. Having two distinct objects allows for separation of the policy definition (ConstraintTemplate) and policy enforcement (Constraint).

Let’s unpack that. An admission controller is a pod that sits at the “gate” of a Kubernetes cluster, watching what’s coming into the API server and doing some type of operation on that resource, before it’s “allowed inside” the cluster and persisted in etcd. That “operation on the resource” could include modifying the resource in-flight (MutatingAdmissionWebhook) or rejecting the resource entirely (ValidatingAdmissionWebhook). Policy Controller uses the second kind of webhook to validate incoming config against the policies it knows about, allowing policies in, or rejecting them.

Policy Controller enforces constraints, but what do those constraints actually look like? What kinds of Kubernetes resources can we use PolicyController to accept or reject?

Here’s an example constraint:

Here, “kind: K8sNoExternalServices” refers to the k8snoexternalservices constraint template already installed on the cluster. And notice how we’re using Config Sync’s cluster-name-selector annotation to scope this resource to the cymbal-dev cluster only.

This Constraint implements the K8sNoExternalServices Constraint Template with concrete information about our environment.

Expected output:

With the above command, you just deployed a Policy Controller policy via Config Sync! When we went to deploy an application that violated the policy constraint, ACM correctly denied the request. If you would like to test drive this lab please follow the setup on this Git Repo developed by our Staff Developer Relations Engineer, Megan O’Keefe. If you’re a GKE customer, you can now use Anthos Config Management at a low incremental per-cluster cost. To learn more about Anthos Config Management and explore best practices, quickstarts, and tutorials, visit our documentation page.