Platform Engineering Fundamentals · Module 08 of 12

Policy guardrails and secure defaults

Encode organizational requirements as early feedback and runtime admission guardrails, distinguishing defaulting, warning, auditing and enforcement while maintaining accountable exceptions.

Learning objectives

By the end of this module, you should be able to:

Explain guardrails versus manual approval gates.
Distinguish Kubernetes Pod Security Admission from custom admission policy.
Design an exception with owner, scope, reason and expiry.

Guardrails make the safe path easy

A platform should prevent known-bad configurations where appropriate and give developers fast, specific feedback. Manual approval for every normal request usually becomes a bottleneck rather than a control.

Kubernetes has built-in and extensible policy layers

Pod Security Admission can enforce Pod Security Standards at namespace scope. ValidatingAdmissionPolicy can express CEL-based validation, while admission webhooks can support more complex checks. Choose the simplest control that matches the requirement.

Exceptions are first-class records

A justified exception needs narrow scope, accountable owner, expiry and compensating controls. Permanent anonymous bypasses turn policy into theater.

Platform security consumes supply-chain evidence

Admission and deployment policy can require evidence such as immutable digests, approved registries, signatures or provenance references. The platform should surface a specific denial reason and an accountable exception path rather than forcing developers to reverse-engineer a generic forbidden response.

Worked example

Policy decision

{"rule":"no-latest-tag","mode":"enforce","owner":"platform-security","exception":{"required":true,"max_days":14}}

Policy semantics and ownership are explicit.
An exception path exists but cannot silently become permanent.

Core lab · account-free

Lab 08 — Evaluate a policy bundle

Goal: Validate workload requests against simple platform policy and an expiring exception model.

Before you start

No cloud account required.
Core lab uses bash/Python 3 and local files only.

STEP 1

Create workload request

cat > /tmp/policy-request.json <<'EOF'
{"image":"registry/orders@sha256:abc123","privileged":false,"owner":"payments","exception_expires_days":0}
EOF

STEP 2

Evaluate policy

python3 - <<'PY2'
import json
x=json.load(open('/tmp/policy-request.json'))
assert '@sha256:' in x['image']
assert x['privileged'] is False
assert x['owner']
assert 0 <= x['exception_expires_days'] <= 14
print('policy pass')
PY2

STEP 3

Test a violation

Change the image to a mutable :latest tag and explain the developer-facing remediation message.

Verify

Digest pinning and non-privileged defaults pass.
The policy has an explicit exception maximum.

Expected outcome

A deterministic policy decision with actionable remediation.

Diagnose / troubleshoot

If policy says only “denied,” include the failed rule and remediation.
If exceptions never expire, add lifecycle enforcement before scaling the policy.

Real-world connection

Platform guardrails reduce repeated review work when they are predictable, actionable and measurable.

Real-tool practicum · optional but recommended

Real-tool practicum — enforce a label contract with Kyverno

Install a tagged Kyverno release in the disposable kind cluster, apply an enforce-mode policy, and experience an admission denial with actionable feedback.

Prerequisites

Run ./ops/setup-platform-kind-lab.sh first.
kubectl access to kind-gnu-platform-lab.
Internet access to download the tagged Kyverno manifest.

Cost / risk

Core learning is account-free. Optional external/sandbox tools may consume local CPU/RAM; do not use production credentials or billable cloud resources.

Warnings

Do not point training automation at production clusters, repositories or cloud accounts.
A successful command is not proof of a good platform interface; validate the developer outcome and guardrails.

TOOL 1

./ops/setup-platform-kind-lab.sh

TOOL 2

KYVERNO_VERSION=${KYVERNO_VERSION:-v1.16.2}; kubectl --context kind-gnu-platform-lab apply --server-side --force-conflicts -f "https://github.com/kyverno/kyverno/releases/download/${KYVERNO_VERSION}/install.yaml"

TOOL 3

kubectl --context kind-gnu-platform-lab -n kyverno wait --for=condition=Available deployment --all --timeout=240s

TOOL 4

cat <<'EOF' | kubectl --context kind-gnu-platform-lab apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-platform-owner
spec:
  rules:
    - name: require-owner-label
      match:
        any:
          - resources:
              kinds: [Pod]
              namespaces: [platform-lab]
      validate:
        failureAction: Enforce
        message: platform.gnu.group/owner label is required
        pattern:
          metadata:
            labels:
              platform.gnu.group/owner: '?*'
EOF

TOOL 5

kubectl --context kind-gnu-platform-lab -n platform-lab run denied-demo --image=nginx:alpine --restart=Never

TOOL 6

kubectl --context kind-gnu-platform-lab -n platform-lab run allowed-demo --image=nginx:alpine --restart=Never --labels=platform.gnu.group/owner=payments

Avoid these traps

Common mistakes

Putting every policy behind a human approval.
Creating vague deny messages.
Granting permanent global exceptions for one incompatible workload.

Knowledge check

Can you connect the developer need to a platform contract?

Three concept checks plus one scenario check.

1What is a platform guardrail?

An automated boundary/default that keeps common self-service within approved constraints and gives actionable feedback.

2What can Pod Security Admission enforce?

Kubernetes Pod Security Standards at namespace scope using enforce, audit and/or warn modes.

3What belongs in an exception record?

Narrow scope, owner, rationale, expiry and compensating controls where needed.

4Scenario: developers bypass a policy because denial messages only say “forbidden.” What should the platform improve?

Actionable policy feedback showing the failed rule, required remediation and legitimate exception path.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.