Business Rules - Docker & Kubernetes

This document lists the fundamental business rules of the Docker & Kubernetes domain, each identified by a unique BR-NNN code. Every rule is technology-independent of the underlying cloud and describes an invariant constraint on the behavior of containerization and orchestration.

---

BR-001 - Immutable images tagged by digest

Code: BR-001 Name: Every image is immutable and referenced by digest in production Description: An Image published to the Registry is not overwritten; a new build produces a new digest. In production, Pods reference the image by digest (not by mutable tag like latest) to guarantee reproducibility. Rationale: Deployment reproducibility and prevention of surprises from tags changing under your feet. Priority: HIGH Actors: Build Engineer, Registry Traceability: OCI image digest; Image, Registry (glossary); build-image.md.

---

BR-002 - Desired state governs real state

Code: BR-002 Name: The control plane continuously reconciles real toward desired Description: The declared desired state (replica count, image, resources) in a Deployment is the source of truth. The Control Plane continuously reconciles the real state toward the desired one; direct imperative changes are overwritten by reconciliation. Rationale: Self-healing and declarative, idempotent configuration. Priority: HIGH Actors: Control Plane, Platform Operator Traceability: Kubernetes reconciliation loop; Declarative configuration (glossary); reconcile-deployment.md.

---

BR-003 - Every container declares resource requests and limits

Code: BR-003 Name: No production container runs without requests and limits Description: Every container in a production Pod must declare requests (for scheduling) and limits (for containment) of CPU and memory. Without requests the scheduler cannot place correctly; without limits a container can exhaust the node's resources. Rationale: Correct scheduling, isolation and prevention of noisy neighbors. Priority: HIGH Actors: Platform Operator, kube-scheduler Violation: admission policy rejecting Pods without requests/limits in production. Traceability: Resource requests and limits (glossary); schedule-pod.md.

---

BR-004 - Mandatory liveness and readiness probes

Code: BR-004 Name: Every service container exposes liveness and readiness probes Description: A container serving traffic must define a readinessProbe (decides whether to receive traffic) and a livenessProbe (decides whether to restart). The Service routes traffic only to READY Pods; a Pod that fails liveness is restarted. Rationale: Zero downtime during updates and self-healing of stuck containers. Priority: HIGH Actors: Platform Operator, kubelet Traceability: Liveness probe, Readiness probe (glossary); reconcile-deployment.md.

---

BR-005 - Configuration and secrets outside the image

Code: BR-005 Name: Config in ConfigMap, secrets in Secret, never baked into the image Description: Environment-specific configuration goes into ConfigMap; secrets into Secret (ideally encrypted at rest and injected as volumes or variables). No secret is included in the image or code, so the same image runs in every environment. Rationale: Portable images across environments and prevention of credential disclosure. Priority: CRITICAL Actors: Platform Operator, Security Operator Violation: the scan blocks an image with baked-in secrets. Traceability: ConfigMap, Secret (glossary); best-practices.md.

---

BR-006 - Zero-downtime rolling update with rollback

Code: BR-006 Name: Updates replace Pods gradually while maintaining availability Description: An update of a Deployment happens as a rolling update: new Pods are created and made READY before terminating the old ones, respecting maxSurge/maxUnavailable. On a problem, the Deployment can roll back to the previous revision. Rationale: Service continuity during releases and fast reversibility. Priority: HIGH Actors: Control Plane, Platform Operator Traceability: Zero-Downtime Deployment, Deployment (glossary); reconcile-deployment.md.

---

BR-007 - Least privilege via RBAC and NetworkPolicy

Code: BR-007 Name: Identities and traffic follow least privilege Description: Every ServiceAccount has minimal RBAC permissions; traffic between Pods is governed by deny-by-default NetworkPolicy allowing only necessary communications. Containers do not run as root nor with unnecessary privileges. Rationale: Contain the blast radius of a compromised container. Priority: CRITICAL Actors: Security Operator, Control Plane Traceability: RBAC, NetworkPolicy (glossary); best-practices.md.

---

BR-008 - Minimal, scanned images

Code: BR-008 Name: Every image is minimal, multi-stage built and scanned Description: Images use multi-stage builds to reduce size and attack surface (no build toolchain in the runtime), start from minimal bases and are scanned for known vulnerabilities before publication. Rationale: Reduce size, pull time and attack surface. Priority: HIGH Actors: Build Engineer, Security Operator Traceability: Multi-stage build, Layer (glossary); build-image.md.