Konfigurationsreferenz für Azure Key Vault geheimen Store-Erweiterung

Der SSE kann an vier Stellen konfiguriert werden: Konfigurationseinstellungen, die der Arc-Infrastruktur beim Erstellen oder Aktualisieren der Erweiterung, AKVSync Ressourcen, SecretSync Kubernetes-Ressourcen und SecretProviderClass Kubernetes-Ressourcen bereitgestellt werden.

Konfigurationseinstellungen für Arc-Erweiterungen

Konfigurationseinstellungen können festgelegt werden, wenn die SSE Arc-Erweiterungsinstanz erstellt wird, oder sie können später aktualisiert werden. --configuration-settings <setting>=<value> az k8s-extension create ... Verwenden Oder az k8s-extension update ... zum Erstellen oder Aktualisieren einer SSE-Instanz.

SSE akzeptiert die folgenden Arc-Erweiterungskonfigurationsparameter:

AKVSync-Ressourcen (Vorschau)

AKVSync Ressourcen vereinfachen die am häufigsten verwendeten SSE-Anwendungsfälle, indem sie die Konfiguration in einer einzelnen Ressource konsolidieren. Diese einzelne Ressource ist für einen Menschen einfacher zu konfigurieren und ist weniger anfällig für Inkonsistenzen. Bei Anwendung AKVSync werden Ressourcen in ihre Entsprechung SecretSync und SecretProviderClass Ressourcen übersetzt. Ändern Sie die automatisch generierten SecretSync Ressourcen SecretProviderClass nicht. Sie werden bei Bedarf automatisch aktualisiert.

Die vereinfachte Konfiguration ist ein Vorschaufeature und kann von geringfügigen Änderungen in bevorstehenden Versionen profitieren. Der direkte Konfigurationsstil bleibt für alle Bereitstellungen verfügbar.

Beispiel

kind: AKVSync
apiVersion: secret-sync.x-k8s.io/v1alpha1
metadata:
  name: my-akv-secrets
  namespace: workload-namespace
spec:
  keyvaultName: exampleKeyvault
  clientID:  "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
  tenantID:  "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
  serviceAccountName: workload-serviceaccountname
  objects:
    - secretInAKV: "secret-A"
    - secretInAKV: "secret-B"
      kubernetesSecretName: "k8s-secret-b"
      labels:
        test-label-0: "label-value-0"
      annotations:
        test-annotation-0: "annotation-value-0"
      versionHistory: 3
    - certInAKV: "cert-A"
      kubernetesSecretType: "kubernetes.io/tls"
    - certInAKV: "cert-B"
      kubernetesSecretType: "Opaque"
      versionHistory: 3
    - kubernetesSecretName: "compound-secret"
      mapping:
        - dataKey: "username"
          secretInAKV: secret-A
        - dataKey: "password"
          secretInAKV: secret-B
          version: 1
        - dataKey: "tls-cert"
          certInAKV: cert-A
    - secretInAKV: "ssh-private-key"
      kubernetesSecretType: "kubernetes.io/ssh-auth"

Werte

• metadata.name(erforderlich): Der Name dieser AKVSync Ressource.

Innerhalb von .spec:

• serviceAccountName(required): Das Kubernetes-Dienstkonto, das für den Zugriff auf den Kubernetes-Geheimspeicher verwendet wird. Dieses Dienstkonto sollte mit der verwalteten Identität mit dem Zugriff auf die geheimen Schlüssel in Azure Key Vault verbunden werden.

• clientID(required): Die Client-ID für die verwaltete Identität mit Zugriff auf die erforderlichen geheimen Schlüssel. Diese verwaltete Identität muss über eine Verbundanmeldeinformationen verfügen, die dem benannten Dienstkonto zugeordnet sind.

• tenantID(required): Die ID des Azure Mandanten, der die AKV-Instanz enthält.

• keyvaultName(required): Der Name des Schlüsseltresors.

• objects(required): Eine Liste von Elementen (secretInAKV, certInAKV oder kubernetesSecretName). Elemente können Geheime oder Zertifikate sein, die von AKV abgerufen werden sollen, oder komplexere "zusammengesetzte Geheimnisse", die viele Elemente von AKV enthalten können.

  • secretInAKV(optional): Der Name eines geheimen Schlüssels, der von AKV abgerufen werden soll.

    • kubernetesSecretName(optional): Der Name des neuen Kubernetes-Schlüssels.
    • kubernetesSecretType(optional): Der Typ des Kubernetes-Schlüssels. Wird standardmäßig auf Opaque festgelegt. Unterstützte Werte sind : Opaque, kubernetes.io/tls, , kubernetes.io/ssh-auth, kubernetes.io/basic-auth, kubernetes.io/dockercfgund kubernetes.io/dockerconfigjson. Dieses Feld ist unveränderlich, nachdem der geheime Schlüssel erstellt wurde. Um den geheimen Typ zu ändern, löschen Sie das automatisch generierte SecretSync- und Kubernetes-Geheimnis, und aktualisieren Sie dann die AKVSync-Ressource. Der Controller erstellt sie mit dem neuen Typ neu.
    • labels(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Bezeichnungen, die auf das geheime Objekt angewendet werden sollen.
    • annotations(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Anmerkungen, die auf das geheime Objekt angewendet werden sollen.
    • versionHistory(optional): Standardwert ist 1. SSE lädt diese vielen Versionen des Geheimen von AKV herunter. Die Versionen werden im Kubernetes-Geheimnis in Schlüsseln namens "v0", "v1", "v2" usw. gespeichert. "v0" ist die neueste Version.

  • certInAKV(optional): Der Name eines Zertifikats, das von AKV abgerufen werden soll. Das Zertifikat und sein privater Schlüssel werden beide abgerufen. Bei Verwendung mit kubernetesSecretType festgelegter Eigenschaft kubernetes.io/tlswerden das Zertifikat und der Schlüssel in den Standard tls.crt - und tls.key Datenschlüsseln gespeichert.

    • kubernetesSecretName(optional): Der Name des neuen Kubernetes-Schlüssels.
    • kubernetesSecretType(optional): Der Typ des Kubernetes-Schlüssels. Wird standardmäßig auf Opaque festgelegt. kubernetes.io/tls Für TLS-Zertifikate festgelegt. Dieses Feld ist unveränderlich, nachdem der geheime Schlüssel erstellt wurde. Um den geheimen Typ zu ändern, löschen Sie das automatisch generierte SecretSync- und Kubernetes-Geheimnis, und aktualisieren Sie dann die AKVSync-Ressource. Der Controller erstellt sie mit dem neuen Typ neu.
    • labels(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Bezeichnungen, die auf das geheime Objekt angewendet werden sollen.
    • annotations(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Anmerkungen, die auf das geheime Objekt angewendet werden sollen.
    • versionHistory(optional): Standardwert ist 1. SSE lädt diese vielen Versionen des Zertifikats von AKV herunter. Das Verhalten hängt von kubernetesSecretType:
      Wenn Opaquealle Versionen in einem einzelnen Kubernetes-Geheimnis mit Datenschlüsseln "v0", "v1", "v2" usw. gespeichert werden.
      Wenn kubernetes.io/tlsjede Version einen separaten Kubernetes-Geheimschlüssel namens <cert-name>-v0, <cert-name>-v1usw. erstellt, die alle enthaltenden tls.crt und tls.key Datenschlüssel enthalten. In beiden Fällen ist "v0" die neueste Version.

  • kubernetesSecretName(optional): Definiert den Namen für einen zusammengesetzten Geheimschlüssel in Kubernetes, der eine beliebige Anzahl von Elementen aufweisen kann. versionHistory kann in dieser Situation nicht verwendet werden. Wenn mehrere Versionen erforderlich sind, müssen sie explizit aufgezählt werden. Optional können Sie kubernetesSecretType (unveränderlich nach der Erstellung), Bezeichnungen und Anmerkungen angeben.

    • mapping(required): Eine Liste der Datenschlüssel und deren AKV-Quellen. Es gibt keine Standardschlüssel. Jeder Eintrag muss genau einen von secretInAKV oder certInAKV angeben.

      • dataKey(required): Der Name des Datenschlüssels innerhalb des Kubernetes-Geheimniss, das den von AKV abgerufenen Geheimschlüssel enthält.

      • secretInAKV(optional): Der Name eines geheimen Schlüssels, der von AKV abgerufen und im nominierten Datenschlüssel gespeichert werden soll.

      • certInAKV(optional): Der Name eines Zertifikats, das von AKV abgerufen werden soll. Sowohl das Zertifikat als auch der private Schlüssel werden als zweiteiliges PEM abgerufen und im nominierten Datenschlüssel gespeichert.

      • version(optional): Die Version des geheimen Schlüssels oder Zertifikats, das von AKV abgerufen werden soll. 0 ist die neueste Version, 1 ist die zweite neueste, usw.

SecretSync-Ressourcen

SecretSync Ressourcen konfigurieren, wie SSE geheime Schlüssel und Zertifikate im Geheimspeicher von Kubernetes speichert. Jede SecretSync-Ressource definiert einen Kubernetes-Schlüssel, obwohl er möglicherweise mehr als einen geheimen Schlüssel enthält.

Beispiel

apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
  name: secret-sync-name
  namespace: workload-namespace
spec:
  serviceAccountName: workload-serviceaccountname
  secretProviderClassName: secret-provider-class-name
  secretObject:
    type: Opaque
    data:
      - sourcePath: aSecret/0
        targetKey: aSecret-data-key0
      - sourcePath: aSecret/1
        targetKey: aSecret-data-key1
    labels:
      fromExample: absolutelyYes
    annotations:
      exampleAnnotation: annotationValue 
  forceSynchronization: ArbitraryValue12354

Werte

• metadata.name(erforderlich): Der Name dieser SecretSync-Ressource. Hinweis: Die automatisch erstellte geheime Ressource hat denselben Namen wie diese Ressource.

Innerhalb von .spec:

• serviceAccountName(required): Das Kubernetes-Dienstkonto, das für den Zugriff auf den Kubernetes-Geheimspeicher verwendet wird. Dieses Dienstkonto sollte mit der verwalteten Identität mit dem Zugriff auf die geheimen Schlüssel in Azure Key Vault verbunden werden.
• secretProviderClassName(required): Der Name der SecretProviderClass-Ressource, die definiert, welche geheimen Schlüssel aus Azure Key Vault abgerufen werden sollen.
• secretObject(required): Definiert, wie die gespeicherte geheime Ressource strukturiert werden soll.
  • type(required): Der Typ des Kubernetes-Geheimobjekts. Legen Sie dieses Feld auf Opaque einen allgemeinen Geheimschlüssel ohne auferlegte Struktur fest. Unter "Typen von Kubernetes-Geheimnissen " finden Sie Anleitungen dazu, wie die speziellen geheimen Typen strukturiert werden müssen. Dieses Feld ist unveränderlich, nachdem der geheime Schlüssel erstellt wurde. Um den geheimen Typ zu ändern, löschen Sie die vorhandene SecretSync und den zugehörigen geheimen Schlüssel, und erstellen Sie dann die SecretSync mit dem neuen Typ neu.
  • data(required): Eine Liste der Datenelemente innerhalb der geheimen Ressource. Es muss mindestens ein Element vorhanden sein. Jedes Datenelement muss diese beiden Felder enthalten:
    • sourcePath(required): Der Pfad zu einem Element, das von AKV abgerufen wurde. Wenn nur eine Version des benannten Geheimen von AKV abgerufen wird, ist der Pfad einfach <secret name>.
      Wenn mehr als eine Version des benannten geheimen Schlüssels von AKV abgerufen wird, lautet <secret name>/0der SourcePath der neuesten Version , der zweite neueste ist <secret name>/1usw.
      Wenn ein Zertifikat von AKV abgerufen wird, hängen die SourcePaths vom Wert objectType der SecretProviderClass ab. Wenn der objectType SPC "geheim" ist, sind sowohl ein Zertifikat als auch ein privater Schlüssel unter sourcePaths von <secret name>/tls.crt bzw <secret name>/tls.key . verfügbar.
    • targetKey(required): Der Schlüssel im Kubernetes-Geheimobjekt zum Speichern der Daten.
  • labels(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Bezeichnungen, die auf das geheime Objekt angewendet werden sollen.
  • annotations(optional): Eine Zuordnung von Schlüsselwertpaaren mit zusätzlichen Anmerkungen, die auf das geheime Objekt angewendet werden sollen.
  • forceSynchronization(optional): Änderungen an diesem Feld lösen SSE aus, um AKV auf Änderungen erneut zu überprüfen. Kubernetes wird wie gewohnt aktualisiert, wenn SSE aktualisierte Daten findet. Der Wert dieses Felds wirkt sich nicht auf das Verhalten des SSE aus.

SecretProviderClass-Ressourcen

SecretProviderClass-Ressourcen konfigurieren, was und wie aus einem Azure Key Vault abgerufen werden kann. In dieser Referenz werden nur die Felder behandelt, die für die SSE-Anwendungsfälle der SecretProviderClass erforderlich sind.

Beispiel

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: secret-provider-class-name
  namespace: workload-namespace
spec:
  provider: azure
  parameters:
    clientID: "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
    tenantID: "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
    keyvaultName: exampleKeyvault
    objects: |
      array:
        - |
          objectName: aSecret
          objectType: secret
          objectVersionHistory: 2
        - |
          objectName: aCertificate
          objectType: secret

Werte

Innerhalb von .spec:

• provider(required): Legen Sie dieses Feld auf azure fest, wenn SSE zum Abrufen von Geheimschlüsseln aus Azure Key Vault verwendet wird.
• parameters(required): Definiert, wie und wo AKV-Schlüssel abgerufen werden sollen.
  • clientID(required): Die Client-ID für die verwaltete Identität mit Zugriff auf die erforderlichen geheimen Schlüssel. Diese verwaltete Identität muss über eine Verbundanmeldeinformation verfügen, die mit dem Dienstkonto verknüpft ist, das in der SecretSync-Ressource benannt ist, die diese SecretProviderClass verwendet.
  • tenantID(required): Die ID des Azure Mandanten, der die AKV-Instanz enthält.
  • keyvaultName(required): Der Name des keyvault.
  • objects(required): Eine Zeichenfolge mit einem YAML-Fragment, das die elemente darstellt, die von diesem AKV abgerufen werden sollen. Achten Sie auf das Beispiel, um zu sehen, wie das Objektfeld erstellt wird. Weitere Beispiele für SecretProviderClass-Ressourcen für die Verwendung mit Azure Key Vault finden Sie in den AKV-Anbieterdokumenten. Objekte müssen mindestens ein Element innerhalb des "Array"-Unterobjekts enthalten.
    • objectName(required): Der Name des geheimen Schlüssels oder Zertifikats, das von AKV abgerufen werden soll.
    • objectType(required): Legen Sie dieses Feld secret beim Abrufen eines geheimen Schlüssels von AKV fest.
      Legen Sie beim Abrufen eines Zertifikats dieses Feld auf Folgendes fest:
      • cert um nur das Zertifikat abzurufen.
      • key um nur den öffentlichen Schlüssel des Zertifikats abzurufen.
      • secret um das Zertifikat und den privaten Schlüssel abzurufen.
    • objectVersionHistory(optional): Wenn vorhanden und größer als eins ist, werden diese vielen Versionen von AKV abgerufen, beginnend mit der neuesten Version.