CNPE — Cloud Native Platform Engineer
Where Will You Enforce Policy
One-line summary
A pipeline handles quick feedback, admission handles enforcement on API requests, and continuous scanning handles discovering violations in resources that already exist. The fact that a policy exists is different from the fact that a real request was checked.
Why one place is not enough
An example scenario: a payments team's CI rejects unsigned images. But if an operator deploys through another path, that CI does not run. Conversely, if you have only admission, you meet the error only after the build is finished. Workloads that are already running are also not automatically corrected just because you created a new policy.
You connect the three places, but you do not copy the same check three times. You manage the version of the shared rules and the exception list, and at each place you keep a record of what was checked as input. Do not look only at the deployment success rate; also look at the number of targets in scope, the number of violations, check errors, and exception expirations.
How it works
Allowing requests and scanning the current state
| Place | Evidence to check | What this alone does not tell you |
|---|---|---|
| CI | The digest of the checked target, the rule version, the exit code | API requests that bypassed CI |
| Admission | The target request, the scope of application, the allow and reject results | Current violations of resources created before the policy was introduced |
| Continuous scanning | The scan time, the total number of targets, the list of violations | Whether the next request will necessarily be rejected |
The guarantee of admission holds within the matched requests and the configured scope. Check namespaceSelector, the resource and operation selection, and even exceptions and webhook error handling. A webhook's failurePolicy: Ignore lets a call error be ignored and proceed. It does not mean it allows what the webhook explicitly rejected with a normal response. Fail rejects even on errors, so you must design availability and the recovery path together. Kubernetes dynamic admission
Validation comes after mutation. If mutation filled in a required label, validation can check the changed object and allow it. This does not mean validation did not run. Validation is the place that checks whether the final object satisfies the rules.
Policy Audit mode and the API audit log are different
A policy engine's Audit mode observes violations and is used to calculate the impact of introduction. You must check the feature and the scan scope for existing resources for each engine. The Kubernetes API audit log is a record of request activity. Turning on the log alone does not block policy violations or rescan all existing resources.
In the introduction plan, write the observation period, the owner of fixes, and the conditions for switching to enforcement. Attach a target, reason, approver, and expiry date to exceptions, and check that expiry is actually enforced. If you turn an urgent exception into a permanent namespace exclusion, later requests in that space can also keep being skipped.
NetworkPolicy and mTLS do not substitute for each other
The standard NetworkPolicy mainly restricts the L3/L4 connection scope. It picks allowed targets by labels, IPs, and ports, but does not provide TLS encryption or certificate-based mutual authentication. A service mesh's or an application's mTLS authenticates identity and encrypts communication, and who can perform what operation is decided by a separate authorization policy. The scope and limits of Kubernetes NetworkPolicy
You need a network plugin that enforces NetworkPolicy. From the standard policy's point of view, a Pod that is not selected is non-isolated in that direction, and other firewalls and platform policies also affect actual reachability. When introducing default deny, first list DNS and the dependent communication you need and check in an isolated test space. Putting default deny across all of production at once and cutting connections is not validation.
What it looks like in the field
An example scenario: signature verification kept succeeding, but the policy selected only team-a and the real service was in team-b. If you read only the success in the report, you miss the fact that the checked scope was empty.
Build the test table first. A request that should be allowed must succeed, and an unsigned request to the same target must be rejected. Also record how a request outside the selection scope is handled. Run timeout tests only in an isolated environment you own. For the network as well, check together the success of an allowed client and the failure of a non-allowed client. If you look at only one side, you can mistake a state where the server is down and every connection fails for a security success.
What to read next
In the next article, you look at how to distinguish digest, signature, SBOM, and provenance and how to leave audit evidence without copying the secret body. This unit is reading and a quiz to practice design and judgment, and it does not mean a lab that verified all the behavior of a real policy engine.