Hello everyone! For those of you exploring the world of Kubernetes, today I will provide an easy and detailed explanation of two powerful tools that can elevate your cluster’s security and stability: AdmissionConfiguration and ImagePolicyWebhook.
๐ Prologue: Why do we need these?
In a Kubernetes cluster, you can easily deploy applications with commands like kubectl apply. It’s incredibly convenient! But here, we need to ask ourselves a question:
“Are all container images deployed to the cluster truly safe and trustworthy?” ๐ค
What if a developer accidentally uses an unverified external image or deploys an image with the vulnerable :latest tag? To prevent such problems in advance and protect our cluster, we need a Gatekeeper. The features I’m introducing today fulfill precisely that role!
1. The Identity of the Gatekeeper: What is an Admission Controller?
The first fundamental concept to understand is the Admission Controller. As the name suggests, it ‘controls admission’.
An Admission Controller is a plugin that intercepts all requests coming into the Kubernetes API server and performs additional validation or modification. Since all operations, such as a user creating a Pod or updating a Service, go through the API server, placing a gatekeeper here allows us to control everything entering the cluster.
Admission Controllers are broadly divided into two types:
- โ๏ธ Mutating Admission Webhook: Modifies or changes incoming requests. For example, you can make it so that a sidecar container is always added when a specific Pod is created.
- โ Validating Admission Webhook: Validates incoming requests and rejects them if they do not conform to policy. For example, you can create a rule that all Pods must include an owner label.
Today’s protagonist, ImagePolicyWebhook, is a type of Validating Admission Webhook.
2. Gatekeeper Configuration File: AdmissionConfiguration ๐
So, how do we configure and manage these smart gatekeepers (Admission Controllers)? That’s where the AdmissionConfiguration file comes in.
AdmissionConfiguration is a configuration file that defines which admission control plugins kube-apiserver should use, in what order, and how. It’s like a set of instructions for a club bouncer, telling them, “Only people on this list are allowed in today!”
Through this file, we can connect external webhooks that we’ve created ourselves, in addition to the built-in admission controllers.
Key Components
Below is a simple example of an AdmissionConfiguration file:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook # Name of the admission controller to use
configuration:
imagePolicy:
kubeConfigFile: /path/to/webhook/kubeconfig.yaml # Authentication information for the webhook server
allowTTL: 50 # Cache TTL (seconds)
denyTTL: 50
retryBackoff: 500 # Retry interval (milliseconds)
defaultAllow: true # Whether to allow by default if webhook call fails- plugins: Here we define the list of admission controllers we want to enable.
- name: Specifies the name of the plugin to enable. Our protagonist, ImagePolicyWebhook, is visible here.
- configuration: This section defines the detailed settings for the plugin. It includes information on how to connect to the webhook server (kubeConfigFile), among other things.
By passing this configuration file as a kube-apiserver runtime argument (–admission-control-config-file), the API server reads this file and formally appoints the specified webhook as the cluster’s ‘gatekeeper’.
3. Image Expert: ImagePolicyWebhook ๐ฎโโ๏ธ
Now, it’s finally time to learn about the core component: ImagePolicyWebhook!
As its name suggests, this webhook is a Validating Admission Webhook specialized in examining policies related solely to container images. It’s like a professional police officer meticulously scrutinizing every container image a Pod intends to use when it’s created or updated in the cluster.
Why is ImagePolicyWebhook powerful?
- Enforce specific registries: You can strengthen security by enforcing the use of approved registries, such as “Our company can only use images from private-registry.mycorp.com!”
- Prohibit :latest tag: To ensure stability, you can mandate the use of explicit version tags (e.g., nginx:1.21.6) and prevent the use of unpredictable :latest tags.
- Image signature verification: You can enforce that only trusted images signed with tools like Notary are deployed.
How it works โ๏ธ
The operational flow of ImagePolicyWebhook is as follows:
- ๐งโ๐ป User Request: A developer sends a Pod creation request including an image. (kubectl apply -f my-pod.yaml)
- โก๏ธ API Server Reception: The kube-apiserver receives this request.
- ๐ค Policy Check: The API server looks at the AdmissionConfiguration and determines, “Ah, I need to call ImagePolicyWebhook!”
- ๐ Webhook Call: The API server packages the image information requiring inspection into an ImageReview object and sends an HTTP POST request to the external webhook server (a server we implement ourselves).
- ๐ง Webhook Server Review: The webhook server receives the ImageReview request, compares the image name, tag, etc., with its internal policies, and decides whether to allow it.
- ๐/๐ Result Transmission: The webhook server sends the review result back to the API server. ({“allowed”: true} or {“allowed”: false, “reason”: “Only internal registry images are allowed.”})
- โ /โ Final Decision: The API server reviews the webhook’s response and either finally approves the request or rejects it with an error message to the user.
๐ฌ Conclusion: An Essential Gateway for a Secure Cluster
In summary, AdmissionConfiguration is the configuration guide that tells us how to deploy and operate our cluster’s gatekeepers (admission controllers), and ImagePolicyWebhook is the strict image expert among them, specializing in scrutinizing container images to ensure cluster security.
By using these two together, you can go beyond simply deploying applications and establish a robust security system that ensures “only safe and trustworthy applications are deployed according to defined rules and policies.” This is a core part of stable cluster operation and the DevSecOps culture.
How about setting up a reliable gatekeeper for your cluster now?
Kubernetes, AdmissionControl, ImagePolicyWebhook, Security, K8s, DevSecOps, Policy, ์ฟ ๋ฒ๋คํฐ์ค, ๋ณด์
Leave a Reply