Versiegelte Geheimnisse herunterladen - Versiegelte Geheimnisse Quellcode herunterladen

versiegelte Geheimnisse

Anderer Quellcode

v0.27.2

Herunterladen

„Sealed Secrets“ für Kubernetes

Problem: „Ich kann alle meine K8s-Konfigurationen in Git verwalten, außer Secrets.“

Lösung: Verschlüsseln Sie Ihr Geheimnis in ein SealedSecret, das sicher gespeichert werden kann – sogar in einem öffentlichen Repository. Das SealedSecret kann nur von dem Controller entschlüsselt werden, der im Zielcluster ausgeführt wird, und niemand sonst (nicht einmal der ursprüngliche Autor) kann das ursprüngliche Secret vom SealedSecret erhalten.

Überblick

SealedSecrets als Vorlagen für Geheimnisse
Öffentlicher Schlüssel/Zertifikat
Bereiche

Installation

Homebrew
MacPorts
Linux
Installation aus der Quelle
Anpassen
Helmkarte
Regler
Kubeseal

Upgrade
Verwendung

Vorhandene Geheimnisse verwalten
Vorhandene Geheimnisse patchen
Vorhandene Geheimnisse aktualisieren
Raw-Modus (experimentell)
Validieren Sie ein versiegeltes Geheimnis

Geheime Rotation

Erneuerung des Siegelschlüssels
Rotation des Benutzergeheimnisses
Vorzeitige Schlüsselerneuerung
Häufige Missverständnisse über die Erneuerung von Schlüsseln
Manuelle Schlüsselverwaltung (erweitert)
Neuverschlüsselung (erweitert)

Details (erweitert)

Krypto

Entwicklung
FAQ

Können Sie weiterhin entschlüsseln, wenn Sie keinen Zugriff mehr auf Ihren Cluster haben?
Wie kann ich ein Backup meiner SealedSecrets erstellen?
Kann ich meine Geheimnisse offline mit einem Backup-Schlüssel entschlüsseln?
Welche Flags sind für Kubeseal verfügbar?
Wie aktualisiere ich Teile einer JSON/YAML/TOML/..-Datei, die mit versiegelten Geheimnissen verschlüsselt ist?
Kann ich meine eigenen (vorgenerierten) Zertifikate mitbringen?
Wie verwende ich Kubeseal, wenn der Controller nicht im kube-system -Namespace ausgeführt wird?
Wie verifiziert man die Bilder?
So verwenden Sie einen Controller für eine Teilmenge von Namespaces
Kann ich die Wiederholungsversuche zum Entsiegeln des Controllers konfigurieren?

Gemeinschaft

Verwandte Projekte

Überblick

Sealed Secrets besteht aus zwei Teilen:

Ein Cluster-seitiger Controller/Operator
Ein clientseitiges Dienstprogramm: kubeseal

Das Dienstprogramm kubeseal verwendet asymmetrische Verschlüsselung, um Geheimnisse zu verschlüsseln, die nur der Controller entschlüsseln kann.

Diese verschlüsselten Geheimnisse sind in einer SealedSecret -Ressource kodiert, die Sie als Rezept zum Erstellen eines Geheimnisses betrachten können. So sieht es aus:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespacespec: cryptodata: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

Sobald dies entsiegelt ist, entsteht ein geheimes Äquivalent zu diesem:

 apiVersion: v1kind: Secretmetadata: name: mysecret namespace: mynamespacedata: foo: YmFy # <- base64 codiert „bar“

Dieses normale Kubernetes-Geheimnis wird nach einigen Sekunden im Cluster angezeigt. Sie können es wie jedes andere Geheimnis verwenden, das Sie direkt erstellt haben (z. B. indem Sie es von einem Pod aus referenzieren).

Gehen Sie zum Abschnitt „Installation“, um loszulegen.

Im Abschnitt „Verwendung“ wird detaillierter erläutert, wie Sie SealedSecret -Ressourcen erstellen.

SealedSecrets als Vorlagen für Geheimnisse

Das vorherige Beispiel konzentrierte sich nur auf die verschlüsselten Secret-Elemente selbst, aber die Beziehung zwischen einer benutzerdefinierten SealedSecret -Ressource und dem Secret in das sie entsiegelt wird, ähnelt in vielerlei Hinsicht (aber nicht in allen) dem bekannten Deployment vs. Pod .

Insbesondere stimmen die Anmerkungen und Beschriftungen einer SealedSecret -Ressource nicht mit den Anmerkungen des Secret überein, das daraus generiert wird.

Um diesen Unterschied zu erfassen, verfügt das SealedSecret -Objekt über einen template , der alle Felder codiert, die der Controller in das unversiegelte Secret einfügen soll.

Die Sprig-Funktionsbibliothek ist zusätzlich zu den Standardfunktionen von Go Text Template verfügbar.

Der metadata wird unverändert kopiert (das Feld ownerReference wird aktualisiert, sofern es nicht deaktiviert ist).

Andere geheime Felder werden individuell behandelt. Die type und immutable Felder werden kopiert und das data kann als Vorlage für komplexe Werte im Secret verwendet werden. Alle anderen Felder werden derzeit ignoriert.

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespace annotations: "kubectl.kubernetes.io/last-applied-configuration": ....spec: cryptodata: .dockerconfigjson: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.... . Vorlage: Typ: kubernetes.io/dockerconfigjson immutable: true # Dies ist ein Beispiel für Beschriftungen und Anmerkungen, die den geheimen Ausgabemetadaten hinzugefügt werden: Beschriftungen: „jenkins.io/credentials-type“: BenutzernamePasswortanmerkungen: „jenkins.io/credentials-description ": Anmeldeinformationen von Kubernetes

Der Controller würde das in etwas entschlüsseln wie:

 apiVersion: v1kind: Secretmetadata: Name: mysecret namespace: mynamespace labels: „jenkins.io/credentials-type“: usernamePassword annotations: „jenkins.io/credentials-description“: Anmeldeinformationen von Kubernetes-EigentümerReferenzen:
  - apiVersion: bitnami.com/v1alpha1 Controller: true Art: SealedSecret Name: mysecret UID: 5caff6a0-c9ac-11e9-881e-42010aac003etype: kubernetes.io/dockerconfigjsonimmutable: truedata: .dockerconfigjson: ewogICJjcmVk...

Wie Sie sehen können, ist die generierte Secret Ressource ein „abhängiges Objekt“ von SealedSecret und wird daher immer dann aktualisiert und gelöscht, wenn das SealedSecret -Objekt aktualisiert oder gelöscht wird.

Öffentlicher Schlüssel/Zertifikat

Das Schlüsselzertifikat (Teil des öffentlichen Schlüssels) wird zum Versiegeln von Geheimnissen verwendet und muss überall dort verfügbar sein, wo kubeseal verwendet werden soll. Bei dem Zertifikat handelt es sich nicht um geheime Informationen. Sie müssen jedoch sicherstellen, dass Sie das richtige Zertifikat verwenden.

kubeseal ruft das Zertifikat zur Laufzeit vom Controller ab (erfordert sicheren Zugriff auf den Kubernetes-API-Server), was für die interaktive Nutzung praktisch ist, aber bekanntermaßen anfällig ist, wenn Benutzer Cluster mit speziellen Konfigurationen haben, wie z. B. private GKE-Cluster, zwischen denen Firewalls bestehen Steuerebene und Knoten.

Ein alternativer Arbeitsablauf besteht darin, das Zertifikat irgendwo (z. B. auf einer lokalen Festplatte) mit kubeseal --fetch-cert >mycert.pem zu speichern und es offline mit kubeseal --cert mycert.pem zu verwenden. Das Zertifikat wird beim Start auch im Controller-Protokoll gedruckt.

Seit Version 0.9.x werden Zertifikate alle 30 Tage automatisch erneuert. Es empfiehlt sich, dass Sie und Ihr Team Ihr Offline-Zertifikat regelmäßig aktualisieren. Um Ihnen dabei zu helfen, akzeptiert kubeseal seit Version 0.9.2 auch URLs. Sie können Ihre interne Automatisierung so einrichten, dass Zertifikate an einem Ort veröffentlicht werden, dem Sie vertrauen.

 kubeseal --cert https://your.intranet.company.com/sealed-secrets/your-cluster.cert

Es erkennt auch die Umgebungsvariable SEALED_SECRETS_CERT . (Profi-Tipp: siehe auch direnv).

HINWEIS : Wir arbeiten an der Bereitstellung von Schlüsselverwaltungsmechanismen, die die Verschlüsselung auf HSM-basierte Module oder verwaltete Cloud-Kryptolösungen wie KMS verlagern.

Bereiche

SealedSecrets stammen aus dem POV eines Endbenutzers, einem „schreibgeschützten“ Gerät.

Die Idee ist, dass das SealedSecret nur von dem Controller entschlüsselt werden kann, der im Zielcluster läuft, und dass niemand sonst (nicht einmal der ursprüngliche Autor) in der Lage ist, das ursprüngliche Secret vom SealedSecret zu erhalten.

Der Benutzer kann direkten Zugriff auf den Zielcluster haben oder auch nicht. Genauer gesagt kann es sein, dass der Benutzer Zugriff auf das vom Controller entsiegelte Geheimnis hat oder auch nicht.

Es gibt viele Möglichkeiten, RBAC auf k8s zu konfigurieren, aber es ist durchaus üblich, Benutzern mit geringen Berechtigungen das Lesen von Secrets zu verbieten. Es ist auch üblich, Benutzern einen oder mehrere Namespaces zu geben, in denen sie über höhere Berechtigungen verfügen, die es ihnen ermöglichen würden, Geheimnisse zu erstellen und zu lesen (und/oder Bereitstellungen zu erstellen, die auf diese Geheimnisse verweisen können).

Verschlüsselte SealedSecret -Ressourcen sind so konzipiert, dass sie sicher eingesehen werden können, ohne dass man Kenntnis von den darin verborgenen Geheimnissen erhält. Dies bedeutet, dass wir Benutzern nicht erlauben können, ein SealedSecret zu lesen, das für einen Namespace bestimmt ist, auf den sie keinen Zugriff haben, und einfach eine Kopie davon in einen Namespace zu verschieben, aus dem sie Geheimnisse lesen können.

Sealed-secrets verhält sich also so, als ob jeder Namespace seinen eigenen unabhängigen Verschlüsselungsschlüssel hätte. Wenn Sie also ein Geheimnis für einen Namespace versiegeln, kann es nicht in einen anderen Namespace verschoben und dort entschlüsselt werden.

Technisch gesehen verwenden wir keinen unabhängigen privaten Schlüssel für jeden Namespace, sondern beziehen stattdessen den Namespace-Namen in den Verschlüsselungsprozess ein und erzielen so effektiv das gleiche Ergebnis.

Darüber hinaus sind Namespaces nicht die einzige Ebene, auf der RBAC-Konfigurationen entscheiden können, wer welches Geheimnis sehen kann. Tatsächlich ist es möglich, dass Benutzer auf ein Geheimnis namens foo in einem bestimmten Namespace zugreifen können, aber nicht auf andere Geheimnisse im selben Namespace. Daher können wir Benutzern standardmäßig nicht erlauben, SealedSecret Ressourcen frei umzubenennen, da sonst ein böswilliger Benutzer in der Lage wäre, jedes SealedSecret für diesen Namespace zu entschlüsseln, indem er es einfach umbenennt, um das eine Geheimnis zu überschreiben, auf das der Benutzer Zugriff hat. Wir verwenden denselben Mechanismus, der zum Einschließen des Namespace in den Verschlüsselungsschlüssel verwendet wird, um auch den geheimen Namen einzuschließen.

Allerdings gibt es viele Szenarien, in denen Ihnen dieses Schutzniveau möglicherweise egal ist. Beispielsweise sind die einzigen Personen, die Zugriff auf Ihre Cluster haben, entweder Administratoren oder sie können überhaupt keine Secret -Ressourcen lesen. Möglicherweise haben Sie einen Anwendungsfall für das Verschieben eines versiegelten Geheimnisses in andere Namespaces (z. B. kennen Sie den Namespace-Namen möglicherweise nicht im Voraus), oder Sie kennen möglicherweise den Namen des Geheimnisses nicht (z. B. könnte es ein eindeutiges Suffix enthalten, das auf dem Hash des Geheimnisses basiert). Inhalte usw.).

Dies sind die möglichen Bereiche:

strict (Standard): Das Geheimnis muss mit genau demselben Namen und Namensraum versiegelt werden. Diese Attribute werden Teil der verschlüsselten Daten und daher würde eine Änderung des Namens und/oder des Namensraums zu einem „Entschlüsselungsfehler“ führen.
namespace-wide : Sie können das versiegelte Geheimnis innerhalb eines bestimmten Namespace frei umbenennen .
cluster-wide : Das Geheimnis kann in jedem Namensraum entsiegelt werden und kann einen beliebigen Namen erhalten.

Im Gegensatz zu den Einschränkungen von name und namespace können geheime Elemente (d. h. JSON-Objektschlüssel wie spec.encryptedData.my-key ) nach Belieben umbenannt werden, ohne dass die Fähigkeit zum Entschlüsseln des versiegelten Geheimnisses verloren geht.

Der Geltungsbereich wird mit dem Flag --scope ausgewählt:

 kubeseal --scope Cluster-Wide sealed-secret.json

Es ist auch möglich, einen Bereich über Anmerkungen im Eingabegeheimnis anzufordern, das Sie an kubeseal übergeben:

sealedsecrets.bitnami.com/namespace-wide: "true" -> für namespace-wide
sealedsecrets.bitnami.com/cluster-wide: "true" -> für cluster-wide

Das Fehlen solcher Anmerkungen bedeutet strict Modus. Wenn beides festgelegt ist, hat cluster-wide Vorrang.

HINWEIS: In der nächsten Version wird dies in einer einzigen Annotation „ sealedsecrets.bitnami.com/scope konsolidiert.

Installation

Die neueste Version und detaillierte Installationsanweisungen finden Sie unter https://github.com/bitnami-labs/sealed-secrets/releases.

Spezifische Hinweise und Anweisungen für die Cloud-Plattform:

GKE

Regler

Sobald Sie das Manifest bereitstellen, wird die SealedSecret -Ressource erstellt, der Controller im kube-system -Namespace installiert, ein Dienstkonto und die erforderlichen RBAC-Rollen erstellt.

Nach wenigen Augenblicken startet der Controller, generiert ein Schlüsselpaar und ist betriebsbereit. Wenn dies nicht der Fall ist, überprüfen Sie die Controller-Protokolle.

Anpassen

Der offizielle Installationsmechanismus für das Controller-Manifest ist lediglich eine YAML-Datei.

In einigen Fällen müssen Sie möglicherweise Ihre eigenen Anpassungen vornehmen, z. B. einen benutzerdefinierten Namespace oder einige Umgebungsvariablen festlegen.

kubectl bietet dafür native Unterstützung, siehe kustomize.

Helmkarte

Das Sealed Secrets-Helmdiagramm wird jetzt offiziell in diesem GitHub-Repo unterstützt und gehostet.

 Helm-Repo fügt versiegelte Geheimnisse hinzu https://bitnami-labs.github.io/sealed-secrets

HINWEIS: Das Versionsschema des Helmdiagramms unterscheidet sich vom Versionsschema des Sealed-Secrets-Projekts selbst.

Ursprünglich wurde das Helm-Diagramm von der Community gepflegt und die erste Version übernahm eine Hauptversion von 1, während das Sealed-Secrets-Projekt selbst immer noch die Hauptversion 0 hat. Das ist in Ordnung, da die Version des Helm-Diagramms selbst nicht unbedingt die Version sein soll der App selbst. Dies ist jedoch verwirrend, daher lautet unsere aktuelle Versionierungsregel:

Das Versionsschema des SealedSecret -Controllers: 0.XY
Das Schema der Ruderkartenversion: 1.XY-rZ

Daher kann es mehrere Überarbeitungen des Helm-Diagramms geben, mit Korrekturen, die nur für das Helm-Diagramm gelten, ohne Auswirkungen auf die statischen YAML-Manifeste oder das Controller-Image selbst.

HINWEIS: Die Helm-Chart-Readme-Datei enthält immer noch einen Verfallshinweis, der jedoch nicht mehr der Realität entspricht und bei der nächsten Veröffentlichung entfernt wird.

HINWEIS: Das Helm-Chart installiert standardmäßig den Controller mit dem Namen sealed-secrets , während die kubeseal -Befehlszeilenschnittstelle (CLI) versucht, auf den Controller mit dem Namen sealed-secrets-controller zuzugreifen. Sie können --controller-name explizit an die CLI übergeben:

 kubeseal --controller-name versiegelte-geheimnisse

Alternativ können Sie bei der Installation des Diagramms fullnameOverride festlegen, um den Namen zu überschreiben. Beachten Sie auch, dass kubeseal davon ausgeht, dass der Controller standardmäßig im kube-system -Namespace installiert ist. Wenn Sie also die kubeseal -CLI verwenden möchten, ohne den erwarteten Controller-Namen und Namespace übergeben zu müssen, sollten Sie das Helm-Chart wie folgt installieren:

 helm install versiegelte Geheimnisse -n kube-system --set-string fullnameOverride=sealed-secrets-controller versiegelte-Geheimnisse/versiegelte-Geheimnisse

Helmkarte in einer eingeschränkten Umgebung

In einigen Unternehmen erhalten Sie möglicherweise nur Zugriff auf einen einzelnen Namespace, nicht auf einen vollständigen Cluster.

Eine der restriktivsten Umgebungen, denen Sie begegnen können, ist:

Ihnen wurde ein namespace mit einem service account zugewiesen.
Sie haben keinen Zugriff auf den Rest des Clusters, nicht einmal auf Cluster-CRDs.
Möglicherweise können Sie in Ihrem Namensraum nicht einmal weitere Dienstkonten oder Rollen erstellen.
Sie müssen in allen Ihren Bereitstellungen Ressourcenlimits berücksichtigen.

Auch mit diesen Einschränkungen können Sie das versiegelte Secrets Helm Chart weiterhin installieren, es gibt nur eine Voraussetzung:

Im Cluster müssen die CRDs für versiegelte Geheimnisse bereits installiert sein .

Sobald Ihre Administratoren die CRDs installiert haben (falls diese noch nicht vorhanden waren), können Sie das Diagramm installieren, indem Sie eine YAML-Konfigurationsdatei wie diese vorbereiten:

 serviceAccount:
  erstellen: falsch
  Name: {allocated-service-account}
rbac:
  erstellen: falsch
  ClusterRole: falsche Ressourcen:
  Grenzen:
    CPU: 150m
    Speicher: 256Mi

Beachten Sie, dass:

Es werden keine Dienstkonten erstellt, sondern das Ihnen zugewiesene verwendet.

{allocated-service-account} ist der Name des service account Ihnen im Cluster zugewiesen wurde.

Weder im Namespace noch im Cluster werden RBAC-Rollen erstellt.
Ressourcenlimits müssen angegeben werden.

Bei den Grenzwerten handelt es sich um Beispiele, die funktionieren sollten. Möglicherweise möchten Sie sie jedoch in Ihrem speziellen Setup überprüfen.

Sobald diese Datei fertig ist und Sie sie config.yaml genannt haben, können Sie das versiegelte Secrets-Helm-Chart wie folgt installieren:

 Helm Install Sealed-Secrets -n {allocated-namespace} Sealed-Secrets/Sealed-Secrets --skip-crds -f config.yaml

Dabei ist {allocated-namespace} der Name des namespace der Ihnen im Cluster zugewiesen wurde.

Kubeseal

Homebrew

Der kubeseal -Client ist auch auf Homebrew verfügbar:

 brew installiere kubeseal

MacPorts

Der kubeseal -Client ist auch auf MacPorts verfügbar:

 Port Kubeseal installieren

Nixpkgs

Der kubeseal -Client ist auch auf Nixpkgs verfügbar: ( HAFTUNGSAUSSCHLUSS : Nicht von bitnami-labs verwaltet)

 nix-env -iA nixpkgs.kubeseal

Linux

Der kubeseal -Client kann unter Linux mit den folgenden Befehlen installiert werden:

 KUBESEAL_VERSION='' # Setzen Sie dies beispielsweise auf KUBESEAL_VERSION='0.23.0'curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION:?} /kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz"tar -xvzf kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Wenn auf Ihrem Computer curl und jq installiert sind, können Sie die Version auf diese Weise dynamisch abrufen. Dies kann für Umgebungen nützlich sein, die in der Automatisierung usw. verwendet werden.

# Fetch the latest sealed-secrets version using GitHub API
KUBESEAL_VERSION=$(curl -s https://api.github.com/repos/bitnami-labs/sealed-secrets/tags | jq -r '.[0].name' | cut -c 2-)

# Check if the version was fetched successfully
if [ -z "$KUBESEAL_VERSION" ]; then
    echo "Failed to fetch the latest KUBESEAL_VERSION"
    exit 1
fi

curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Dabei ist KUBESEAL_VERSION das Versions-Tag der Kubeseal-Version, die Sie verwenden möchten. Zum Beispiel: v0.18.0 .

Installation aus der Quelle

Wenn Sie nur das neueste Client-Tool benötigen, können Sie es in $GOPATH/bin installieren mit:

 Gehen Sie zur Installation github.com/bitnami-labs/sealed-secrets/cmd/kubeseal@main

Sie können anstelle von main ein Release-Tag oder einen Commit-SHA angeben.

Der Befehl go install platziert die kubeseal Binärdatei unter $GOPATH/bin :

 $(go env GOPATH)/bin/kubeseal

Upgrade

Vergessen Sie nicht, die Versionshinweise zu lesen, um Hinweise zu möglichen Breaking Changes zu erhalten, wenn Sie das Client-Tool und/oder den Controller aktualisieren.

Unterstützte Versionen

Derzeit wird nur die neueste Version von Sealed Secrets für Produktionsumgebungen unterstützt.

Kompatibilität mit Kubernetes-Versionen

Der Sealed Secrets-Controller stellt die Kompatibilität mit verschiedenen Versionen von Kubernetes sicher, indem er auf eine stabile Kubernetes-API setzt. Normalerweise gelten Kubernetes-Versionen über 1.16 als kompatibel. Wir unterstützen jedoch offiziell die aktuell empfohlenen Kubernetes-Versionen. Darüber hinaus werden Versionen über 1.24 bei jeder Veröffentlichung einer gründlichen Überprüfung durch unseren CI-Prozess unterzogen.

Verwendung

 # Erstellen Sie irgendwie ein JSON/YAML-codiertes Secret:# (Beachten Sie die Verwendung von „--dry-run“ – dies ist nur eine lokale Datei!)echo -n bar | kubectl erstellt geheimes generisches Mysecret --dry-run=client --from-file=foo=/dev/stdin -o json >mysecret.json# Das ist das wichtige Bit:kubeseal -f mysecret.json -w mysealedsecret.json# Zu diesem Zeitpunkt kann mysealedsecret.json sicher auf Github hochgeladen, # auf Twitter usw. gepostet werden. # Schließlich: kubectl create -f mysealedsecret.json# Profit!kubectl get Secret Mysecret

Beachten Sie, dass SealedSecret und Secret denselben Namespace und Namen haben müssen. Dies ist eine Funktion, die verhindern soll, dass andere Benutzer im selben Cluster Ihre versiegelten Geheimnisse wiederverwenden. Weitere Informationen finden Sie im Abschnitt „Bereiche“.

kubeseal liest den Namespace aus dem Eingabegeheimnis, akzeptiert ein explizites --namespace Argument und verwendet den kubectl Standardnamespace (in dieser Reihenfolge). Alle Beschriftungen, Anmerkungen usw. zum ursprünglichen Secret bleiben erhalten, werden jedoch nicht automatisch im SealedSecret widergespiegelt.

Dieses Schema authentifiziert den Benutzer konstruktionsbedingt nicht . Mit anderen Worten: Jeder kann ein SealedSecret erstellen, das ein beliebiges Secret enthält (vorausgesetzt, dass Namespace/Name übereinstimmt). Es liegt an Ihrem vorhandenen Konfigurationsverwaltungsworkflow, Ihren Cluster-RBAC-Regeln usw., sicherzustellen, dass nur das vorgesehene SealedSecret in den Cluster hochgeladen wird. Die einzige Änderung gegenüber dem bestehenden Kubernetes besteht darin, dass der Inhalt des Secret jetzt außerhalb des Clusters verborgen ist.

Vorhandene Geheimnisse verwalten

Wenn Sie möchten, dass der Sealed Secrets-Controller ein vorhandenes Secret verwaltet, können Sie Ihr Secret mit der Annotation „ sealedsecrets.bitnami.com/managed: "true" annotieren. Das vorhandene Secret wird überschrieben, wenn ein SealedSecret mit demselben Namen und Namensraum entsiegelt wird, und das SealedSecret übernimmt den Besitz des Secret (so dass beim Löschen des SealedSecret auch das Secret gelöscht wird).

Vorhandene Geheimnisse patchen

Neu in v0.23.0

In einigen Anwendungsfällen möchten Sie nicht das gesamte Secret ersetzen, sondern nur einige Schlüssel zum vorhandenen Secret hinzufügen oder ändern. Hierzu können Sie Ihr Secret mit sealedsecrets.bitnami.com/patch: "true" kommentieren. Durch die Verwendung dieser Annotation wird sichergestellt, dass geheime Schlüssel, Beschriftungen und Anmerkungen im Secret , die nicht im SealedSecret vorhanden sind, nicht gelöscht werden und diejenigen, die im SealedSecret vorhanden sind, dem Secret hinzugefügt werden (geheime Schlüssel, Beschriftungen und Anmerkungen, die vorhanden sind). Sowohl im Secret als auch im SealedSecret wird das SealedSecret geändert.

Diese Anmerkung führt nicht dazu, dass SealedSecret den Besitz des Secret übernimmt. Sie können sowohl den patch als auch managed Anmerkungen hinzufügen, um das Patch-Verhalten zu erhalten und gleichzeitig den Besitz des Secret zu übernehmen.

Siegelgeheimnis, das festgelegte Eigentümerreferenzen überspringen kann

Wenn Sie möchten, SealedSecret und das Secret unabhängig sind, was bedeutet, dass das Secret beim Löschen des SealedSecret nicht mit ihm verschwindet, müssen Sie dieses Secret mit der Annotation sealedsecrets.bitnami.com/skip-set-owner-references: "true" annotieren sealedsecrets.bitnami.com/skip-set-owner-references: "true" vor der Anwendung der Nutzungsschritte. Sie können Ihrem Secret weiterhin auch sealedsecrets.bitnami.com/managed: "true" hinzufügen, damit Ihr Geheimnis aktualisiert wird, wenn SealedSecret aktualisiert wird.

Vorhandene Geheimnisse aktualisieren

Wenn Sie vorhandene versiegelte Geheimnisse hinzufügen oder aktualisieren möchten, ohne den Klartext für die anderen Elemente zu haben, können Sie einfach die neuen verschlüsselten Datenelemente kopieren und einfügen und sie in ein vorhandenes versiegeltes Geheimnis einbinden.

Sie müssen darauf achten, die aktualisierten Elemente mit einem kompatiblen Namen und Namespace zu versiegeln (siehe Hinweis zu Bereichen oben).

Sie können den Befehl --merge-into verwenden, um vorhandene versiegelte Geheimnisse zu aktualisieren, wenn Sie nicht kopieren und einfügen möchten:

 echo -n bar | kubectl erstellt geheimes generisches mysecret --dry-run=client --from-file=foo=/dev/stdin -o json  | kubeseal > mysealedsecret.jsonecho -n baz | kubectl erstellt geheimes generisches mysecret --dry-run=client --from-file=bar=/dev/stdin -o json  | kubeseal --merge-into mysealedsecret.json

Raw-Modus (experimentell)

Das Erstellen eines temporären Secrets mit dem Befehl kubectl und das anschließende Wegwerfen nach der Weiterleitung an kubeseal kann eine ziemlich unfreundliche Benutzererfahrung sein. Wir arbeiten an einer Überarbeitung des CLI-Erlebnisses. In der Zwischenzeit bieten wir einen alternativen Modus an, bei dem sich Kubeseal nur um die Verschlüsselung eines Werts in stdout kümmert und es in Ihrer Verantwortung liegt, ihn in eine SealedSecret -Ressource einzufügen (ähnlich wie bei allen anderen k8s-Ressourcen).

Es kann auch als Baustein für Editor-/IDE-Integrationen nützlich sein.

Der Nachteil besteht darin, dass Sie darauf achten müssen, dass der Dichtungsbereich, der Namespace und der Name konsistent sind.

Siehe Bereiche

strict Bereich (Standard):

 $ echo -n foo | kubeseal --raw --namespace bar --name mysecretAgBChHUWLMx...

namespace-wide Bereich:

 $ echo -n foo | kubeseal --raw --namespace bar --scope namespace-wideAgAbbFNkM54...

Fügen Sie die Annotation „ sealedsecrets.bitnami.com/namespace-wide in „ SealedSecret

 Metadaten: Anmerkungen: sealsecrets.bitnami.com/namespace-wide: „true“

cluster-wide Bereich:

 $ echo -n foo | kubeseal --raw --scope cluster-wideAgAjLKpIYV+...

Fügen Sie die Annotation „ sealedsecrets.bitnami.com/cluster-wide in „ SealedSecret

 Metadaten: Anmerkungen: sealsecrets.bitnami.com/cluster-wide: „true“

Validieren Sie ein versiegeltes Geheimnis

Wenn Sie ein vorhandenes versiegeltes Geheimnis validieren möchten, hilft Ihnen kubeseal mit der Flagge --validate .

Geben Sie eine Datei mit dem Namen sealed-secrets.yaml an, die das folgende versiegelte Geheimnis enthält:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespacespec: cryptodata: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

Sie können überprüfen, ob das versiegelte Geheimnis ordnungsgemäß erstellt wurde oder nicht:

 $ cat seal-secrets.yaml | kubeseal --validate

Im Falle eines ungültigen versiegelten Geheimnisses zeigt kubeseal Folgendes an:

 $ cat seal-secrets.yaml | kubeseal --validateerror: Versiegeltes Geheimnis konnte nicht entschlüsselt werden

Geheime Rotation

Sie sollten Ihre Geheimnisse immer wechseln. Da Ihre Geheimnisse jedoch mit einem anderen Geheimnis verschlüsselt sind, müssen Sie verstehen, wie diese beiden Ebenen zusammenhängen, um die richtigen Entscheidungen treffen zu können.

TL;DR:

Wenn ein versiegelnder privater Schlüssel kompromittiert ist, müssen Sie die Anweisungen unten im Abschnitt „Frühzeitige Schlüsselerneuerung“ befolgen, bevor Sie einen Ihrer tatsächlichen geheimen Werte rotieren.
Die Schlüsselerneuerungs- und Neuverschlüsselungsfunktionen von SealedSecret sind kein Ersatz für die regelmäßige Rotation Ihrer tatsächlichen Geheimwerte.

Erneuerung des Siegelschlüssels

Die Siegelschlüssel werden alle 30 Tage automatisch erneuert. Dies bedeutet, dass ein neuer Versiegelungsschlüssel erstellt und an den Satz aktiver Versiegelungsschlüssel angehängt wird, den der Controller zum Entsiegeln von SealedSecret Ressourcen verwenden kann.

Der zuletzt erstellte Versiegelungsschlüssel ist derjenige, der zum Versiegeln neuer Geheimnisse verwendet wird, wenn Sie kubeseal verwenden, und derjenige, dessen Zertifikat heruntergeladen wird, wenn Sie kubeseal --fetch-cert verwenden.

Die Erneuerungszeit von 30 Tagen ist ein angemessener Standardwert, kann jedoch nach Bedarf mit dem Flag --key-renew-period= für den Befehl in der Pod-Vorlage des SealedSecret Controllers angepasst werden. Das value kann als Golang-Dauer-Flag angegeben werden (z. B. 720h30m ). Vorausgesetzt, Sie haben Sealed Secrets im Namespace kube-system installiert, verwenden Sie den folgenden Befehl, um den Deployment-Controller zu bearbeiten und den Parameter --key-renew-period hinzuzufügen. Sobald Sie Ihren Texteditor schließen und der Bereitstellungscontroller geändert wurde, wird automatisch ein neuer Pod erstellt, der den alten Pod ersetzt.

kubectl edit deployment/sealed-secrets-controller --namespace=kube-system

Ein Wert von 0 deaktiviert die automatische Schlüsselerneuerung. Natürlich haben Sie vielleicht einen sinnvollen Anwendungsfall für die Deaktivierung der automatischen Erneuerung von Siegelschlüsseln, aber die Erfahrung hat gezeigt, dass neue Benutzer oft zu voreiligen Schlussfolgerungen neigen, dass sie die Kontrolle über die Erneuerung von Schlüsseln haben wollen, bevor sie vollständig verstehen, wie versiegelte Geheimnisse funktionieren. Lesen Sie mehr darüber im Abschnitt „Häufige Missverständnisse“ weiter unten.

Leider können Sie z. B. „d“ nicht als Einheit für Tage verwenden, da dies von der Go-Stdlib nicht unterstützt wird. Anstatt sich mit der Handfläche ins Gesicht zu schlagen, sollten Sie dies zum Anlass nehmen, über die Unwahrheiten nachzudenken, die Programmierer über die Zeit glauben.

Ein häufiges Missverständnis besteht darin, dass die Schlüsselerneuerung oft als eine Form der Schlüsselrotation angesehen wird, bei der der alte Schlüssel nicht nur veraltet, sondern tatsächlich schlecht ist und Sie ihn daher loswerden möchten. Es hilft auch nicht, dass diese Funktion in der Vergangenheit als „Schlüsselrotation“ bezeichnet wurde, was zu weiterer Verwirrung führen kann.

Versiegelte Geheimnisse werden nicht automatisch rotiert und alte Schlüssel werden nicht gelöscht, wenn neue Schlüssel generiert werden. Alte SealedSecret -Ressourcen können weiterhin entschlüsselt werden (da alte Siegelschlüssel nicht gelöscht werden).

Rotation des Benutzergeheimnisses

Die Erneuerung des Siegelschlüssels und die SealedSecret-Rotation sind kein Ersatz für die Rotation Ihrer tatsächlichen Geheimnisse.

Ein zentrales Wertversprechen dieses Tools ist:

Verschlüsseln Sie Ihr Geheimnis in ein SealedSecret, das sicher gespeichert werden kann – sogar in einem öffentlichen Repository.

Wenn Sie etwas in einem Versionskontrollspeicher, insbesondere in einem öffentlichen Speicher, speichern, müssen Sie davon ausgehen, dass Sie diese Informationen niemals löschen können.

Wenn ein Versiegelungsschlüssel irgendwie aus dem Cluster entweicht, müssen Sie alle mit diesem Schlüssel verschlüsselten SealedSecret Ressourcen als gefährdet betrachten. Daran kann auch keine Rotation des Versiegelungsschlüssels im Cluster oder gar eine Neuverschlüsselung bestehender SealedSecrets-Dateien etwas ändern.

Die beste Vorgehensweise besteht darin, alle Ihre tatsächlichen Geheimnisse regelmäßig zu wechseln (z. B. das Passwort zu ändern) und mit diesen neuen Geheimnissen neue SealedSecret Ressourcen zu erstellen.

Wenn der SealedSecret -Controller den Siegelschlüssel jedoch nicht erneuern würde, wäre diese Rotation irrelevant, da der Angreifer einfach auch die neuen Geheimnisse entschlüsseln könnte. Daher müssen Sie beides tun: den Siegelschlüssel regelmäßig erneuern und Ihre tatsächlichen Geheimnisse wechseln!

Vorzeitige Schlüsselerneuerung

Wenn Sie wissen oder vermuten, dass ein Siegelschlüssel kompromittiert wurde, sollten Sie den Schlüssel so schnell wie möglich erneuern, bevor Sie mit der Versiegelung Ihrer neuen rotierten Geheimnisse beginnen. Andernfalls gewähren Sie Angreifern auch Zugriff auf Ihre neuen Geheimnisse.

Ein Schlüssel kann frühzeitig generiert werden, indem der aktuelle Zeitstempel in einem Flag namens --key-cutoff-time oder einer Umgebungsvariablen namens SEALED_SECRETS_KEY_CUTOFF_TIME an den Controller übergeben wird. Das erwartete Format ist RFC1123. Sie können es mit dem Unix-Befehl date -R generieren.

Häufige Missverständnisse über die Erneuerung von Schlüsseln

Versiegelte Geheimnisse, Versiegelungsschlüssel sind keine Zugangskontrollschlüssel (z. B. ein Passwort). Sie ähneln eher dem GPG-Schlüssel, den Sie möglicherweise zum Lesen verschlüsselter E-Mails verwenden, die an Sie gesendet werden. Lassen Sie uns noch ein wenig mit der E-Mail-Analogie fortfahren:

Stellen Sie sich vor, Sie haben Grund zu der Annahme, dass Ihr privater GPG-Schlüssel möglicherweise kompromittiert wurde. Sie hätten mehr zu verlieren als zu gewinnen, wenn Sie als Erstes einfach Ihren privaten Schlüssel löschen würden. Alle zuvor mit diesem Schlüssel gesendeten E-Mails sind für Sie nicht mehr zugänglich (es sei denn, Sie verfügen über eine entschlüsselte Kopie dieser E-Mails), und auch neue E-Mails von Ihren Freunden, denen Sie noch nicht beigebracht haben, den neuen Schlüssel zu verwenden, sind für Sie nicht mehr zugänglich.

Sicher, der Inhalt dieser verschlüsselten E-Mails ist nicht sicher, da ein Angreifer sie jetzt möglicherweise entschlüsseln kann, aber was geschehen ist, ist geschehen. Ihr plötzlicher Verlust der Fähigkeit, diese E-Mails zu lesen, macht den Schaden sicherlich nicht wieder gut. Wenn überhaupt, ist es noch schlimmer, weil Sie nicht mehr sicher wissen, welches Geheimnis der Angreifer erfahren hat. Was Sie wirklich tun möchten, ist sicherzustellen, dass Ihr Freund Ihren alten Schlüssel nicht mehr verwendet und dass von nun an die gesamte weitere Kommunikation mit einem neuen Schlüsselpaar verschlüsselt wird (dh Ihr Freund muss über diesen neuen Schlüssel Bescheid wissen).

Die gleiche Logik gilt für SealedSecrets. Das ultimative Ziel besteht darin, Ihre tatsächlichen „Benutzer“-Geheimnisse zu schützen. Die Geheimnisse der „Versiegelung“ sind nur ein Mechanismus, eine „Hülle“. Wenn ein Geheimnis preisgegeben wird, gibt es kein Zurück mehr, es ist geschehen.

Sie müssen zunächst sicherstellen, dass neue Geheimnisse nicht mit diesem alten kompromittierten Schlüssel verschlüsselt werden (in der E-Mail-Analogie oben heißt das: Erstellen Sie ein neues Schlüsselpaar und geben Sie allen Ihren Freunden Ihren neuen öffentlichen Schlüssel).

Der zweite logische Schritt besteht darin, den Schaden zu neutralisieren, der von der Art des Geheimnisses abhängt. Ein einfaches Beispiel ist ein Datenbankkennwort: Wenn Sie versehentlich Ihr Datenbankkennwort preisgeben, sollten Sie einfach Ihr Datenbankkennwort ändern (in der Datenbank; und das alte widerrufen!) und die SealedSecret Ressource mit dem aktualisieren neues Passwort (dh kubeseal erneut ausführen).

Beide Schritte werden in den vorherigen Abschnitten beschrieben, wenn auch weniger ausführlich. Es ist keine Schande, sie noch einmal zu lesen, da Sie nun die zugrunde liegende Begründung besser verstanden haben.

Manuelle Schlüsselverwaltung (erweitert)

Der SealedSecret Controller und der zugehörige Workflow sind darauf ausgelegt, alte Siegelschlüssel beizubehalten und regelmäßig neue hinzuzufügen. Sie sollten alte Schlüssel nicht löschen, es sei denn, Sie wissen, was Sie tun.

Das heißt, wenn Sie möchten, können Sie Siegelschlüssel manuell verwalten (erstellen, verschieben, löschen). Es handelt sich lediglich um normale k8s-Geheimnisse, die im selben Namespace leben, in dem sich der SealedSecret -Controller befindet (normalerweise kube-system , aber konfigurierbar).

Es gibt fortgeschrittene Anwendungsfälle, die Sie durch kreatives Management der Siegelschlüssel angehen können. Sie können beispielsweise denselben Versiegelungsschlüssel für mehrere Cluster freigeben, sodass Sie in mehreren Clustern genau dasselbe versiegelte Geheimnis anwenden können. Da Versiegelungsschlüssel nur normale k8s-Geheimnisse sind, können Sie sogar versiegelte Geheimnisse selbst verwenden und einen GitOps-Workflow verwenden, um Ihre Versiegelungsschlüssel zu verwalten (nützlich, wenn Sie denselben Schlüssel zwischen verschiedenen Clustern teilen möchten)!

Wenn Sie ein Siegelschlüsselgeheimnis mit etwas anderem als active kennzeichnen, wird der Schlüssel effektiv aus dem SealedSecret -Controller gelöscht, er steht jedoch weiterhin in k8s zur manuellen Ver-/Entschlüsselung zur Verfügung, falls erforderlich.

HINWEIS SealedSecret Controller erkennt derzeit manuell erstellte, gelöschte oder neu beschriftete Siegelschlüssel nicht automatisch. Ein Administrator muss den Controller neu starten, bevor der Effekt wirksam wird.

Neuverschlüsselung (erweitert)

Bevor Sie einige alte Siegelschlüssel loswerden können, müssen Sie Ihre SealedSecrets mit dem neuesten privaten Schlüssel neu verschlüsseln.

 kubeseal --re-encrypt tmp.json  && mv tmp.json my_sealed_secret.json

Der obige Aufruf erzeugt eine neue versiegelte Geheimdatei, die frisch mit dem neuesten Schlüssel verschlüsselt wird, ohne dass die Geheimnisse den Cluster an den Client verlassen. Sie können diese Datei dann in Ihrem Versionskontrollsystem speichern ( kubeseal --re-encrypt aktualisiert das In-Cluster-Objekt nicht).

Derzeit werden alte Schlüssel nicht automatisch im Müll gesammelt.

Es ist eine gute Idee, Ihre SealedSecrets regelmäßig neu zu verschlüsseln. Aber wie bereits erwähnt, wiegen Sie sich nicht in falscher Sicherheit: Sie müssen davon ausgehen, dass die alte Version der SealedSecret -Ressource (diejenige, die mit einem Schlüssel verschlüsselt ist, den Sie für tot halten) potenziell immer noch verfügbar und für Angreifer zugänglich ist. Das heißt, die Neuverschlüsselung ist kein Ersatz für die regelmäßige Rotation Ihrer tatsächlichen Geheimnisse.

Details (erweitert)

Dieser Controller fügt eine neue benutzerdefinierte SealedSecret -Ressource hinzu. Der interessante Teil eines SealedSecret ist ein base64-codiertes, asymmetrisch verschlüsseltes Secret .

Der Controller verwaltet einen Satz privater/öffentlicher Schlüsselpaare als Kubernetes-Geheimnisse. Schlüssel sind mit sealedsecrets.bitnami.com/sealed-secrets-key gekennzeichnet und werden im Etikett als active oder compromised gekennzeichnet. Beim Start wird der Controller für versiegelte Geheimnisse ...

Suchen Sie nach diesen Schlüsseln und fügen Sie sie dem lokalen Speicher hinzu, wenn sie als aktiv gekennzeichnet sind.
Erstellen Sie einen neuen Schlüssel
Starten Sie den Schlüsselrotationszyklus

Krypto

Weitere Details zu Krypto finden Sie hier.

Entwicklung

Entwicklungsrichtlinien finden Sie im Entwicklerhandbuch.

FAQ

Kann ich mehrere Geheimnisse gleichzeitig in einer YAML / JSON -Datei gleichzeitig verschlüsseln?

Ja, das kannst du! Lassen Sie so viele Geheimnisse fallen, wie Sie in einer Datei möchten. Stellen Sie sicher, dass Sie sie über --- für YAML und als zusätzliche einzelne Objekte in JSON trennen.

Können Sie immer noch entschlüsseln, wenn Sie keinen Zugriff mehr auf Ihren Cluster mehr haben?

Nein, die privaten Schlüssel werden nur in dem vom Controller verwalteten Geheimnis gespeichert (es sei denn, Sie haben eine andere Sicherung Ihrer K8S -Objekte). Es gibt keine Hintertoors - ohne dass der private Schlüssel zum Verschlingen einer bestimmten Versiegelungsekrets nicht entschlüsselt werden kann. Wenn Sie mit den Verschlüsselungsschlüssel nicht in die Geheimnisse gelangen und auch nicht zu den entschlüsselten Versionen Ihrer Geheimnisse in dem Cluster gelangen können, müssen Sie neue Passwörter für alles regenerieren, sie erneut mit einem neuen versiegeln Versiegelungsschlüssel usw.

Wie kann ich eine Sicherung meiner Versiegelungserkreten durchführen?

Wenn Sie eine Sicherung der privaten Schlüssel der Verschlüsselung durchführen möchten, ist dies einfach von einem Konto mit geeignetem Zugriff zu erledigen:

 kubectl Get Secret -n kube-system -l dosiedsecrets.bitnami.com/sealed-secrets-key -o yaml> main.keyecho "---" >> Main.Key
kubectl Get geheime -n kube-system versiegelte-screts-key -o yaml >> main.key

HINWEIS: Sie benötigen die zweite Anweisung nur, wenn Sie jemals versiegelte Kreten älter als Version 0.9.x in Ihrem Cluster installiert haben.

Hinweis: Diese Datei enthält die öffentlichen + privaten Schlüssel des Controllers und sollte OMG-Safe aufbewahrt werden!

Hinweis: Nach der Versiegelung der Schlüsselverlängerung sollten Sie Ihr Backup neu erstellen. Andernfalls kann Ihr Backup keine neuen versiegelten Geheimnisse entschlüsseln.

Um nach einer Katastrophe von einer Sicherung wiederherzustellen, stellen Sie diese Geheimnisse zurück, bevor Sie den Controller starten - oder wenn der Controller bereits gestartet wurde, ersetzen Sie die neu geschaffenen Geheimnisse und starten Sie den Controller neu:

Für den Helm -Bereitstellung:

 kubectl anwenden -f main.key
kubectl delete pod -n kube -system -l app.kubernetes.io/name=Sealed-secrets

Für die Bereitstellung über controller.yaml Manifest

 kubectl anwenden -f main.key
kubectl löschen pod -n kube-system -l name = versiegelte secrets-controller

Kann ich meine Geheimnisse offline mit einem Backup -Schlüssel entschlüsseln?

Während die Behandlung von versiegelten Sendern als langfristiges Speichersystem für Geheimnisse SealedSecret der empfohlene Anwendungsfall ist. praktisch.

Wenn Sie einen oder mehrere Ihrer privaten Schlüsseln gesichert haben (siehe vorherige Frage), können Sie die kubeseal --recovery-unseal --recovery-private-key file1.key,file2.key,... Befehl zum Entschlüsseln A verwenden versiegelte Geheimnisse Datei.

Welche Flaggen stehen für Kubseal zur Verfügung?

Sie können die verfügbaren Flags mit kubeseal --help überprüfen.

Wie aktualisiere ich Teile von JSON/YAML/TOML/.. Datei mit versiegelten Geheimnissen verschlüsselt?

Eine Kubernetes Secret Ressource enthält mehrere Elemente, im Grunde genommen eine flache Karte von Schlüssel-/Wertpaaren. Versiegelte Sektor arbeiten auf dieser Ebene und es ist egal, was Sie in die Werte einfügen. Mit anderen Worten, es kann für eine strukturierte Konfigurationsdatei, die Sie möglicherweise möglicherweise in ein Geheimnis eingerichtet haben, keinen Sinn ergeben, und können daher nicht helfen, einzelne Felder darin zu aktualisieren.

Da dies ein häufiges Problem ist, insbesondere wenn wir uns mit älteren Anwendungen befassen, bieten wir ein Beispiel für eine mögliche Problemumgehung an.

Kann ich meine eigenen (vorgenerierten) Zertifikate mitbringen?

Ja, Sie können dem Controller Ihre eigenen Zertifikate zur Verfügung stellen, und er wird sie konsumieren. Bitte überprüfen Sie hier eine Problemumgehung.

Wie benutze ich Kubseal, wenn der Controller nicht im `kube-system` -Namespace ausgeführt wird?

Wenn Sie den Controller in einem anderen Namespace als das Standardkube kube-system installiert haben, müssen Sie diesen Namespace für das kubeseal Befehlszeilen-Tool angeben. Es gibt zwei Optionen:

Sie können den Namespace über die Befehlszeilenoption angeben: --controller-namespace :

 KUBSEAL-CONTROLLER-NAMEEPACE RAILED-SECRETS  MySealedSecret.json

Über die Umgebungsvariable SEALED_SECRETS_CONTROLLER_NAMESPACE :

 exportieren dosied_secrets_controller_namespace = versiegelte Sektionen
kubseal  mySealedSecret.json

Wie überprüfen Sie die Bilder?

Unsere Bilder werden mit cosign signiert. Die Unterschriften wurden in unserem GitHub -Containerregister gespeichert.

Bilder bis hin zu V0.20.2 wurden unter Verwendung von CoSIGN V1 signiert. Neuere Bilder sind mit CoSsign V2 signiert.

Es ist ziemlich einfach, die Bilder zu überprüfen:

 # Exportieren Sie das COSIGN_Variable-Einrichten der GitHub-ContainerregistrierungspfadepathExport cosign_repository = ghcr.io/bitnami-labs/dosided-secrets-controller/signs# Überprüfen Sie das in GhcrCosign-Verifizierung hochgeladene Bild. IO/Bitnami-Labs/Versiegelte-Kreten-Controller: Neueste# Überprüfen Sie das Bild hochgeladen in DockerHubCosign verifizieren-Key .github/Workflows/cosign.pub docker.io/bitnami/sealed-secrets-controller:latest

So verwenden Sie einen Controller für eine Teilmenge von Namespaces

Wenn Sie einen Controller für mehr als einen Namespace verwenden möchten, jedoch nicht für alle Namespaces, können Sie zusätzliche Namespaces mit dem Befehlszeilen-Flag --additional-namespaces=,,<...> verwenden. Stellen Sie sicher, dass Sie in den Zielnamenspitzen geeignete Rollen und Rollenbindungen anbieten, damit der Controller die Geheimnisse dort verwalten kann.

Kann ich die Controller -Wiederfassungsversuche konfigurieren?

Die Antwort lautet Ja, Sie können die Anzahl der Wiederholungen in Ihrem Controller mithilfe des Flag --max-unseal-retries konfigurieren. Mit diesem Flag können Sie die Anzahl der maximalen Wiederholungen konfigurieren, um Ihre versiegelten Geheimnisse zu entsiegeln.

Gemeinschaft

#versiegelte Kreten auf Kubernetes Slack

Klicken Sie hier, um sich bei der Kubernetes Slack Org anzumelden.

versiegelte Geheimnisse