🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🛂 धडा 12 — Admission आणि pod security: pod चालण्याआधी दरवाजावरची तपासणी

📍 तुम्ही इथे आहात: 16 पैकी धडा 12 · मागील: lesson-11-k8s-secrets-network · पुढील: lesson-13-dependencies

📦 या ब्रँचमध्ये काय आहे

धडे 01–11, आणि Kubernetes चे शेवटचे दार: admission. "हा user pods तयार करू शकतो" असे RBAC म्हटल्यानंतर, admission controllers pod च्या आत पाहतात आणि तो चालू शकतो का ते ठरवतात. तुम्ही तीन Pod Security Standards (privileged, baseline, restricted), namespace labels सह Pod Security Admission, आणि standards मध्ये न येणाऱ्या नियमांसाठी policy engines (Kyverno, OPA Gatekeeper) शिकता — जसे pinned images आणि resource limits.

sec/cloud.py — admit(pod): "restricted" पद्धतीची policy pod नाकारेल ती कारणे
sec/demo.py — python3 sec/demo.py admission
sec/test_sec.py — check L12

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिनाकडे एक keycard (RBAC) आहे ज्यामुळे ती परिसरात एका पाहुण्याला आणू शकते. पण दरवाजावर दीपिकाची team तरीही पाहुण्याला तपासते:

🔑 Master key नाही. पाहुणे प्रत्येक दार उघडणारी चावी बाळगू शकत नाहीत (privileged).
👤 मुख्याध्यापक म्हणून नाही. पाहुणा साधा पाहुणा म्हणून येतो, प्रत्येक नियम बदलू शकणारी व्यक्ती म्हणून नाही (root).
🪜 शिडी नाही. नंतर खोल्यांमध्ये चढण्यासाठी पाहुणा शिडी आणू शकत नाही (privilege escalation).
🪟 Boiler room च्या खिडकीतून नाही. पाहुणा इमारतीच्या स्वतःच्या यंत्रांपर्यंत छिद्र पाडू शकत नाही (hostPath — node ची disk).
🏷️ पूर्ण नावाचा बिल्ला. "पाहुणा" हे नाव नाही. "Results app, version 1.4.2" हे नाव आहे — आणि त्यावरचा फोटो जुळायला हवा (pinned image tag आणि digest, :latest नाही).
🍱 जेवणाची मर्यादा. कोणताही पाहुणा पूर्ण स्वयंपाकघर संपवू शकत नाही (resource limits).

आजचा पहिला पाहुणा सहाही नियम मोडतो. दरवाजा नाही म्हणतो, आणि यादी देतो. यादीतले दुरुस्त करा, परत या, आणि दरवाजा उघडतो.

🗺️ आकृती

flowchart LR
    k["👩 kubectl apply / CI"] --> a["🔐 authentication"]
    a --> r["☸️ RBAC<br/>may create pods? (L10)"]
    r --> m["✏️ mutating admission"]
    m --> v{"🛂 validating admission<br/>Pod Security Admission: restricted<br/>Kyverno / Gatekeeper / VAP"}
    v -->|"❌ privileged · root · escalation<br/>hostPath · :latest · no limits"| no["403: rejected, with the reasons"]
    v -->|"✅ all rules pass"| etcd["📒 stored → scheduled → runs"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l12

❓ काय

Admission controller — API server च्या मार्गातला code जो authentication आणि RBAC नंतर आणि object साठवला जाण्याआधी चालतो. Mutating controllers object बदलू शकतात (एखादी default जोडणे); validating controllers फक्त तो स्वीकारू किंवा नाकारू शकतात.
Pod Security Standards — Kubernetes project ने लिहिलेल्या तीन पातळ्या:
- privileged — कोणत्याही मर्यादा नाहीत (CNI सारख्या system pods साठी);
- baseline — ओळखीच्या मोठ्या पळवाटा थांबवते: privileged containers, host namespaces, hostPath, धोकादायक capabilities जोडणे;
- restricted — baseline आणि hardening: runAsNonRoot: true, allowPrivilegeEscalation: false, ALL capabilities drop करणे, RuntimeDefault चा seccompProfile, आणि फक्त सुरक्षित volume types.
Pod Security Admission (PSA) — built-in controller जो त्या पातळ्या प्रत्येक namespace वर labels ने लागू करतो, तीन modes मध्ये: enforce (नाकारणे), audit (audit log मध्ये लिहिणे) आणि warn (user ला warning दाखवणे). warn आणि audit ने सुरुवात करा, मग enforce.
PSA काय तपासत नाही — image tags, registries, resource limits, labels, signatures. त्यांच्यासाठी policy engine लागतो:
- Kyverno — Kubernetes YAML मध्ये लिहिलेल्या policies;
- OPA Gatekeeper — Rego मध्ये लिहिलेल्या policies;
- ValidatingAdmissionPolicy — Kubernetes मध्येच असलेले (1.30 पासून stable), नियम CEL मध्ये लिहिलेले, जादा software नाही.
प्रत्येक नियम का महत्त्वाचा:
- privileged — container ला host ची जवळजवळ सगळी ताकद मिळते; त्यातून निसटणे सोपे असते;
- root — container escape bug node वर root देतो;
- allowPrivilegeEscalation — process ला त्याच्या parent पेक्षा जास्त हक्क मिळू शकतात (setuid);
- hostPath — node ची disk; /var/run/docker.sock किंवा / म्हणजे पूर्ण node;
- :latest किंवा tag नाही — काय चालते ते कळू शकत नाही, किंवा "त्याच" गोष्टीकडे परत rollback करता येत नाही; digest (@sha256:…) नेमके bytes सांगतो;
- limits नाहीत — एक pod node ची उपासमार करू शकतो (denial of service).

🤔 का

कारण RBAC "कतरिना pods तयार करू शकते का?" याचे उत्तर देते, "तिच्या pod मध्ये काय आहे?" याचे नाही. एखाद्या namespace मध्ये pods तयार करू शकणारा कोणीही — developer, CI pipeline, चोरलेला token — नाहीतर node ची disk mount केलेला privileged pod चालवून node ताब्यात घेऊ शकतो, आणि तिथून त्यावरचा प्रत्येक pod. Admission ही अशी एकमेव जागा आहे जिथून प्रत्येक pod जातो, तो कोणीही आणि कसाही तयार केलेला असो. तिथला नियम cluster चे चुकांपासून आणि attackers पासून सारख्याच प्रकारे संरक्षण करतो.

🔧 कसे (या repo मध्ये)

sec/cloud.py मधले admit(pod) pod["container"] आणि pod.get("hostPath") पाहते आणि नाकारण्याची कारणे गोळा करते:

privileged: True;
runAsNonRoot True वर set केलेले नाही;
allowPrivilegeEscalation False वर set केलेले नाही (ते नसेल तर True असते, Kubernetes सारखेच);
hostPath volume;
:latest ने संपणारी, किंवा अजिबात : नसलेली image;
limits नाहीत.

ते (True, []) किंवा (False, [reasons]) परत करते. पहिल्या चार Pod Security Standards च्या कल्पना आहेत; शेवटचे दोन policy engine नियम आहेत — model त्यांना एकत्र ठेवते, एकच दार म्हणून. sec/demo.py मधले admission() एक वाईट pod आणि एक दुरुस्त pod वापरून पाहते. Snippet वाईट pod एका वेळी एक नियम असा दुरुस्त करतो.

🧪 करून पाहा

python3 sec/demo.py admission
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from cloud import admit
c = dict(image="school/results", privileged=True); pod = dict(container=c, hostPath="/var/run/docker.sock")
steps = (("first try", lambda: None),
         ("privileged off", lambda: c.update(privileged=False)),
         ("run as non-root", lambda: c.update(runAsNonRoot=True)),
         ("no escalation", lambda: c.update(allowPrivilegeEscalation=False)),
         ("no hostPath", lambda: pod.pop("hostPath")),
         ("tag :latest", lambda: c.update(image="school/results:latest")),
         ("pinned digest", lambda: c.update(image="school/results:1.4.2@sha256:9f1c")),
         ("limits", lambda: c.update(limits={"cpu": "500m", "memory": "256Mi"})))
for name, fix in steps:
    fix(); ok, why = admit(pod)
    print(f"{name:<16} → {'admitted' if ok else f'{len(why)} left: ' + '; '.join(why)}")
EOF
python3 sec/test_sec.py

✅ तपासा — तुम्हाला काय दिसायला हवे

admission हे छापते:

═══ admission ═══
── first try → rejected: privileged container; may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
── fixed     → admitted
   enforce with Pod Security Admission (restricted) or a policy engine (Kyverno / OPA Gatekeeper)

✅ done — every door checked

तुमचा snippet हे छापतो:

first try        → 6 left: privileged container; may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
privileged off   → 5 left: may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
run as non-root  → 4 left: allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
no escalation    → 3 left: mounts a hostPath volume; image has no pinned tag/digest; no resource limits
no hostPath      → 2 left: image has no pinned tag/digest; no resource limits
tag :latest      → 2 left: image has no pinned tag/digest; no resource limits
pinned digest    → 1 left: no resource limits
limits           → admitted

Tests मध्ये ✅ L12 admission rejects a privileged, unpinned pod आहे आणि शेवट 16/16 passed ने होतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

प्रत्येक दुरुस्ती नेमके एक कारण काढून टाकते, आणि सहाही गेल्यावरच दार उघडते. :latest tag जोडल्याने मदत झाली नाही — तो हलणारा tag आहे, म्हणून संख्या 2 वरच राहिली. फक्त digest सह खऱ्या version ने ते दुरुस्त झाले. Default ने काय नव्हते हे सुद्धा लक्षात घ्या: escalation साठी धोकादायक ठरायला pod ने कधीच "privileged: yes" म्हटले नव्हते — allowPrivilegeEscalation तुम्ही false लिहीपर्यंत true म्हणून गणले जाते. सुरक्षित settings लिहाव्या लागतात.

⚠️ नेहमीच्या चुका

आधी warn वापरून न पाहता, चालू pods ने भरलेल्या namespace वर enforce: restricted — पुढचा rollout fail होतो
एका namespace ला label लावणे आणि नवे namespaces विसरणे — labels namespace template मध्ये जोडा, किंवा AdmissionConfiguration मध्ये cluster defaults लावा
एका pod ला hostPath लागतो म्हणून "आत्तापुरते" पूर्ण namespace ला सूट देणे
PSA image tags किंवा limits तपासते असे मानणे — ते तपासत नाही; तुम्हाला policy engine लागतो
वर्षभर Audit mode मध्ये असलेला policy engine: तो report करतो, कोणी वाचत नाही, काहीच block होत नाही
failurePolicy: Ignore असलेला webhook policy engine — तो बंद पडला की सगळेच admit होते
ज्या image चा user root आहे तिच्यासोबत runAsNonRoot: true — pod start होतानाच नाकारला जातो; image numeric non-root USER सह build करा

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — school namespace वर Pod Security Admission. आधी काय तुटेल ते पाहा, मग enforce करा:

kubectl label --dry-run=server --overwrite ns school pod-security.kubernetes.io/enforce=restricted

apiVersion: v1
kind: Namespace
metadata:
  name: school
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

restricted (आणि खालचे policy engine नियम) पास करणारा pod spec:

apiVersion: apps/v1
kind: Deployment
metadata: { name: results-api, namespace: school }
spec:
  replicas: 3
  selector: { matchLabels: { app: results-api } }
  template:
    metadata: { labels: { app: results-api } }
    spec:
      serviceAccountName: results-api
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: api
          image: ghcr.io/baluraut/school-results:1.4.2@sha256:<the image digest from CI>
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }

PSA तपासत नाही त्यासाठी Kyverno — :latest नाही, आणि CPU व memory limits बंधनकारक (Kyverno 1.13+ प्रत्येक नियमावर failureAction ठेवतो; जुन्या releases मध्ये spec.validationFailureAction वापरले जाते):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: school-pod-rules }
spec:
  background: true
  rules:
    - name: no-latest-tag
      match: { any: [{ resources: { kinds: [Pod] } }] }
      validate:
        failureAction: Enforce
        message: "Use a pinned version tag or a digest, not :latest."
        pattern:
          spec:
            containers:
              - image: "!*:latest"
    - name: require-limits
      match: { any: [{ resources: { kinds: [Pod] } }] }
      validate:
        failureAction: Enforce
        message: "CPU and memory limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

तोच limits नियम, Kubernetes मध्येच असलेल्या ValidatingAdmissionPolicy (CEL) आणि त्याच्या binding सह:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata: { name: require-limits }
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.containers.all(c, has(c.resources) && has(c.resources.limits) && 'memory' in c.resources.limits && 'cpu' in c.resources.limits)"
      message: "every container needs CPU and memory limits"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata: { name: require-limits-school }
spec:
  policyName: require-limits
  validationActions: [Deny]
  matchResources:
    namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: school } }

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: याच policies CI मध्ये सुद्धा चालवा (उदाहरणार्थ rendered manifests विरुद्ध kyverno apply), म्हणजे developer ला "rejected: no limits" pull request मध्येच दिसेल, rollout दरम्यान रात्री 2 वाजता नाही.

⏭️ पुढे

Cluster ची दारे बंद आहेत: कोण कृती करू शकतो (RBAC), कोण connect करू शकतो (NetworkPolicy), काय चालू शकते (admission). पण pod ची image इतरांच्या code ने भरलेली आहे. पुढे: वितरण खिडकी उघडते, dependencies सह.

git checkout lesson-13-dependencies

🛂 Lesson 12 — Admission & pod security: the check at the gate before a pod runs

📍 You are here: Lesson 12 of 16 · Previous: lesson-11-k8s-secrets-network · Next: lesson-13-dependencies

📦 What's in this branch

Lessons 01–11, plus the last Kubernetes gate: admission. After RBAC says "this user may create pods", admission controllers look inside the pod and decide whether it may run. You learn the three Pod Security Standards (privileged, baseline, restricted), Pod Security Admission with namespace labels, and policy engines (Kyverno, OPA Gatekeeper) for rules the standards do not cover — like pinned images and resource limits.

sec/cloud.py — admit(pod): the reasons a "restricted"-style policy would reject a pod
sec/demo.py — python3 sec/demo.py admission
sec/test_sec.py — check L12

🧒 Explain like I'm 5

Katrina has a keycard (RBAC) that lets her bring a visitor onto the campus. But at the gate, Dipika's team still looks at the visitor:

🔑 No master key. Visitors may not carry the key that opens every door (privileged).
👤 Not as the head teacher. A visitor comes in as a normal guest, not as the person who can change every rule (root).
🪜 No ladder. A visitor may not bring a ladder to climb into rooms later (privilege escalation).
🪟 Not through the window to the boiler room. A visitor may not open a hole to the building's own machines (hostPath — the node's disk).
🏷️ A full name badge. "Visitor" is not a name. "Results app, version 1.4.2" is — and the photo on it must match (a pinned image tag and digest, not :latest).
🍱 A lunch limit. No visitor may eat the whole kitchen (resource limits).

The first visitor today breaks all six rules. The gate says no, and gives the list. Fix the list, come back, and the gate opens.

🗺️ Diagram

flowchart LR
    k["👩 kubectl apply / CI"] --> a["🔐 authentication"]
    a --> r["☸️ RBAC<br/>may create pods? (L10)"]
    r --> m["✏️ mutating admission"]
    m --> v{"🛂 validating admission<br/>Pod Security Admission: restricted<br/>Kyverno / Gatekeeper / VAP"}
    v -->|"❌ privileged · root · escalation<br/>hostPath · :latest · no limits"| no["403: rejected, with the reasons"]
    v -->|"✅ all rules pass"| etcd["📒 stored → scheduled → runs"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l12

❓ What

Admission controller — code in the API server path that runs after authentication and RBAC and before the object is stored. Mutating ones may change the object (add a default); validating ones may only accept or reject it.
Pod Security Standards — three levels, written by the Kubernetes project:
- privileged — no limits (for system pods like the CNI);
- baseline — stops the known big escapes: privileged containers, host namespaces, hostPath, adding dangerous capabilities;
- restricted — baseline plus hardening: runAsNonRoot: true, allowPrivilegeEscalation: false, drop ALL capabilities, a seccompProfile of RuntimeDefault, and only safe volume types.
Pod Security Admission (PSA) — the built-in controller that applies those levels per namespace with labels, in three modes: enforce (reject), audit (write to the audit log) and warn (show a warning to the user). Start with warn and audit, then enforce.
What PSA does not check — image tags, registries, resource limits, labels, signatures. For those you need a policy engine:
- Kyverno — policies written as Kubernetes YAML;
- OPA Gatekeeper — policies written in Rego;
- ValidatingAdmissionPolicy — built into Kubernetes (stable since 1.30), rules written in CEL, no extra software.
Why each rule matters:
- privileged — the container gets nearly all of the host's power; escaping it is easy;
- root — a container escape bug gives root on the node;
- allowPrivilegeEscalation — a process can gain more rights than its parent (setuid);
- hostPath — the node's disk; /var/run/docker.sock or / is the whole node;
- :latest or no tag — you cannot know what runs, or roll back to "the same" thing; a digest (@sha256:…) names exact bytes;
- no limits — one pod can starve the node (a denial of service).

🤔 Why

Because RBAC answers "may Katrina create pods?", not "what is inside her pod?". Someone who may create pods in a namespace — a developer, a CI pipeline, a stolen token — could otherwise run a privileged pod with the node's disk mounted and own the node, and from there every pod on it. Admission is the one place where every pod passes, whoever created it and however. A rule there protects the cluster from mistakes and from attackers in the same way.

🔧 How (in this repo)

admit(pod) in sec/cloud.py looks at pod["container"] and pod.get("hostPath") and collects reasons to reject:

privileged: True;
runAsNonRoot not set to True;
allowPrivilegeEscalation not set to False (it is True when missing, like Kubernetes);
a hostPath volume;
an image ending in :latest, or with no : at all;
no limits.

It returns (True, []) or (False, [reasons]). The first four are Pod Security Standards ideas; the last two are policy engine rules — the model puts them together, as one gate. admission() in sec/demo.py tries a bad pod and a fixed pod. The snippet fixes the bad pod one rule at a time.

🧪 Try it

python3 sec/demo.py admission
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from cloud import admit
c = dict(image="school/results", privileged=True); pod = dict(container=c, hostPath="/var/run/docker.sock")
steps = (("first try", lambda: None),
         ("privileged off", lambda: c.update(privileged=False)),
         ("run as non-root", lambda: c.update(runAsNonRoot=True)),
         ("no escalation", lambda: c.update(allowPrivilegeEscalation=False)),
         ("no hostPath", lambda: pod.pop("hostPath")),
         ("tag :latest", lambda: c.update(image="school/results:latest")),
         ("pinned digest", lambda: c.update(image="school/results:1.4.2@sha256:9f1c")),
         ("limits", lambda: c.update(limits={"cpu": "500m", "memory": "256Mi"})))
for name, fix in steps:
    fix(); ok, why = admit(pod)
    print(f"{name:<16} → {'admitted' if ok else f'{len(why)} left: ' + '; '.join(why)}")
EOF
python3 sec/test_sec.py

✅ Verify — what you should see

admission prints:

═══ admission ═══
── first try → rejected: privileged container; may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
── fixed     → admitted
   enforce with Pod Security Admission (restricted) or a policy engine (Kyverno / OPA Gatekeeper)

✅ done — every door checked

Your snippet prints:

first try        → 6 left: privileged container; may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
privileged off   → 5 left: may run as root (set runAsNonRoot: true); allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
run as non-root  → 4 left: allowPrivilegeEscalation not false; mounts a hostPath volume; image has no pinned tag/digest; no resource limits
no escalation    → 3 left: mounts a hostPath volume; image has no pinned tag/digest; no resource limits
no hostPath      → 2 left: image has no pinned tag/digest; no resource limits
tag :latest      → 2 left: image has no pinned tag/digest; no resource limits
pinned digest    → 1 left: no resource limits
limits           → admitted

The tests include ✅ L12 admission rejects a privileged, unpinned pod and end with 16/16 passed.

🏁 What you just proved

Each fix removes exactly one reason, and the gate opens only when all six are gone. Adding the tag :latest did not help — it is a tag that moves, so the count stayed at 2. Only a real version with a digest fixed it. Note also what was missing by default: the pod never said "privileged: yes" to be risky for escalation — allowPrivilegeEscalation counts as true until you write false. Safe settings have to be written.

⚠️ Common mistakes

enforce: restricted on a namespace full of running pods without trying warn first — the next rollout fails
labelling one namespace and forgetting new ones — add the labels in the namespace template, or set cluster defaults in the AdmissionConfiguration
exempting a whole namespace "for now" because one pod needs hostPath
believing PSA checks image tags or limits — it does not; you need a policy engine
a policy engine in Audit mode for a year: it reports, nobody reads, nothing is blocked
a webhook policy engine with failurePolicy: Ignore — if it is down, everything is admitted
runAsNonRoot: true with an image whose user is root — the pod is rejected at start; build the image with a numeric non-root USER

🏭 In production

On a real account — Pod Security Admission on the school namespace. First see what would break, then enforce:

kubectl label --dry-run=server --overwrite ns school pod-security.kubernetes.io/enforce=restricted

apiVersion: v1
kind: Namespace
metadata:
  name: school
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

A pod spec that passes restricted (and the policy engine rules below):

apiVersion: apps/v1
kind: Deployment
metadata: { name: results-api, namespace: school }
spec:
  replicas: 3
  selector: { matchLabels: { app: results-api } }
  template:
    metadata: { labels: { app: results-api } }
    spec:
      serviceAccountName: results-api
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: api
          image: ghcr.io/baluraut/school-results:1.4.2@sha256:<the image digest from CI>
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }

Kyverno for what PSA does not check — no :latest, and CPU and memory limits required (Kyverno 1.13+ puts failureAction on each rule; older releases use spec.validationFailureAction):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: school-pod-rules }
spec:
  background: true
  rules:
    - name: no-latest-tag
      match: { any: [{ resources: { kinds: [Pod] } }] }
      validate:
        failureAction: Enforce
        message: "Use a pinned version tag or a digest, not :latest."
        pattern:
          spec:
            containers:
              - image: "!*:latest"
    - name: require-limits
      match: { any: [{ resources: { kinds: [Pod] } }] }
      validate:
        failureAction: Enforce
        message: "CPU and memory limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

The same limits rule, built in, with a ValidatingAdmissionPolicy (CEL) and its binding:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata: { name: require-limits }
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.containers.all(c, has(c.resources) && has(c.resources.limits) && 'memory' in c.resources.limits && 'cpu' in c.resources.limits)"
      message: "every container needs CPU and memory limits"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata: { name: require-limits-school }
spec:
  policyName: require-limits
  validationActions: [Deny]
  matchResources:
    namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: school } }

🏭 Why this matters in production: run the same policies in CI too (for example kyverno apply against the rendered manifests), so a developer sees "rejected: no limits" in the pull request, not at 2 a.m. during a rollout.

⏭️ Next

The cluster's gates are closed: who may act (RBAC), who may connect (NetworkPolicy), what may run (admission). But the pod's image is full of other people's code. Next: the delivery desk opens, with dependencies.

git checkout lesson-13-dependencies

← Previousk8s secrets network Next →dependencies

This page is the lesson's README from the lesson-12-admission branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.