Lock

Portée : namespaced · Garde-fou

Lock protège une autre resource contre une suppression accidentelle — la même idée qu'un verrou de resource Azure CanNotDelete. Tant qu'un Lock référençant une resource existe, tout kubectl delete (ou suppression via l'API) de cette resource est rejeté au moment de l'admission ; vous devez d'abord supprimer le Lock.

apiVersion: core.navique.com/v1alpha1
kind: Lock
metadata:
  name: protect-forge-stack
  namespace: forge
spec:
  targetRef:
    apiVersion: core.navique.com/v1alpha1
    kind: Stack
    name: forge
  reason: "Environnement de production — retirez ce Lock délibérément avant de supprimer."

$ kubectl delete stack forge -n forge
Error from server (Forbidden): admission webhook ... denied the request:
resource is protected by Lock(s) [protect-forge-stack]; delete the Lock(s) before deleting this resource

Fonctionnement

Kubernetes n'a pas de verrou de resource intégré, et un contrôleur seul ne peut pas empêcher une suppression — au moment où un contrôleur la voit, la suppression est déjà irréversible. Le Lock est donc appliqué là où les suppressions peuvent réellement être rejetées : à l'étape d'admission de l'API server. Deux éléments coopèrent :

1. Le contrôleur Lock appose sur la cible une annotation core.navique.com/locked listant les Locks qui la protègent. Lorsque le dernier Lock est retiré, l'annotation est effacée.
2. Une ValidatingAdmissionPolicy à l'échelle du cluster rejette tout DELETE d'une resource core.navique.com portant une annotation core.navique.com/locked non vide.

Cela nécessite Kubernetes 1.30+ (ValidatingAdmissionPolicy GA). La policy est installée avec l'opérateur (valeur Helm lockGuard.enabled, true par défaut).

Champs

Champ	Requis	Description
targetRef.kind	oui	Type de la resource protégée, p. ex. Stack, PostgresCluster, Gateway.
targetRef.name	oui	Nom de la cible, dans le même namespace que le Lock.
targetRef.apiVersion	non	Par défaut core.navique.com/v1alpha1. Seul le groupe d'API de l'opérateur est applicable.
reason	non	Note en texte libre, affichée dans le statut et dans le message de refus.

Comportement et limites

• Même namespace, notre groupe uniquement. Un Lock ne peut protéger qu'une resource core.navique.com dans son propre namespace. Les autres groupes (et le verrouillage d'un Lock lui-même) sont rejetés avec Active: false et la raison InvalidTarget.
• Plusieurs verrous se cumulent. Plusieurs Locks peuvent protéger une même cible ; elle reste protégée jusqu'à la suppression du dernier.
• Les suppressions en cascade sont aussi bloquées. Supprimer un Stack dont un enfant est verrouillé sera bloqué pour cet enfant (les suppressions du garbage collector passent aussi par l'admission), laissant le Stack partiellement démantelé. Retirez d'abord le Lock de l'enfant — ou ne verrouillez pas les enfants individuels possédés par le Stack si vous voulez que le Stack se supprime proprement, verrouillez plutôt le Stack.
• Un garde-fou, pas un contrôle de sécurité. Quiconque a les droits RBAC pour supprimer le Lock (ou éditer l'annotation de la cible) peut lever la protection. Pour une frontière stricte, utilisez RBAC.
• Suppressions uniquement. Un Lock bloque la suppression, pas les mises à jour (le mode ReadOnly d'Azure n'est pas implémenté — il bloquerait aussi les réconciliations de l'opérateur lui-même).

Statut

Champ	Signification
status.active	true une fois que la cible porte l'annotation de verrou (la suppression est rejetée).
status.conditions[Ready]	True lorsqu'actif ; False avec la raison MissingReference (cible introuvable) ou InvalidTarget.