In today's cloud-native environment, managing policies at scale is crucial for maintaining security, compliance, and operational consistency. Google Cloud Kubernetes Engine (GKE) offers robust tools for policy enforcement, with Policy Controller being a key component. This article will guide you step-by-step through implementing a Policy Controller in GKE. Note: Policy Controller is available if you use Google Kubernetes Engine (GKE) Enterprise edition.

Table of Contents

1. Introduction to Policy Controller

2. Prerequisites

3. Enabling Policy Controller

4. Install Policy Controller

5. Sync Cluster With Fleet Setting to have Policy Controller

6. Verify Template Library of policy controller is Installed

7. Testing Constraint Policies

8. Auditing Using Constraint

9. Conclusion

1. Introduction to Policy Controller

Policy Controller is a Kubernetes admission controller that uses Open Policy Agent (OPA) to enforce policies. It ensures that all changes to your Kubernetes resources comply with specified policies before they are applied. This helps in maintaining security, compliance, and best practices across your clusters.

2. Prerequisites

Before we begin, ensure you have the following:

• A Google Cloud Platform (GCP) account

• Google Cloud SDK installed on your local machine

• kubectl installed on your local machine

• Basic understanding of Kubernetes and GKE

3. Enabling Policy Controller

• From Console -> Search Bar -> Type "Enabled API & Service"

• Find and enable Anthos Policy Controller API

4. Install Policy Controller

Policy Controller can be installed in fleet settings level, make sure you have GKE Enterprise, to install policy controller:

• Enable Policy Controller in fleet setting

  1. From Console -> Kubernetes Engine -> Feature Manager -> configure

     • 

  2. Under Kubernetes Engine Tab -> Policy -> Settings -> Configure Fleet Setting

     • 

  3. Feature Manager -> Customize Fleet Setting

     • 

  4. Make sure that Template Library is installed in fleet.

     • 

5. Sync Cluster With Fleet Setting to have Policy Controller

After we have enabled policy controller to Fleet Settings Level, we can attach cluster that we want to have policy controller:

• Sync Cluster to have Policy Controller

  1. From Console -> Kubernetes Engine -> Under Posture Management -> Policy -> Sync With Fleet Settings

     • 

  2. Under Kubernetes Engine Tab -> Feature Manager -> Check Desired Cluster -> Sync To Fleet Setting -> Make sure in sync with fleet is "yes"

     • 

6. Verify Template Library of policy controller is Installed

Policy Controller is a Kubernetes admission controller that uses Open Policy Agent (OPA) to enforce policies. Google Offers various of constrain template available for us. To Make sure Steps 4.4 is installed, use the command below:

$ kubectl get constrainttemplates

7. Testing Constraint Policies

For this time we will use "K8sRequiredLabels" that applied in namespaces for testing policies. The following constraint, called k8s-ns-must-have-label, invokes a constraint template called K8sRequiredLabels, which is included in the constraint template library provided by Google. The constraint defines parameters that the constraint template uses to evaluate whether namespaces have the "istio-injection" label set to some value.

#k8s-ns-must-have-label.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: k8s-ns-must-have-label
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Namespace
  parameters:
    labels:
    - key: istio-injection
    message: you must provide labels istio-injection

$ kubectl apply -f k8s-ns-must-have-label.yaml

To verify:

$ kubectl get constraint
#output
NAME                                                                 ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/k8s-ns-must-have-label   deny                 8

To Testing, we can create namespace and the error will show up such as following command.

$ kubectl create ns stg-test
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [k8s-ns-must-have-label] you must provide labels istio-injection

8. Auditing Using Constraint

Policy Controller constraint objects enable you to enforce policies for your Kubernetes clusters. To help test your policies, you can add an enforcement action to your constraints. You can then view violations in constraint objects and logs.

Types of enforcement actions

There are three enforcement actions: deny, dryrun, and warn.

9. Conclusion

Using a policy controller in Google Kubernetes Engine (GKE) offers several significant benefits, enhancing the security, compliance, and management of your Kubernetes clusters. Here's a summary of the key advantages:

• Enhanced Security and Compliance

• Centralized Policy Management

• Reduces the manual effort required to audit and enforce policies

In conclusion, using a policy controller in GKE provides robust security, ensures compliance, and improves operational efficiency by automating policy enforcement and centralizing policy management. This results in a more secure, compliant, and well-governed Kubernetes environment.

The Argo CD Image Updater can check for new versions of the container images that are deployed with your Kubernetes workloads and automatically update them to their latest allowed version using Argo CD.

Usage is simple: You annotate your Argo CD Application resources with a list of images to be considered for update, along with a version constraint to restrict the maximum allowed new version for each image. Argo CD Image Updater then regularly polls the configured applications from Argo CD and queries the corresponding container registry for possible new versions. If a new version of the image is found in the registry, and the version constraint is met, Argo CD Image Updater instructs Argo CD to update the application with the new image.

There are 4 update strategies available for Argo CD image updater:

• semver: update to highest allowed version according to given image constraint,

• latest: update to the most recently created image tag,

• name: update to the last tag in an alphabetically sorted list

• digest: update to the most recent pushed version of a mutable tag

And for this tutorial, we will use digest update strategies.

Installation

You can install the Image Updater alongside Argo CD, typically as a separate pod within the same namespace as Argo CD:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml

Usage

1. Authenticate to Artifact Registry

   To fully utilize the Argo CD Image Updater, it’s crucial to configure it to connect with your image registry properly, especially if you are using private registries or private repositories on public registries. Make sure you have service account key file with json format with appropriate permissions. Please read Create Service Account for more information.

    cat sa-gcr-prd.json | docker login -u _json_key --password-stdin https://asia-southeast2-docker.pkg.dev
   

   

   The second step is to create secret from docker config file, so the ArgoCD Image Updater can use that for scanning dan watch every time there are new images pushed. Mostly docker saved the credential to authenticate with Registry in /home/user/.docker/config.json so you can take that file for generating secret.

     apiVersion: v1
    kind: Secret
    metadata:
      name: gcr-prd
      namespace: argocd
    data:
      .dockerconfigjson: <base64 encoded dockerconfigjson>
    type: kubernetes.io/dockerconfigjson
   

2. Configuring ArgoCD Image Updater

   After setting up the credentials, include them in the ArgoCD Image Updater’s configurationto authenticate with the image registry.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app.kubernetes.io/name: argocd-image-updater-config
        app.kubernetes.io/part-of: argocd-image-updater
      name: argocd-image-updater-config
    data:
      git.commit-message-template: |
        Auto-commit by Argocd Image Updater [{{ .AppName }}]
   
        {{ range .AppChanges -}}
        updates image {{ .Image }} tag '{{ .OldTag }}' to '{{ .NewTag }}'
        {{ end -}}
      log.level: debug
      registries.conf: |
        registries:
        - name: asia-southeast2-docker.pkg.dev
          api_url: https://asia-southeast2-docker.pkg.dev
          ping: no
          credentials: pullsecret:argocd/gcr-prd #namespaceName/secretName
          defaultns: library
          prefix: asia-southeast2-docker.pkg.dev
   

   As i mentioned above, we annotate Argo CD Application resources with a list of images to be considered for update, and here is the example.

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: your-argocd-app-name
      namespace: argocd
      labels:
        key: value
      finalizers:
        - resources-finalizer.argocd.argoproj.io
      annotations:
        notifications.argoproj.io/subscribe.on-deployed.slack: report-argocd
        notifications.argoproj.io/subscribe.on-sync-failed.slack: report-argocd
        argocd-image-updater.argoproj.io/image-list: frontend=asia-southeast2-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:tag,backend=asia-southeast2-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:tag
        argocd-image-updater.argoproj.io/frontend.update-strategy: digest
        argocd-image-updater.argoproj.io/backend.update-strategy: digest
        argocd-image-updater.argoproj.io/write-back-method: git
    spec:
      project: your-argocd-project-name
      source:
        repoURL: https://gitlab.com/your-gitops-repository/repository.git
        targetRevision: your-branch-name
        path: target-folder-git
      destination:
        server: https://your-cluster-external-endpoint
        namespace: your-target-deployed-to
      syncPolicy:
        automated:
          selfHeal: true
          prune: true
   

3. Once everything is applied, Argo CD Image updater will be able to do this kind of commit to your repository, and Argo CD will do the rest:

   

   If you are interested in testing it, I hope this post showed you how easy it is to configure Argo CD Image Updater for your infrastructure. 😄