Security policy as a Word document
A typical technology organization has a security policy. It describes what is allowed and what is not. Container configuration requirements — no root privileges, defined resource limits, no images with the latest tag. Network requirements — no open ports without justification, encryption in transit. Deployment requirements — approval by an authorized person, automated tests, change logs.
The problem with a document: nobody verifies it at every deployment. A developer configuring a container in a hurry doesn’t always reach for a 40-page policy document. A code reviewer focuses on business logic, not security configuration parameters. An auditor will spot the violation — but only at the next audit, which might be a year away.
The space between policy and enforcement
This space — between what the policy says and what actually reaches production — is where security incidents are born. Not because anyone has bad intentions. Because human verification processes don’t scale with the speed of software delivery.
An organization that deploys dozens of times a day cannot manually verify every deployment’s compliance with security policy. Either verification is automated — or it doesn’t exist.
Policy-as-Code as a model shift
Policy-as-Code is an approach of encoding security policies as executable code and automatically verifying them at every deploy, every configuration change, every resource created in infrastructure.
Open Policy Agent (OPA, a CNCF project) is one of the most widely used engines for this purpose. It allows defining a policy (“no container can run as root”) and automatically verifying every Kubernetes resource before it starts. A policy violation results in a rejection — with a message describing what needs to change.
The result: policy stops being a document. It becomes a property of the system — enforced automatically, at every operation, without exceptions and without the possibility of being skipped due to forgetfulness or haste.
Where policy-as-code makes the most sense
The greatest value appears with controls that are objectively verifiable and high-risk: container security context configuration, secret access, network policies, base image requirements. These are controls where automated verification is both possible and critical.
Policies that require context and judgment — e.g., whether a given architectural decision is appropriate — remain the domain of human code review. Policy-as-Code doesn’t replace engineering thinking. It replaces those verifications that are mechanical, repetitive, and too important to depend on someone’s attention at any given moment.
Read also: