Introduction to Anthos Config Management
This is part 1 in a multi-part series about the Anthos Config Management (ACM). In part 1, I will introduce ACM and ACM Standalone for GKE. Then I will demonstrate how to use each of the components (Config Sync, Policy Controller and Config Controller) that make-up ACM.
From large digital-native powerhouses to midsized manufacturing firms, every company today is creating and deploying more software to more places more often. Anthos Config Management lets you set and enforce consistent configurations and policies for your Kubernetes resources — wherever you build and run them — and manage Google Cloud services the same way.
Anthos Config Management is a service for configuration and policy management that combines three components; Config Sync, Policy Controller and Config Controller. Together, these components make it possible for Anthos Config Management to continuously protect and configure your Google Cloud and Kubernetes resources as shown in the following diagram:
Anthos Config Management is now available for Google Kubernetes Engine (GKE) as a standalone service. GKE customers can now take advantage of config and policy automation in Google Cloud at a low incremental per-cluster cost.
This delivers a whole new approach to config and policy management — one that’s descriptive or declarative, rather than procedural or imperative. Let’s take a closer look.
Anthos Config Management automatically synchronizes configurations and applies policies across multiple clusters, it provides you with a number of benefits:
- Simplify management: Anthos Config Management lets you define and deploy configurations and policies across environments, without having to build your own toolchain from scratch.
- Consistent configurations and policy management: Anthos Config Management provides an auditable and version-controlled system that manages the configuration of your organization’s clusters.
- Scalable across environments: Anthos Config Management centralizes the configuration and governance across environments, creating a scalable, automated, and reliable method for managing complex modern systems in production.
- Secure and compliant: With Anthos Config Management, platform administrators can reduce security risks. You can define a fully-customized set of policies and ensure that the policies are consistently applied across environments. Anthos Config Management also continuously monitors environments to ensure their desired configuration is in place and no violations of governance controls are present.
- Open source technologies: Anthos Config Management is based on Kubernetes and Cloud Native open source tools and projects, including Open Policy Agent Gatekeeper.
Components
You can use each of the Anthos Config Management components independently, but they are designed to work together:
Config Sync
Config Sync continuously reconciles your clusters to a central set of configurations that are stored in one or more Git repositories. This GitOps methodology lets you apply configuration consistently across clusters and environments with an auditable, transactional, and version-controlled deployment process.
Policy Controller
Policy Controller enables the enforcement of fully programmable policies that represent constraints on the desired state. These policies act as “guardrails” and prevent configurations from violating security and compliance controls. You can use these policies to actively block non-compliant API requests, or simply to audit the configuration of your clusters and report violations. Policy Controller is built from the Open Policy Agent Gatekeeper project and comes with a full library of pre-built policies for common security and compliance controls.
Config Controller
Config Controller is a hosted service to provision and orchestrate Anthos and Google Cloud resources. This component offers an API endpoint that can provision, actuate, and orchestrate Google Cloud resources as part of Anthos Config Management.
Config Controller is a hosted service to provision and orchestrate Anthos and Google Cloud resources. This component offers an API endpoint that can provision, actuate, and orchestrate Google Cloud resources as part of Anthos Config Management.
Hands-on Tutorial
By the end of part 3, you will have built a Kubernetes developer platform for a (fake) financial services company called Cymbal Bank, shown in the diagram below. Follow the setup process in the Git repo to build out the infrastructure and then deploy the services as per the directions.
Section 1: Installing Config Sync and Policy Controller
git clone https://github.com/kasiarun/build-a-platform-with-krm.git
cd 4-platform-admin/
export PROJECT_ID=[your-project-id]
export GITHUB_USERNAME=[your-github-username]Run the policy repo setup script from the 4-platform-admin/ directory:
./policy-repo-setup.shExpected output:
Compressing objects: 100% (9/9), done.
Writing objects: 100% (17/17), 1.29 KiB | 662.00 KiB/s, done.
Total 17 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/kasiarun/cymbalbank-policy
* [new branch] main -> mainInstall Config Sync and Policy Controller on all four GKE clusters
./install.shThis script does the following:
- Installs Config Sync on all four clusters. This is a set of workloads, running in each cluster, designed to sync configuration from the policy repo to the cluster automatically.
- Installs Policy Controller on all four clusters. This is a Kubernetes admission controller that can read custom policies from your policy repo.
Here, Last_Synced_Token is the git commit SHROT_SHA of your latest commit to the main branch of your cymbalbank-policy repo - you can verify this by cd-ing into your policy repo and running:
git logExpected output:
commit 5e068d0ff2128026368479342ff7f892dc964f8d (HEAD -> main, origin/main) Init - CymbalBank namespaces
So when you installed Config Sync and Policy Controller, what actually got deployed?
Switch to the dev cluster, and get the Pods in the config-management-system and gatekeeper-system namespaces
kubectx cymbal-dev
kubectl get pods -n config-management-system
kubectl get pods -n gatekeeper-systemExpected output:
NAME READY STATUS RESTARTS AGE
admission-webhook-6899f7fbd9-2zlvw 1/1 Running 0 14m
admission-webhook-6899f7fbd9-nskpn 1/1 Running 1 14m
reconciler-manager-6b785845c4-5gx47 2/2 Running 0 14m
root-reconciler-8b8889f49-jnnsg 3/3 Running 0 14mNAME READY STATUS RESTARTS AGE
gatekeeper-audit-76d8d7fb-dbnd7 1/1 Running 0 15m
gatekeeper-controller-manager-6bf5fdb68f-bftcz 1/1 Running 0 15m
The first set of workloads, 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 deploys those updated resources to the cluster. (Note that every cluster runs their own Config Sync, but all the clusters are synced to the same repo.)
The second set of workloads, in the gatekeeper-system namespace, run Policy Controller. (Policy Controller is based on an open-source project called Gatekeeper). These workloads help ensure that any resources entering the cluster - both through CI/CD or through Config Sync - adheres with any policies we set.
We’ll explore how both these tools work in the rest of this demo.
Now that all our clusters are synced to the same policy repo, we can get started on the first goal — ensuring KRM resource consistency across our multi-cluster environment.
Section 2: Keeping Resources in sync using Config Sync
You might be asking yourself why we just set up another repo to store KRM, and another mechanism — beyond the Cloud Build CI/CD we already have — to deploy KRM to our clusters. The answer has to do with the way Config Sync works. Unlike CI/CD, Config Sync is constantly making sure the Git resources are in sync on the cluster. Deployment doesn’t just happen on a build trigger — it’s a continuous reconciliation loop between what’s in Git, and what is deployed on the cluster.
Source: Config Sync documentation
What this means is that if a developer tries to manually delete a config resource from the cluster that lives in the cymbalbank-policy repo, Config Sync notices, and it will block that developer from doing so. If a bad actor gains access to the cluster and does successfully delete the resource, Config Sync will bring it back online. When the live state of the cluster diverges from the source-of-truth in Git, this is called configuration drift, and Config Sync is great at preventing that.
Further, Config Sync works really well for certain types of platform-level KRM resources that might apply to all the Cymbal bank teams — think authentication policies, or base-layer workloads for monitoring. CI/CD works well for application workloads that are tied to source code and pull requests. Both tools handle KRM, but they are complementary and as we’ll see later in this demo, they can be used together to powerful effect.
Let’s explore how we can use Config Sync to keep the same resources constantly deployed across all the Cymbal Bank clusters.
Get the frontend namespace in the cymbal-dev cluster
We created this namespace manually, but now it’s being managed by Config Sync.
kubectx cymbal-dev
kubectl get namespace frontend -o yamlExpected output (trimmed):
apiVersion: v1
kind: Namespace
metadata:
annotations:
config.k8s.io/owning-inventory: config-management-system_root-sync
configmanagement.gke.io/cluster-name: cymbal-dev
configmanagement.gke.io/managed: enabledYou can see that a set of new configmanagement annotations have been added to the existing namespace, including configmanagement.gke.io/managed: enabled. This annotation indicates that Config Sync is responsible for managing this resource, keeping it synced with the cymbalbank-policy repo.
Where did this resource come from? Let’s explore the structure of the policy repo.
Run the tree command on the newly-initialized cymbalbank-policy repo
tree cymbalbank-policy/Expected output:
.
└── namespaces
├── balancereader
│ └── namespace.yaml
├── contacts
│ └── namespace.yaml
├── frontend
│ └── namespace.yaml
├── ledgerwriter
│ └── namespace.yaml
├── loadgenerator
│ └── namespace.yaml
├── transactionhistory
│ └── namespace.yaml
└── userservice
└── namespace.yaml8 directories, 7 files
This repo is what’s called an unstructured repo in Config Sync. This means that we can set up the repo however we want to, with whatever subdirectory structure suits the Cymbal org best, and Config Sync will deploy all the resources in the subdirectories. The alternative for Config Sync is to use a hierarchical repo, which has a structure you must adhere to (for instance, with cluster-scoped resources in a cluster/ subdirectory).
By default, resources committed to a policy repo will be synced to all clusters that use it as a sync source. So here, each of the Cymbal Bank namespaces we’ve committed will be synced to the dev, staging, prod, and admin clusters, because each of those clusters is set up to sync from this repo.
Attempt to delete the frontend namespace from the dev cluster
kubectl delete namespace frontendExpected output:
error: You must be logged in to the server (admission webhook "v1.admission-webhook.configsync.gke.io" denied the request: requester is not authorized to delete managed resources)Here, Config Sync blocks us from doing so — this resource is managed by Config Sync, and it’s protected from errant kubectl commands.
You can see how we’re starting to work towards that goal of consistency across our Kubernetes environment — we define the resources we always want deployed to our clusters (in this case, a set of application namespaces), and Config Sync works hard on our behalf to make sure that’s always true.
We can also scope KRM resources to only apply to specific clusters. Let’s see how in part 2 of the series. See you there.
