Infrastructure as code for Kubernetes means the desired state of your cluster is written in files, kept in version control, reviewed like software and applied by tooling instead of by hand. It gives you history, review and repeatability. It also puts secrets and permissions into a place where mistakes spread fast.
What does Kubernetes already give you?
Kubernetes is declarative by design. The Kubernetes documentation on declarative management describes keeping object configuration in files, "typically stored in source control, such as Git", and using kubectl apply to create and update objects as needed. The same page describes kubectl diff, which previews what an apply would change before you run it.
The docs also distinguish live configuration, the values the cluster holds in its store, from the object configuration files you wrote. The gap between the two is where drift lives. Someone edits a deployment with an emergency command, the file in Git no longer matches, and the next apply either reverts the fix or hides it.
What goes in the repository?
Manifests for workloads, services, network policies, role bindings, resource quotas and namespaces. Cluster-level pieces such as node pools or managed cluster settings usually live in a separate tool and repository, because they change on a different rhythm and need different reviewers.
What does not go in: secret values. A base64 string in a manifest is not encryption. Store a reference to a secret manager, or an encrypted form that only the cluster can open, and keep the plain value out of history. Git remembers everything, so a leaked value stays leaked after a delete.
Where do the risks sit?
Permissions in code. Role bindings are the most security-sensitive files you have. A pull request that grants a cluster-wide role to a service account should get a stricter review than a change to a replica count.
Images. NIST SP 800-190, the application container security guide, covers image risks, registries, orchestrator and host. Pin images by digest where you can, so what you reviewed is what runs.
Pipeline power. Whatever applies the manifests holds broad cluster rights. Protect the branch, require reviews and keep the apply credentials short-lived.
Defaults. A workload without a security context or a network policy is allowed more than it needs.
What does a constructed review catch?
A team reviews a pull request titled "fix crash loop". It changes one line: the container now runs as root, because a file write was failing. A reviewer with a checklist asks why the app writes to the image filesystem at all. The real fix is a writable volume mounted at the one path it needs. The checklist item was "does any change add privilege".
How do you handle emergencies?
Sooner or later someone must fix production at night with a direct command. Plan for it. Allow a break-glass path with its own account, log it, and require that the change is copied back into Git within a set time, such as the next working day. Without that rule, the repository and the cluster slowly stop matching, and the next automated apply may undo the fix without warning.
Drift detection helps here. A scheduled comparison between live state and Git turns "someone changed something" into a ticket with a name on it.
How to check or apply this
- Put all workload manifests in version control, with one source of truth per environment.
- Run
kubectl diffin your pipeline and attach the output to the pull request. - Detect drift: compare live state to Git on a schedule and alert when they differ.
- Block plain secrets from the repository with a pre-commit or pipeline scan.
- Require two reviewers for role bindings, network policy and anything that adds privilege.
- Scan manifests against a policy set before merge: no privileged containers, no host paths, resource limits present.
- Scan images and dependencies in the same pipeline. Safeguard's policy gates and SBOM and dependency scanning can fit this step, failing a build before the apply.
Quick check
Is YAML in Git enough to call it infrastructure as code?
Only if the files are the source of truth. If people also change the cluster by hand, you have files and drift, not control.
Are base64 values in a Secret manifest safe in Git?
No. Base64 is an encoding, not encryption. Keep secret values out of the repository.
Sources
- Kubernetes documentation: Declarative Management of Kubernetes Objects
- NIST SP 800-190, Application Container Security Guide
Last reviewed: 18 October 2026.
