Lock

Geltungsbereich: namespaced · Schutzplanke

Lock schützt eine andere Ressource vor versehentlichem Löschen — dieselbe Idee wie eine Azure-CanNotDelete-Ressourcensperre. Solange ein Lock existiert, der auf eine Ressource verweist, wird jedes kubectl delete (bzw. jedes API-Delete) dieser Ressource zum Zeitpunkt der Admission abgelehnt; Sie müssen zuerst den Lock löschen.

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: "Produktionsumgebung — diesen Lock bewusst entfernen, bevor gelöscht wird."

$ 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

Funktionsweise

Kubernetes kennt keine eingebaute Ressourcensperre, und ein Controller allein kann ein Löschen nicht verhindern — sobald ein Controller es sieht, ist das Löschen bereits unumkehrbar. Der Lock wird daher dort durchgesetzt, wo Löschvorgänge tatsächlich abgelehnt werden können: in der Admission-Phase des API-Servers. Zwei zusammenspielende Teile:

1. Der Lock-Controller versieht das Ziel mit einer Annotation core.navique.com/locked, die die schützenden Locks auflistet. Wird der letzte Lock entfernt, wird die Annotation gelöscht.
2. Eine cluster-weite ValidatingAdmissionPolicy lehnt jedes DELETE einer core.navique.com-Ressource ab, die eine nicht-leere Annotation core.navique.com/locked trägt.

Dies erfordert Kubernetes 1.30+ (ValidatingAdmissionPolicy GA). Die Policy wird mit dem Operator installiert (Helm-Wert lockGuard.enabled, Standard true).

Felder

Feld	Pflicht	Beschreibung
targetRef.kind	ja	Art der geschützten Ressource, z. B. Stack, PostgresCluster, Gateway.
targetRef.name	ja	Name des Ziels, im selben Namespace wie der Lock.
targetRef.apiVersion	nein	Standard core.navique.com/v1alpha1. Nur die API-Gruppe des Operators ist durchsetzbar.
reason	nein	Freitext-Notiz, im Status und in der Ablehnungsmeldung sichtbar.

Verhalten & Grenzen

• Gleicher Namespace, nur unsere Gruppe. Ein Lock kann nur eine core.navique.com-Ressource im eigenen Namespace schützen. Andere Gruppen (und das Sperren eines Lock selbst) werden mit Active: false und dem Grund InvalidTarget abgelehnt.
• Mehrere Locks summieren sich. Mehrere Locks können ein Ziel schützen; es bleibt geschützt, bis der letzte gelöscht ist.
• Auch Kaskaden-Löschungen werden blockiert. Das Löschen eines Stack, dessen Kind gesperrt ist, wird für dieses Kind blockiert (auch Garbage-Collection-Löschungen durchlaufen die Admission), sodass der Stack teilweise abgebaut zurückbleibt. Entfernen Sie zuerst den Lock des Kindes — oder sperren Sie keine einzelnen vom Stack besessenen Kinder, wenn der Stack sauber löschbar bleiben soll, sondern den Stack selbst.
• Eine Schutzplanke, keine Sicherheitskontrolle. Wer RBAC-Rechte hat, den Lock zu löschen (oder die Annotation des Ziels zu bearbeiten), kann den Schutz aufheben. Für eine harte Grenze verwenden Sie RBAC.
• Nur Löschvorgänge. Ein Lock blockiert das Löschen, nicht das Aktualisieren (Azures ReadOnly-Modus ist nicht implementiert — er würde auch die eigenen Reconciles des Operators blockieren).

Status

Feld	Bedeutung
status.active	true, sobald das Ziel die Lock-Annotation trägt (Löschen wird abgelehnt).
status.conditions[Ready]	True bei aktivem Schutz; False mit Grund MissingReference (Ziel noch nicht gefunden) oder InvalidTarget.