Regole di Business - Docker & Kubernetes

Questo documento elenca le regole di business fondamentali del dominio Docker & Kubernetes, identificate con codice univoco BR-NNN. Ogni regola è technology-independent rispetto al cloud sottostante e descrive un vincolo invariante sul comportamento della containerizzazione e dell'orchestrazione.

---

BR-001 - Immagini immutabili e taggate per digest

Codice: BR-001 Nome: Ogni immagine è immutabile e referenziata per digest in produzione Descrizione: Una Image pubblicata nel Registry non viene sovrascritta; una nuova build produce un nuovo digest. In produzione i Pod referenziano l'immagine per digest (non per tag mutabile come latest) per garantire riproducibilità. Motivazione: Riproducibilità dei deployment e prevenzione di sorprese da tag che cambiano sotto i piedi. Priorità: ALTA Attori: Build Engineer, Registry Tracciabilità: OCI image digest; Immagine, Registry (glossary); build-image.md.

---

BR-002 - Lo stato desiderato governa lo stato reale

Codice: BR-002 Nome: Il control plane riconcilia continuamente reale verso desiderato Descrizione: Lo stato desiderato dichiarato (numero di repliche, immagine, risorse) in un Deployment è la fonte di verità. Il Control Plane riconcilia continuamente lo stato reale verso quello desiderato; le modifiche imperative dirette vengono sovrascritte dalla riconciliazione. Motivazione: Self-healing e configurazione dichiarativa, idempotente. Priorità: ALTA Attori: Control Plane, Platform Operator Tracciabilità: Kubernetes reconciliation loop; Configurazione dichiarativa (glossary); reconcile-deployment.md.

---

BR-003 - Ogni container dichiara richieste e limiti di risorse

Codice: BR-003 Nome: Nessun container production gira senza requests e limits Descrizione: Ogni container in un Pod di produzione deve dichiarare requests (per lo scheduling) e limits (per il contenimento) di CPU e memoria. Senza requests lo scheduler non può collocare correttamente; senza limits un container può esaurire le risorse del nodo. Motivazione: Scheduling corretto, isolamento e prevenzione del rumore tra workload. Priorità: ALTA Attori: Platform Operator, kube-scheduler Violazione: policy di admission che rifiuta i Pod senza requests/limits in produzione. Tracciabilità: Richieste e limiti di risorse (glossary); schedule-pod.md.

---

BR-004 - Probe di liveness e readiness obbligatorie

Codice: BR-004 Nome: Ogni container di servizio espone liveness e readiness probe Descrizione: Un container che serve traffico deve definire una readinessProbe (decide se ricevere traffico) e una livenessProbe (decide se riavviare). Il Service instrada traffico solo ai Pod READY; un Pod che fallisce la liveness viene riavviato. Motivazione: Zero-downtime durante gli aggiornamenti e self-healing dei container bloccati. Priorità: ALTA Attori: Platform Operator, kubelet Tracciabilità: Probe di liveness, Probe di readiness (glossary); reconcile-deployment.md.

---

BR-005 - Configurazione e segreti fuori dall'immagine

Codice: BR-005 Nome: Config in ConfigMap, segreti in Secret, mai cotti nell'immagine Descrizione: La configurazione specifica dell'ambiente va in ConfigMap; i segreti in Secret (idealmente cifrati a riposo e iniettati come volumi o variabili). Nessun segreto è incluso nell'immagine o nel codice, così la stessa immagine gira in ogni ambiente. Motivazione: Immagini portabili tra ambienti e prevenzione della disclosure di credenziali. Priorità: CRITICA Attori: Platform Operator, Security Operator Violazione: lo scan blocca l'immagine con segreti cotti dentro. Tracciabilità: ConfigMap, Secret (glossary); best-practices.md.

---

BR-006 - Rolling update a downtime zero con rollback

Codice: BR-006 Nome: Gli aggiornamenti sostituiscono i Pod gradualmente mantenendo la disponibilità Descrizione: Un aggiornamento di un Deployment avviene come rolling update: nuovi Pod vengono creati e resi READY prima di terminare i vecchi, rispettando maxSurge/maxUnavailable. In caso di problema, il Deployment può fare rollback alla revisione precedente. Motivazione: Continuità del servizio durante i rilasci e reversibilità rapida. Priorità: ALTA Attori: Control Plane, Platform Operator Tracciabilità: Zero-Downtime Deployment, Deployment (glossary); reconcile-deployment.md.

---

BR-007 - Privilegio minimo via RBAC e NetworkPolicy

Codice: BR-007 Nome: Identità e traffico seguono il privilegio minimo Descrizione: Ogni ServiceAccount ha permessi RBAC minimi; il traffico tra Pod è governato da NetworkPolicy deny-by-default che permette solo le comunicazioni necessarie. I container non girano come root né con privilegi non necessari. Motivazione: Contenere il blast radius di un container compromesso. Priorità: CRITICA Attori: Security Operator, Control Plane Tracciabilità: RBAC, NetworkPolicy (glossary); best-practices.md.

---

BR-008 - Immagini minimali e scansionate

Codice: BR-008 Nome: Ogni immagine è minimale, costruita multi-stage e scansionata Descrizione: Le Image usano build multi-stage per ridurre dimensione e superficie d'attacco (no toolchain di build nel runtime), partono da basi minimali e sono scansionate per vulnerabilità note prima della pubblicazione. Motivazione: Ridurre dimensione, tempo di pull e superficie d'attacco. Priorità: ALTA Attori: Build Engineer, Security Operator Tracciabilità: Build multi-stage, Layer (glossary); build-image.md.