# Kubernetes Deployment Review Checklist

> **Intro:** This checklist gives a practical review flow for workload manifests, Helm charts, and deployment policy assumptions.

## Best time to use this checklist

Use it when a new workload is introduced, a chart changes materially, or a service gains new privileges, exposure, or data sensitivity.

## Stop-the-line conditions

* privileged or near-privileged workload settings without strong justification;
* service account or cloud identity with excessive privilege;
* missing network policy or namespace isolation where it matters;
* no useful logs, runtime alerts, or audit trail for a sensitive workload.

## Text-first review prompts

* What service account or workload identity does the workload run as?
* Is the pod security context using safe defaults for user, filesystem, capabilities, and privilege escalation?
* What network paths can reach the workload, and where can it reach out?
* What secrets, config, and external systems does the workload depend on?
* What runtime or audit signals would show suspicious behavior later?
* What admission or policy controls would stop dangerous manifest patterns?

## Evidence table

| Control area   | What to verify                                            | Typical evidence                           |
| -------------- | --------------------------------------------------------- | ------------------------------------------ |
| Identity       | Service account and cloud identity are scoped correctly   | manifest, IAM mapping                      |
| Pod security   | Security context avoids avoidable privilege               | deployment YAML, policy result             |
| Networking     | Ingress, egress, and namespace boundaries are intentional | network policy, service config             |
| Secrets/config | Sensitive material is injected safely and minimally       | secret refs, external secrets              |
| Observability  | Audit, runtime, and service telemetry exist               | dashboard, Falco/Tetragon/KubeArmor config |

## Common misses

* assuming cluster-level guardrails remove the need to review workload manifests;
* forgetting that egress to metadata or internal services can become the real exploit path;
* using the default service account casually;
* treating a passing deployment as the same thing as a secure deployment.

## Related pages

* [Kubernetes Baseline and Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)
* [Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md)
* [Kubernetes Network Policy Patterns](/cloud-kubernetes-and-infrastructure-security/index-1/network-policy-patterns.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-3/kubernetes-deployment-review-checklist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.