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

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

🛡️ धडा 09 — Policy as code आणि guardrails: दुरुस्ती सांगणारे नियम

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-secrets-config · पुढील: lesson-10-scorecards

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

धडे 01–08, आणि policy as code: शाळेचे सुरक्षा नियम code म्हणून लिहिलेले, जे प्रत्येक deployment तपासतात. प्रत्येक नियम काय चुकले आणि ते कसे दुरुस्त करायचे हे परत सांगतो. तेच नियम audit mode (परवानगी, पण इशारा) किंवा enforce mode (नकार) मध्ये चालतात. RULES आणि evaluate() idp/guard.py मध्ये, policy() idp/demo.py मध्ये.

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

शाळेत वर्गखोल्यांसाठी सुरक्षा नियम आहेत: प्रत्येक खोलीला नाव असलेला मालक असतो, fire exits अडवलेले नसतात, मोठ्या हॉलमध्ये किमान दोन बाहेर पडायचे दरवाजे असतात, रसायनांचे कपाट कुलूपबंद असते.

जुनी पद्धत: एक निरीक्षक येतो, "नापास" म्हणतो आणि निघून जातो. 🚫 शिक्षिकेला काय बदलायचे ते कळत नाही, म्हणून पुढच्या भेटीआधी ती अडचण लपवते.

सुविधा कार्यालय हे वेगळ्या पद्धतीने करते. निरीक्षकाची तपासणी-यादी लिहून ठेवलेली असते आणि खोलीत प्रत्येक बदल झाला की ती आपोआप चालते. प्रत्येक अडचणीसाठी ती काय आणि कसे सांगते: "दारावर मालकाची पाटी नाही → इथे तुमच्या विभागाचे नाव लावा — योग्य व्यक्तीला बोलावण्यासाठी कार्यालय ते वापरते." 🛡️

पहिल्या महिन्यात तपासणी-यादी फक्त इशारा देते (audit mode): खोल्या उघड्या राहतात, शिक्षिकांना यादी मिळते. बहुतेक खोल्या पास झाल्या की कार्यालय enforce वर जाते: अडचण असलेली खोली ती दुरुस्त होईपर्यंत उघडत नाही. कतरिनाच्या परीक्षा-खोलीत 4 अडचणी होत्या. तिने फक्त messages वाचून चारही दुरुस्त केल्या, आणि खोली उघडली.

🗺️ आकृती

flowchart LR
    m["📄 exam-results manifest"] --> e{"🛡️ 5 rules"}
    e -->|"audit"| w["⚠️ allowed with warnings<br/>4 findings"]
    e -->|"enforce"| d["⛔ denied<br/>4 findings"]
    d --> f["💬 each finding:<br/>what is wrong → fix"]
    f --> m2["📄 fixed manifest"] --> ok["✅ allowed"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l09

❓ काय

Policy as code — machine तपासू शकेल अशा भाषेत लिहिलेले नियम, Git मध्ये ठेवलेले, इतर code प्रमाणेच review आणि test केलेले. तोच नियम developer च्या editor मध्ये, CI मध्ये आणि deploy च्या वेळी चालू शकतो.
Guardrail — संपूर्ण रस्ता न अडवता teams ना सुरक्षित रस्त्यावर ठेवणारा नियम. प्रत्येक बदलाला एखाद्या व्यक्तीची मंजुरी लागणाऱ्या फाटका च्या उलट.
Admission control — Kubernetes मध्ये, प्रत्येक object store होण्याआधी तो पाहणारा आणि नाकारू शकणारा webhook किंवा built-in check. OPA Gatekeeper, Kyverno आणि Kubernetes ची स्वतःची ValidatingAdmissionPolicy (CEL मध्ये लिहिलेली) हे सगळे इथे काम करतात.
Audit विरुद्ध enforce — audit अडचणी सांगतो आणि बदल जाऊ देतो; enforce तो नाकारतो. Gatekeeper चे enforcementAction dryrun, warn किंवा deny असू शकते; Kyverno मध्ये Audit आणि Enforce आहेत. आधी audit मध्ये rollout केल्याने किती गोष्टी मोडतील ते दिसते.
Shift left — तेच checks लवकर चालवणे (editor मध्ये, Conftest सारख्या tool ने CI मध्ये) म्हणजे लोकांना अडचण लिहिल्यानंतर काही मिनिटांत कळते, deploy च्या वेळी नाही.
Actionable message — नियमाचे नाव, अडचण आणि दुरुस्ती सांगणारी finding. शिकवणारा guardrail आणि लोक ज्याला वळसा घालतात असा guardrail यांच्यात हाच फरक आहे.
Exceptions — खऱ्या policy system मध्ये "हा नाही, कारण …" असे सांगण्याची सोय हवी, ज्याला owner आणि शेवटची तारीख असते.

🤔 का

कारण self-service (भाग 2) ने निर्णय कार्यालयाकडून teams कडे नेले. कार्यालयाने प्रत्येक बदल हाताने review न करता महत्त्वाच्या गोष्टी खऱ्या राहतील याची खात्री नियम करतात: प्रत्येक service ला owner आहे, images pinned आहेत, production मध्ये दोन replicas आहेत, buckets private आहेत. आणि कारण फक्त "नाही" म्हणणारा नियम काहीच शिकवत नाही — मग लोक मागच्या वेळी जे पास झाले त्याची copy करतात, किंवा मागचा दरवाजा शोधतात. दुरुस्ती समजावणारा नियम सुरक्षित मार्गालाच सोपा मार्ग बनवतो, आणि सोनेरी वाटेची संपूर्ण कल्पना हीच आहे.

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

idp/guard.py मधील RULES ही (id, test, message, fix) ची यादी आहे; manifest ठीक असेल तर test(manifest) True परत देतो. पाच नियम: owner-label, no-latest-tag, limits-set, two-replicas-in-prod (फक्त env production असेल तेव्हाच तपासला जातो) आणि no-public-bucket. evaluate(manifest, mode, rules) काहीच नापास नसेल तर allowed परत देतो; नाहीतर audit mode मध्ये allowed with warnings किंवा enforce mode मध्ये denied, आणि सोबत प्रत्येक finding तिच्या दुरुस्तीसह. तुम्ही तुमची स्वतःची नियमांची यादीही देऊ शकता.

🧪 करून पाहा

python3 idp/demo.py policy
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from guard import RULES, evaluate
m = dict(name="timetable", labels={"owner": "maths"}, image="timetable", limits={"cpu": "250m", "memory": "128Mi"},
         env="staging", replicas=1, public_bucket=True)
decision, findings = evaluate(m, "enforce")
print(decision, [rid for rid, _, _ in findings])
m["env"] = "production"; print("in production:", [rid for rid, _, _ in evaluate(m)[1]])
rules = RULES + [("has-probe", lambda m: "probe" in m, "no health probe", "add probe: /healthz (the template ships one)")]
m.update(image="timetable:2.0.1", replicas=2, public_bucket=False)
print("with a sixth rule:", evaluate(m, "enforce", rules)[0], "·", evaluate(m, "enforce", rules)[1][0][2])
m["probe"] = "/healthz"; print("fixed:", evaluate(m, "enforce", rules))
EOF

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

policy हे छापते:

── audit mode: exam-results → allowed with warnings (4 findings)
── enforce mode: exam-results → denied (4 findings)
   ✗ owner-label           no owner label → fix: add labels.owner: <your group> (the catalog uses it to page the right people)
   ✗ two-replicas-in-prod  1 replica in production → fix: set replicas: 2 or more so one restart is not an outage
── after the four fixes → allowed

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

denied ['no-latest-tag', 'no-public-bucket']
in production: ['no-latest-tag', 'two-replicas-in-prod', 'no-public-bucket']
with a sixth rule: denied · add probe: /healthz (the template ships one)
fixed: ('allowed', [])

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

तोच manifest audit mode मध्ये allowed आणि enforce mode मध्ये denied झाला — नियम बदलले नाहीत, फक्त नापास झाल्यावर काय होते ते बदलले. अजिबात tag नसलेली image :latest सारख्याच नियमात नापास झाली. Manifest staging वरून production वर नेल्यावर एक finding वाढली (staging साठी एक replica चालते, production साठी नाही): नियम संदर्भावर अवलंबून असू शकतात. सहावा नियम जोडणे म्हणजे एक ओळ, आणि त्याची दुरुस्ती थेट धडा 03 मधल्या सोनेरी वाटेकडे बोट दाखवत होती ("the template ships one"). Template मधून बनलेली service पहिल्याच दिवशी बहुतेक नियम पास करते — guardrails आणि golden paths जोडीने काम करतात.

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

पहिल्याच दिवशी enforce चालू करणे — शेकडो deploys एकाच वेळी नापास होतात, आणि नियम बंद केले जातात
नियमाचे नाव आणि दुरुस्ती नसलेले "policy violation" सारखे messages
नियम फक्त deploy च्या वेळी, त्यामुळे लोकांना अडचण सर्वात वाईट क्षणी कळते
exception ची प्रक्रिया नाही, त्यामुळे खरे कारण असलेल्या teams system ला वळसा घालतात
ज्यांचा कोणी owner नाही किंवा जे कोणी test करत नाही असे नियम — एक buggy नियम सगळ्यांना अडवतो

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

Kyverno, खऱ्या cluster वर — दुरुस्ती कशी करायची हे सांगणारा message असलेला नियम. Kyverno 1.13+ प्रत्येक नियमासाठी action failureAction ने ठरवतो; जुन्या releases मध्ये spec.validationFailureAction वापरत असत:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  rules:
    - name: owner-label
      match:
        any:
          - resources:
              kinds: [Deployment]
      validate:
        failureAction: Audit
        message: "Add metadata.labels.owner: <your group> — the catalog uses it to page the right people."
        pattern:
          metadata:
            labels:
              owner: "?*"

OPA Gatekeeper नियम (Rego मधील ConstraintTemplate) आणि तो कुठे व कसा लागू होतो (एक constraint) हे वेगळे ठेवतो. dry-run पासून सुरुवात:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels            # from the Gatekeeper policy library
metadata:
  name: must-have-owner
spec:
  enforcementAction: dryrun        # later: warn, then deny
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: owner

तेच Rego काहीही deploy होण्याआधी CI मध्ये files तपासू शकते:

conftest test deploy/values.yaml --policy policy/

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: enforce करण्याआधी काही आठवडे audit चे निकाल पाहा. प्रत्येक नियमाच्या findings ची संख्या सांगते की कोणत्या नियमाला चांगला template default हवा, आणि कोणत्याला चांगला message.

⏭️ पुढे

Policies सांगतात की काय खरे असलेच पाहिजे. पुढे: एक scorecard जो दाखवतो की प्रत्येक service काय खरे असायला हवे त्यापासून किती दूर आहे — आणि पुढे काय करायचे.

git checkout lesson-10-scorecards

🛡️ Lesson 09 — Policy as code & guardrails: rules that say how to fix

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-secrets-config · Next: lesson-10-scorecards

📦 What's in this branch

Lessons 01–08, plus policy as code: the school's safety rules written as code that checks every deployment. Each rule returns what is wrong and how to fix it. The same rules run in audit mode (allow, but warn) or enforce mode (deny). RULES and evaluate() in idp/guard.py, policy() in idp/demo.py.

🧒 Explain like I'm 5

The school has safety rules for classrooms: every room has a named owner, fire exits are not blocked, there are at least two exits in the big hall, the chemical cupboard is locked.

The old way: an inspector walks in, says "FAILED", and leaves. 🚫 The teacher does not know what to change, so she hides the problem before the next visit.

The facilities office does it differently. The inspector's checklist is written down and runs automatically every time a room changes. For every problem it says what and how: "No owner sign on the door → put your department's name here — the office uses it to call the right person." 🛡️

For the first month, the checklist only warns (audit mode): rooms stay open, teachers get the list. When most rooms pass, the office switches to enforce: a room with a problem does not open until it is fixed. Katrina's exam room had 4 problems. She fixed all 4 from the messages alone, and it opened.

🗺️ Diagram

flowchart LR
    m["📄 exam-results manifest"] --> e{"🛡️ 5 rules"}
    e -->|"audit"| w["⚠️ allowed with warnings<br/>4 findings"]
    e -->|"enforce"| d["⛔ denied<br/>4 findings"]
    d --> f["💬 each finding:<br/>what is wrong → fix"]
    f --> m2["📄 fixed manifest"] --> ok["✅ allowed"]

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

❓ What

Policy as code — rules written in a language a machine can check, kept in Git, reviewed and tested like other code. The same rule can run in a developer's editor, in CI and at deploy time.
Guardrail — a rule that keeps teams on a safe road without blocking the whole road. The opposite of a gate that needs a person to approve every change.
Admission control — in Kubernetes, a webhook or built-in check that sees every object before it is stored and can reject it. OPA Gatekeeper, Kyverno and Kubernetes' own ValidatingAdmissionPolicy (written in CEL) all work here.
Audit vs enforce — audit reports problems and lets the change through; enforce rejects it. Gatekeeper's enforcementAction can be dryrun, warn or deny; Kyverno has Audit and Enforce. Rolling out in audit first shows how many things would break.
Shift left — running the same checks early (in the editor, in CI with a tool like Conftest) so people learn of a problem minutes after writing it, not at deploy time.
Actionable message — a finding that names the rule, the problem and the fix. That is the difference between a guardrail that teaches and one people route around.
Exceptions — a real policy system needs a way to say "not this one, because …", with an owner and an end date.

🤔 Why

Because self-service (Part 2) moved decisions from the office to the teams. Rules make sure the important things stay true without the office reviewing every change by hand: every service has an owner, images are pinned, production has two replicas, buckets are private. And because a rule that only says "no" teaches nothing — people then copy whatever passed last time, or find the side door. A rule that explains the fix makes the safe way the easy way, which is the whole idea of a golden path.

🔧 How (in this repo)

RULES in idp/guard.py is a list of (id, test, message, fix); test(manifest) returns True when the manifest is fine. The five rules: owner-label, no-latest-tag, limits-set, two-replicas-in-prod (only checked when env is production) and no-public-bucket. evaluate(manifest, mode, rules) returns allowed when nothing fails; otherwise allowed with warnings in audit mode or denied in enforce mode, plus every finding with its fix. You can pass your own list of rules.

🧪 Try it

python3 idp/demo.py policy
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from guard import RULES, evaluate
m = dict(name="timetable", labels={"owner": "maths"}, image="timetable", limits={"cpu": "250m", "memory": "128Mi"},
         env="staging", replicas=1, public_bucket=True)
decision, findings = evaluate(m, "enforce")
print(decision, [rid for rid, _, _ in findings])
m["env"] = "production"; print("in production:", [rid for rid, _, _ in evaluate(m)[1]])
rules = RULES + [("has-probe", lambda m: "probe" in m, "no health probe", "add probe: /healthz (the template ships one)")]
m.update(image="timetable:2.0.1", replicas=2, public_bucket=False)
print("with a sixth rule:", evaluate(m, "enforce", rules)[0], "·", evaluate(m, "enforce", rules)[1][0][2])
m["probe"] = "/healthz"; print("fixed:", evaluate(m, "enforce", rules))
EOF

✅ Verify — what you should see

policy prints:

── audit mode: exam-results → allowed with warnings (4 findings)
── enforce mode: exam-results → denied (4 findings)
   ✗ owner-label           no owner label → fix: add labels.owner: <your group> (the catalog uses it to page the right people)
   ✗ two-replicas-in-prod  1 replica in production → fix: set replicas: 2 or more so one restart is not an outage
── after the four fixes → allowed

Your snippet prints:

denied ['no-latest-tag', 'no-public-bucket']
in production: ['no-latest-tag', 'two-replicas-in-prod', 'no-public-bucket']
with a sixth rule: denied · add probe: /healthz (the template ships one)
fixed: ('allowed', [])

🏁 What you just proved

The same manifest was allowed in audit mode and denied in enforce mode — the rules did not change, only what happens on failure. An image with no tag at all failed the same rule as :latest. Moving the manifest from staging to production added one finding (one replica is fine for staging, not for production): rules can depend on context. Adding a sixth rule was one line, and its fix pointed straight back at the golden path from lesson 03 ("the template ships one"). A service made from the template passes most rules on day one — guardrails and golden paths work as a pair.

⚠️ Common mistakes

turning on enforce on day one — hundreds of deploys fail at once, and the rules get switched off
messages like "policy violation" with no rule name and no fix
rules only at deploy time, so people learn of a problem at the worst moment
no exception process, so teams with a real reason work around the system instead
rules nobody owns or tests — a buggy rule blocks everyone

🏭 In production

Kyverno, on a real cluster — a rule with a message that says how to fix it. Kyverno 1.13+ sets the action per rule with failureAction; older releases used spec.validationFailureAction:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  rules:
    - name: owner-label
      match:
        any:
          - resources:
              kinds: [Deployment]
      validate:
        failureAction: Audit
        message: "Add metadata.labels.owner: <your group> — the catalog uses it to page the right people."
        pattern:
          metadata:
            labels:
              owner: "?*"

OPA Gatekeeper separates the rule (a ConstraintTemplate in Rego) from where and how it applies (a constraint). Starting in dry-run:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels            # from the Gatekeeper policy library
metadata:
  name: must-have-owner
spec:
  enforcementAction: dryrun        # later: warn, then deny
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: owner

The same Rego can check files in CI before anything is deployed:

conftest test deploy/values.yaml --policy policy/

🏭 Why this matters in production: watch the audit results for a few weeks before enforcing. The number of findings per rule tells you which rule needs a better template default, and which needs a better message.

⏭️ Next

Policies say what must be true. Next: a scorecard that shows how far each service is from what should be true — and what to do next.

git checkout lesson-10-scorecards

← Previoussecrets config Next →scorecards

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