Infrastructure as Code Using Config Controller in GCP

Config Controller and Config Connector

The modern Cloud Infrastructure is managed using Infrastructure as Code (IaC) approach. IaC is the process of managing Infrastructure using code instead of by manual process.

We are familiar with a lot of IaC Tools like Terraform, AWS Cloud Formation, Azure Resource Manager, Cloud Deployment Manager etc.

Today, we will be looking into the IaC approach using Config Controller and Config Connector in GCP.

Why IaC?

IaC Allows developers with efficient and faster development lifecycle by eliminating manual processes. A code-based approach makes it easier to get more done in less time.

Photo by Clément Hélardot on Unsplash

Config Controller

Config Controller is a component of Google Cloud’s Config Management service, which enables Infrastructure as Code (IaC) in Google Cloud Platform (GCP). Config Controller allows you to define and manage your GCP resources using declarative configuration files. It offers an API endpoint that can provision, actuate, and orchestrate Google Cloud resources as part of ACM (Anthos Config Management).

Config Controller leverages Config Connector, which maps resources using the Kubernetes Resource Model (KRM) to their Google Cloud counterparts by making the necessary Google Cloud API calls. It also includes Config Sync that connects to a Git repository, making configuration changes as easy as git push.

Config Connector

Config Connector is a Kubernetes add-on which allows to manage Google Cloud Resources using Kubernetes. It provides a set of CRD’s (Custom Resource Definitions) and controllers which allows Kubernetes to manage resources within GCP.

It also provides way to manage existing Google Cloud Resources and use Kubernetes secrets to provide sensitive data such as passwords.

Config Sync

We would have heard of GitOps approach in IaC where in Git repositories act as the single source of truth to deliver the Infrastructure. Config Sync is a GitOps service offered as part of Anthos.

Advantages of Config Controller Over Terraform

Config Controller uses Config Sync GitOps approach, the single source of truth for Managing Infrastructure. It also adds the continuous reconciliation of the resources with the Single source of Truth thus ensuring compliance and enforcement.

If policy enforcement and compliance are critical, Config Controller’s focus on enforcing desired state and built-in monitoring can be advantageous.

If you are already into Kubernetes or planning to start with Kubernetes, Config Controller’s native integration with Kubernetes can simplify your workflows.

Config Controller provides built-in support for resource monitoring, configuration drift detection, and policy enforcement.

In short, if you are already using Kubernetes or prioritize policy enforcement and compliance, Config Controller’s Kubernetes-native approach could be beneficial.

Setup Config Controller

Config Controller supports both Standard and Autopilot Cluster Types. To setup a config controller cluster open the cloud shell within a GCP project where you must do the following:

1. Enable API’s

gcloud services enable krmapihosting.googleapis.com  container.googleapis.com  cloudresourcemanager.googleapis.com  serviceusage.googleapis.com

2. Create the Controller instance by running the below command. Please note that this command would take upto 15–20 mints to create the cluster.

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION

Currently the Config controller cluster is supported only in few regions.

3. Grant permission to Config Controller to manage resources

By default when you create a Config Controller Cluster, a service account is created with config-control namespace. Retrieve the service account and export to an environment variable after which assign the required permissions depending on the resources you would want to manage within the GCP Project.

export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
    -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "ROLE" \
    --project PROJECT_ID

Here you can give roles/owner if you would want to manage all the resources within your project to be managed by Config Controller cluster.

4. Create a GCP resource with Config Connector

Once the cluster is setup, you can create a CRD for any resource as below in a yaml file.

#cloud-storage.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  annotations:
    cnrm.cloud.google.com/force-destroy: "false"
  labels:
    label-one: "value-one"
  # StorageBucket names must be globally unique. Replace ${PROJECT_ID?} with your project ID.
  name: ${PROJECT_ID?}-sample
  namespace: config-control
spec:
  lifecycleRule:
    - action:
        type: Delete
      condition:
        age: 7
        withState: ANY
  versioning:
    enabled: true
  uniformBucketLevelAccess: true

5. Apply the manifest using kubectl:

kubectl apply -f cloud-storage.yaml

6. Check if the resource is created

gcloud storage ls

Config Controller benefits from the Kubernetes ecosystem and community. You can leverage various Kubernetes operators, controllers, and custom resources developed by the community to extend the functionality of Config Controller and manage a wide range of GCP resources.

I would love to do a write up on Setting up Landing Zone’s using Google Blueprints. Stay Tuned! Happy Learning!