Implementing Policy Controller in Google Cloud Kubernetes Engine (GKE)
Introduction
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
Introduction to Policy Controller
Prerequisites
Enabling Policy Controller
Install Policy Controller
Sync Cluster With Fleet Setting to have Policy Controller
Verify Template Library of policy controller is Installed
Testing Constraint Policies
Auditing Using Constraint
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
From Console -> Kubernetes Engine -> Feature Manager -> configure
Under Kubernetes Engine Tab -> Policy -> Settings -> Configure Fleet Setting
Feature Manager -> Customize Fleet Setting
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
From Console -> Kubernetes Engine -> Under Posture Management -> Policy -> Sync With Fleet Settings
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.
deny | dryrun | warn |
default enforcement action. It's automatically enabled, even if you don't add an enforcement action in your constraint. Use deny to prevent a given cluster operation from occurring when there's a violation. | lets you monitor violations of your rules without actively blocking transactions. You can use it to test if your constraints are working as intended, prior to enabling active enforcement using the deny action. Testing constraints this way can prevent disruptions caused by an incorrectly configured constraint. | similar to dryrun, but also provides an immediate message about the violations that occur at admission time. |
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.
Subscribe to my newsletter
Read articles from Gilang Adhi Wibowo directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by