Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Trident Protect-Autorisierung und Zugriffskontrolle verwalten

Beitragende netapp-aruldeepa
PDFs

Trident Protect verwendet das Kubernetes-Modell der rollenbasierten Zugriffskontrolle (RBAC). Standardmäßig stellt Trident Protect einen einzelnen System-Namespace und das zugehörige Standard-Dienstkonto bereit. Wenn Ihre Organisation viele Benutzer oder spezielle Sicherheitsanforderungen hat, können Sie die RBAC-Funktionen von Trident Protect nutzen, um eine genauere Kontrolle über den Zugriff auf Ressourcen und Namespaces zu erhalten.

Der Clusteradministrator hat immer Zugriff auf die Ressourcen im Standardverzeichnis. trident-protect Namespace und kann auch auf Ressourcen in allen anderen Namespaces zugreifen. Um den Zugriff auf Ressourcen und Anwendungen zu steuern, müssen Sie zusätzliche Namensräume erstellen und diesen Namensräumen Ressourcen und Anwendungen hinzufügen.

Beachten Sie, dass im Standardmodus keine Benutzer Änderungsanforderungen für die Anwendungsdatenverwaltung erstellen können. trident-protect Namespace. Sie müssen Anwendungsdatenverwaltungs-CRs in einem Anwendungs-Namespace erstellen (als Best Practice sollten Anwendungsdatenverwaltungs-CRs im selben Namespace wie die zugehörige Anwendung erstellt werden).

Hinweis

Nur Administratoren sollten Zugriff auf privilegierte , Trident Protect geschützte benutzerdefinierte Ressourcenobjekte haben, darunter:

  • AppVault: Erfordert Bucket-Anmeldeinformationen

  • AutoSupportBundle: Erfasst Metriken, Protokolle und andere sensible Trident Protect-Daten

  • AutoSupportBundleSchedule: Verwaltet die Zeitpläne für die Protokollerfassung

Als bewährte Methode empfiehlt es sich, RBAC zu verwenden, um den Zugriff auf privilegierte Objekte auf Administratoren zu beschränken.

Weitere Informationen darüber, wie RBAC den Zugriff auf Ressourcen und Namensräume regelt, finden Sie in der "Kubernetes RBAC-Dokumentation" .

Weitere Informationen zu Servicekonten finden Sie unter "Dokumentation zum Kubernetes-Dienstkonto" .

Beispiel: Zugriffsverwaltung für zwei Benutzergruppen

Eine Organisation verfügt beispielsweise über einen Cluster-Administrator, eine Gruppe von Entwicklern und eine Gruppe von Marketing-Anwendern. Der Cluster-Administrator würde die folgenden Aufgaben erledigen, um eine Umgebung zu schaffen, in der die Entwicklungsabteilung und die Marketingabteilung jeweils nur Zugriff auf die Ressourcen haben, die ihren jeweiligen Namensräumen zugewiesen sind.

Schritt 1: Erstellen Sie einen Namensraum, der die Ressourcen für jede Gruppe enthält.

Durch die Erstellung eines Namensraums können Sie Ressourcen logisch trennen und besser kontrollieren, wer Zugriff auf diese Ressourcen hat.

Schritte

  1. Erstellen Sie einen Namensraum für die Entwicklungsgruppe:

    kubectl create ns engineering-ns

  2. Erstellen Sie einen Namensraum für die Marketinggruppe:

    kubectl create ns marketing-ns

Schritt 2: Erstellen Sie neue Dienstkonten, um mit Ressourcen in jedem Namensraum zu interagieren.

Jeder neu erstellte Namespace verfügt über ein Standarddienstkonto. Sie sollten jedoch für jede Benutzergruppe ein Dienstkonto erstellen, um die Berechtigungen bei Bedarf später weiter zwischen den Gruppen aufteilen zu können.

Schritte

  1. Erstellen Sie ein Dienstkonto für die Entwicklungsgruppe:

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: eng-user
  namespace: engineering-ns

  2. Erstellen Sie ein Servicekonto für die Marketinggruppe:

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: mkt-user
  namespace: marketing-ns

Schritt 3: Erstellen Sie ein Geheimnis für jedes neue Dienstkonto.

Ein Dienstkontogeheimnis dient zur Authentifizierung beim Dienstkonto und kann im Falle einer Kompromittierung leicht gelöscht und neu erstellt werden.

Schritte

  1. Erstellen Sie ein Geheimnis für das Engineering-Service-Konto:

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: eng-user
  name: eng-user-secret
  namespace: engineering-ns
type: kubernetes.io/service-account-token

  2. Erstellen Sie ein Geheimnis für das Marketing-Service-Konto:

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: mkt-user
  name: mkt-user-secret
  namespace: marketing-ns
type: kubernetes.io/service-account-token

Schritt 4: Erstellen Sie ein RoleBinding-Objekt, um das ClusterRole-Objekt an jedes neue Dienstkonto zu binden.

Beim Installieren von Trident protect wird ein Standard-ClusterRole-Objekt erstellt. Sie können diese ClusterRole an das Dienstkonto binden, indem Sie ein RoleBinding-Objekt erstellen und anwenden.

Schritte

  1. Binden Sie die ClusterRole an das Engineering-Servicekonto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: engineering-ns-tenant-rolebinding
  namespace: engineering-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  2. Binden Sie die ClusterRole an das Marketing-Servicekonto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: marketing-ns-tenant-rolebinding
  namespace: marketing-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: mkt-user
  namespace: marketing-ns

Schritt 5: Berechtigungen testen

Prüfen Sie, ob die Berechtigungen korrekt sind.

Schritte

  1. Stellen Sie sicher, dass die technischen Benutzer auf die technischen Ressourcen zugreifen können:

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n engineering-ns

  2. Bestätigen Sie, dass die technischen Benutzer keinen Zugriff auf Marketingressourcen haben:

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n marketing-ns

Schritt 6: Zugriff auf AppVault-Objekte gewähren

Um Datenverwaltungsaufgaben wie Backups und Snapshots durchzuführen, muss der Clusteradministrator einzelnen Benutzern Zugriff auf AppVault-Objekte gewähren.

Schritte

  1. Erstellen und Anwenden einer YAML-Datei mit einer Kombination aus AppVault und Geheimnis, die einem Benutzer Zugriff auf einen AppVault gewährt. Beispielsweise gewährt die folgende CR dem Benutzer Zugriff auf einen AppVault. eng-user :

    apiVersion: v1
data:
  accessKeyID: <ID_value>
  secretAccessKey: <key_value>
kind: Secret
metadata:
  name: appvault-for-eng-user-only-secret
  namespace: trident-protect
type: Opaque
---
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: appvault-for-eng-user-only
  namespace: trident-protect # Trident protect system namespace
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: testbucket
      endpoint: 192.168.0.1:30000
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-for-eng-user-only-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-for-eng-user-only-secret
  providerType: GenericS3

  2. Erstellen und wenden Sie eine Rollen-CR an, um Cluster-Administratoren die Möglichkeit zu geben, Zugriff auf bestimmte Ressourcen in einem Namespace zu gewähren. Beispiel:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: eng-user-appvault-reader
  namespace: trident-protect
rules:
- apiGroups:
  - protect.trident.netapp.io
  resourceNames:
  - appvault-for-enguser-only
  resources:
  - appvaults
  verbs:
  - get

  3. Erstellen und wenden Sie eine RoleBinding CR an, um die Berechtigungen an den Benutzer eng-user zu binden. Beispiel:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eng-user-read-appvault-binding
  namespace: trident-protect
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: eng-user-appvault-reader
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  4. Überprüfen Sie, ob die Berechtigungen korrekt sind.

    1. Versuch, AppVault-Objektinformationen für alle Namespaces abzurufen:

      kubectl get appvaults -n trident-protect --as=system:serviceaccount:engineering-ns:eng-user

      Die Ausgabe sollte in etwa wie folgt aussehen:

      Error from server (Forbidden): appvaults.protect.trident.netapp.io is forbidden: User "system:serviceaccount:engineering-ns:eng-user" cannot list resource "appvaults" in API group "protect.trident.netapp.io" in the namespace "trident-protect"

    2. Testen Sie, ob der Benutzer die AppVault-Informationen abrufen kann, für die er nun Zugriffsberechtigung hat:

      kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get appvaults.protect.trident.netapp.io/appvault-for-eng-user-only -n trident-protect

      Die Ausgabe sollte in etwa wie folgt aussehen:

    yes
Ergebnis

Die Benutzer, denen Sie AppVault-Berechtigungen erteilt haben, sollten in der Lage sein, autorisierte AppVault-Objekte für Anwendungsdatenverwaltungsvorgänge zu verwenden und sollten nicht in der Lage sein, auf Ressourcen außerhalb der zugewiesenen Namensräume zuzugreifen oder neue Ressourcen zu erstellen, auf die sie keinen Zugriff haben.