Feedback

Chat Icon

DevSecOps in Practice

A Hands-On Guide to Operationalizing DevSecOps at Scale

IaC Code Analysis - Kubernetes Manifests
70%

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 NameDescriptionEnabled by Default
dangling-serviceDetects services without matching deployments.✅ Yes
env-var-secretAlerts on secrets stored in environment variables.✅ Yes
run-as-non-rootEnsures containers do not run as root.✅ Yes
privileged-containerFlags containers running in privileged mode.✅ Yes
no-read-only-root-fsWarns if the root filesystem is not read-only.✅ Yes
no-liveness-probeDetects containers without a liveness probe.❌ No
no-readiness-probeDetects containers without a readiness probe.❌ No
mismatching-selectorEnsures deployment selectors match pod template labels.✅ Yes
unset-memory-requirementsFlags containers missing memory requests/limits.✅ Yes
unset-cpu-requirementsFlags 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 Scale

Enroll now to unlock all content and receive all future updates for free.