We are very pleased to partner with a Modern, Cloud Native, Zero Trust CNAPP innovator like AccuKnox. Zero Trust security is a Clint Health imperative ....
Generate Kyverno Admission Controller Policies with KubeArmor®
Look into the functions, security, and Zero Trust tokens of Kubernetes admission controllers. Let us walk through KubeArmor’s Discovery Engine, which provides full visibility and proactive security measures for fortified cluster protection. See how to strengthen your Kubernetes environment with advanced safeguards!
Reading Time: 3 minutes
Table of Contents
What are Kubernetes admission controllers?
Admission Controllers enforce semantic validation of objects during create, update, and delete operations. Kubernetes Admission controllers leverage admission webhooks which are HTTP callbacks. These receive admission requests before k8s resources are deployed such that the controllers can perform some actions such as security, compliance, and governance checks before admitting the resources. Admission controllers use validating and mutating webhooks (some extend to ValidatingAdmissionPolicy too) to control the operations performed through the kube-api server.
💡TL;DR
- Kubernetes admission controllers enforce semantic validation of objects during create, update, and delete operations.
- They leverage admission webhooks to perform security, compliance, and governance checks before admitting resources.
- These controllers are easy to integrate with existing clusters and highly configurable, enhancing their security posture.
- KubeArmor, a runtime security platform, can detect application behavior and generate admission controller policies based on the container or application behavior.
- It is recommended to run applications in the pre-production stage to gain visibility into application behavior and generate highly accurate policies.
Why is Kubernetes admission controller required?
Kubernetes admission controller can enforce custom policies that are not possible with Kubernetes RBAC or Pod Security Policies. Almost all Kubernetes admission controllers are easy to integrate with an existing cluster and being highly configurable, they can severely enhance security posture. Some notable policy examples are:
- Resource Limits
- Trusted Container Images
- Label Existence
- Security Context
- Ingress, Egress, and NetworkPolicy governance
How can KubeArmor runtime visibility enhance Kubernetes admission controller policies?
Admission controllers, as the name suggests, enforce policies at the time of admission. Consequently, administrators need to understand application behavior before enforcing policies to ensure that a mistake does not lead to downtime in application availability.
Runtime security platforms like AccuKnox and its OpenSource companion, KubeArmor can detect application behavior and generate admission controller policies based on the container or the application behavior. Administrators can deploy applications in the pre-production stage for AccuKnox/KubeArmor to collect runtime data and generate admission controller policies according to application behavior.
Zero Trust with service account token
For any pod deployed on the cluster, the service account token is automatically mounted onto that container unless explicitly setting automountServiceAccountToken: false . Unless explicitly specified, the default service account token of the particular namespace is mounted onto the pod. Though the permissions of the default token are highly restricted, these can be enhanced by binding it with some role or clusterrole.
What attacks are possible with service account tokens?
“Every possible attack that can be performed after accessing the kube-api server”
The service account token is used to access the kube-api server. The attack surface varies according to the role assigned to the service account token. After getting the service account token, the attacker can impersonate the application and access the API server to even perform crypto-jacking attacks.
Disallow mounting of unused tokens with AccuKnox®
While access to the service account token can be restricted at runtime using KubeArmor (https://docs.kubearmor.io/kubearmor/use-cases/use-cases#block-access-to-k8s-service-account-token), it is better to stop auto-mounting of service account tokens if the container does not access it.
How does it work?
Discovery Engine works as a plug-in with KubeArmor. Discovery Engine acquires system logs from KubeArmor Relay which are processed and analyzed to check whether there are any accesses to the service account token mounted into the container.
Discovered policy uses labels to match on the pod or the pod controller. Discovery Engine stores these policies internally inside a database which are updated and deleted as per application behavior. It is suggested to run applications in the pre-production stage, trying to hit maximum code points so that KubeArmor has maximum visibility into application behavior and highly accurate policies can be generated.
These discovered policies will then prevent bad configurations at the admission time only, enhancing the security posture and not leaving it for runtime pre or post attack mitigation.
Note: Only Kyverno policies are recommended at present. The framework can be extended to generate OPA (Open Policy Agent) Rego policies or KubeWarden policies.
Demo Time ⏳
I. Download and install karmor cli-tool
$ curl -sfL http://get.kubearmor.io/ | sudo sh -s — -b /usr/local/bin
II. Install KubeArmor
$ karmor install
III. Install Discovery Engine
$ kubectl apply -f
https://raw.githubusercontent.com/kubearmor/discovery-engine/dev/deployments/k8s/deployment.yaml
IV. Create an nginx deployment
$ kubectl create deploy nginx –image=nginx –replicas=1
V. Let’s try to recommend policies using karmorCLI, nginx image does not access the service account token.
- Schedule 1:1 Demo
- Product Tour
On an average Zero Day Attacks cost $3.9M
4+
Marketplace Listings
7+
Regions
33+
Compliance Coverage
37+
Integrations Support
