> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Static Analysis of User Workloads

> Explains using static analysis tools to detect and fix security misconfigurations in Kubernetes manifests early in development and CI pipelines

In this lesson we explain how to catch security misconfigurations in Kubernetes resource definition files before they ever reach the cluster. Static analysis examines manifests (YAML/JSON) as soon as they are written — before `kubectl apply` or any admission controller runs — enabling earlier feedback, faster remediation, and safer CI/CD pipelines.

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/WWXuSSf_CvRt0mlY/images/Certified-Kubernetes-Security-Specialist-CKS/Supply-Chain-Security/Use-Static-Analysis-of-User-Workloads/static-analysis-user-workloads-slide.jpg?fit=max&auto=format&n=WWXuSSf_CvRt0mlY&q=85&s=c439651860fbc6ca3bda616b91d2de82" alt="A presentation slide titled &#x22;Static Analysis of User Workloads&#x22; with a dark blue curved panel on the right showing a white icon of scales and document sheets." width="1920" height="1080" data-path="images/Certified-Kubernetes-Security-Specialist-CKS/Supply-Chain-Security/Use-Static-Analysis-of-User-Workloads/static-analysis-user-workloads-slide.jpg" />
</Frame>

## Why perform static analysis?

When a user submits a Pod creation request, the control plane and configured admission controllers may accept, mutate, or reject the request. However, by the time that happens the manifest has already been written and applied. Static analysis moves policy and security checks earlier into the development workflow so problems are found:

* Immediately after the manifest is authored (IDE, editor, pre-commit).
* During CI build and test stages (pull request validation).
* Before any resource is pushed to the cluster.

This shift-left approach reduces the cost and risk of fixing security issues and enforces standards consistently across teams.

## Example: a risky Pod manifest

Below is a simple Pod manifest that intentionally includes multiple security concerns:

```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu
      command: ["sleep", "3600"]
      securityContext:
        privileged: true
        runAsUser: 0
        capabilities:
          add: ["SYS_ADMIN"]
  volumes:
    - name: data-volume
      hostPath:
        path: /data
        type: Directory
```

Common security issues in this manifest:

* `privileged: true` grants highly elevated privileges to the container and is generally high-risk.
* `runAsUser: 0` runs the process as root inside the container.
* Adding capability `SYS_ADMIN` expands kernel-level permissions.
* `hostPath` exposes the node filesystem to the Pod, enabling host-level access.

Static analysis tools flag these problems early so developers can fix them before deployment.

<Callout icon="lightbulb" color="#1CB2FE">
  Static analysis helps catch misconfigurations and enforce policies before resources are submitted to the cluster, reducing the risk and cost of fixing issues later in the pipeline.
</Callout>

## Typical findings, risk classification, and remediation

| Setting / Finding | Risk Level | Example remediation |
| - | - | - |
| `privileged: true` | High | Remove `privileged` or require a Just-In-Time approval process; use PSP/PSA or OPA Gatekeeper to block. |
| `runAsUser: 0` | High | Set `runAsNonRoot: true` or pick a non-root UID with `runAsUser: <uid>`. |
| `capabilities: add: ["SYS_ADMIN"]` | High | Avoid adding powerful capabilities; use least-privilege; drop all capabilities then add explicitly required ones. |
| `hostPath` volumes | High | Replace with network-attached volumes (PVCs) or restrict `hostPath` usage via policy. |
| Missing resource limits | Medium | Define `resources.requests` and `resources.limits` for CPU/memory. |
| Image tag `latest` or unpinned image | Medium | Pin image digests or use immutable tags, and scan images for vulnerabilities. |

## Lightweight static analysis: kubesec

kubesec ([https://kubesec.io](https://kubesec.io)) is a simple tool that scores Kubernetes manifests and explains findings. It provides a numeric score and detailed guidance for each issue it detects, which makes it easy to prioritize fixes.

Ways to use kubesec:

* Install the `kubesec` CLI and scan local files.
* Use the publicly hosted API at `https://v2.kubesec.io/scan`.
* Run a local `kubesec` HTTP server to integrate with local tooling.

Example commands:

```bash theme={null}
# Scan a local file with the kubesec binary
$ kubesec scan pod.yaml

# Post the manifest to the public kubesec API and get analysis
$ curl -sSX POST --data-binary @"pod.yaml" https://v2.kubesec.io/scan

# Run a local kubesec HTTP server on port 8080 (background)
$ kubesec http 8080 &
```

When kubesec completes an analysis it lists issues, explains their significance, and returns a score that helps prioritize remediation. Integrate such checks into pre-commit hooks, CI pipelines, or IDE extensions so manifests are validated before being applied to a cluster.

## Other useful static-analysis tools and integrations

| Tool | Primary focus | Notes / Links |
| - | - | - |
| kube-linter | Policy and best-practice checks | Good for CI and PR checks — [https://github.com/stackrox/kube-linter](https://github.com/stackrox/kube-linter) |
| kube-score | Scoring and suggestions | Focuses on Pod/Deployment best practices — [https://github.com/zegl/kube-score](https://github.com/zegl/kube-score) |
| conftest | Policy testing with Rego | Use for custom policies and tests — [https://www.conftest.dev/](https://www.conftest.dev/) |
| OPA Gatekeeper / OPA | Admission-time enforcement using Rego policies | Enforces policies inside the cluster — [https://www.openpolicyagent.org/](https://www.openpolicyagent.org/) |

## Where to integrate static analysis

* Local development: editor/IDE plugins or pre-commit hooks (faster feedback).
* Continuous Integration: block pull requests with failing checks.
* Artifact scanning: validate rendered manifests from Helm, Kustomize, or templating pipelines.
* Developer platforms: embed checks in self-service portals and developer onboarding.

## Recommended workflow

1. Add static checks in the developer’s IDE and pre-commit hooks.
2. Fail builds in CI when critical issues are detected.
3. Enforce cluster-level policies with OPA Gatekeeper or similar admission controllers.
4. Continuously scan images and artifacts in your supply chain.

## References

* kubesec: [https://kubesec.io](https://kubesec.io)
* Open Policy Agent: [https://www.openpolicyagent.org/](https://www.openpolicyagent.org/)
* kube-linter: [https://github.com/stackrox/kube-linter](https://github.com/stackrox/kube-linter)
* kube-score: [https://github.com/zegl/kube-score](https://github.com/zegl/kube-score)
* conftest: [https://www.conftest.dev/](https://www.conftest.dev/)

That covers the essentials of static analysis for Kubernetes manifests and practical ways to adopt these checks across your development lifecycle.

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/certified-kubernetes-security-specialist-cks/module/e4511664-185f-4204-9aa2-b4250cbadf84/lesson/1950504d-1bea-4ef0-a92c-683f9c5a0c23" />

  <Card title="Practice Lab" icon="flask-conical" cta="Learn more" href="https://learn.kodekloud.com/user/courses/certified-kubernetes-security-specialist-cks/module/e4511664-185f-4204-9aa2-b4250cbadf84/lesson/11566885-cd7c-468d-a321-5d9d6fed5f46" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.