IaC Code Analysis - Kubernetes Manifests
Static Analysis for Kubernetes Manifests Using KubeLinter
KubeLinter is a static analysis tool for Kubernetes YAML manifests and Helm charts, focusing on security best practices and production readiness. It identifies misconfigurations early in the development cycle and helps teams enforce policies for container security, access controls, and resource configurations.
KubeLinter uses checks, which are predefined rules that identify common security issues. These checks cover various areas such as the use of privileged containers, running containers as root, missing resource requests, and more. Find below a list of some checks:
| Check Name | Description | Enabled by Default |
|---|---|---|
dangling-service | Detects services without matching deployments. | ✅ Yes |
env-var-secret | Alerts on secrets stored in environment variables. | ✅ Yes |
run-as-non-root | Ensures containers do not run as root. | ✅ Yes |
privileged-container | Flags containers running in privileged mode. | ✅ Yes |
no-read-only-root-fs | Warns if the root filesystem is not read-only. | ✅ Yes |
no-liveness-probe | Detects containers without a liveness probe. | ❌ No |
no-readiness-probe | Detects containers without a readiness probe. | ❌ No |
mismatching-selector | Ensures deployment selectors match pod template labels. | ✅ Yes |
unset-memory-requirements | Flags containers missing memory requests/limits. | ✅ Yes |
unset-cpu-requirements | Flags containers missing CPU requests/limits. | ✅ Yes |
For the full list, visit the KubeLinter checks documentation. By default, KubeLinter enables a subset of these checks, but users can customize them by enabling, disabling, or modifying their behavior.
Checks are based on templates, which define reusable validation logic. A template provides a framework, while a check applies it with specific parameters. Users can create custom checks by modifying template parameters to fit their security policies. For example, a check enforcing the use of a specific service account could be based on a service-account template.
The following is an example of a service-account template:
- description: A regex specifying the required service account to match.
name: serviceAccount
negationAllowed: true
regexAllowed: true
required: true
type: string
KubeLinter allows organizations and teams to manage security policies declaratively using configuration files. This helps in defining and maintaining consistent enforcement of best practices across projects.
Policies can be customized using:
- Config files: Specify which checks to enable or exclude.
checks:
include:
- run-as-non-root
- no-privileged-containers
exclude:
- dangling-service
- Annotations: Used within Kubernetes manifests to document exceptions and justify policy violations.
apiVersion: v1
kind: Pod
metadata:
name: my-pod
metadata:
annotations:
ignore-check.kube-linter.io/privileged-container: "This container requires privileged DevSecOps in Practice
A Hands-On Guide to Operationalizing DevSecOps at ScaleEnroll now to unlock all content and receive all future updates for free.
