Identität und Sicherheit konfigurieren

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Auf dieser Seite wird gezeigt, wie Sie die OpenID Connect-Authentifizierung (OIDC) für Nutzercluster aktivieren, die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) einrichten und die Einmalanmeldung (Single Sign-On, SSO) von Google für die Authentifizierung verwenden. Weitere Informationen zur Authentifizierung mit OIDC finden Sie unter Identitätsverwaltung mit OIDC in Anthos-Cluster auf Bare Metal.

OIDC-Authentifizierung für Nutzercluster aktivieren

Die OIDC-Authentifizierung kann beim Erstellen des Nutzerclusters oder für einen vorhandenen Nutzercluster aktiviert werden. Voraussetzung für die Einrichtung der OIDC-Authentifizierung ist, dass die Identitätsprofile, die auf den Cluster angewendet werden sollen, bereits vorhanden sind. Weitere Informationen finden Sie unter Identitätsprofile erstellen.

Identitätsprofile bei der Clustererstellung festlegen

Eine Anleitung zum Erstellen von Nutzerclustern finden Sie unter Nutzercluster mit der UI des Management Center erstellen. Wählen Sie auf der Seite Clusterkonfiguration zum Erstellen eines Nutzerclusters die Identitätsprofile aus der Drop-down-Liste AIS-Konfigurationen aus. Diese Identitätsprofile werden auf den Nutzercluster angewendet.

Identitätsprofile für einen vorhandenen Nutzercluster festlegen

1. Rufen Sie die Seite Identität und Zugriff auf.

   

2. Klicken Sie auf Profile auf Cluster anwenden.

   

3. Wählen Sie in der Drop-down-Liste Profile die Identitätsprofile aus, die angewendet werden sollen.

4. Wählen Sie in der Drop-down-Liste Cluster die Cluster aus, auf die die Identitätsprofile angewendet werden sollen.

Auf den Nutzercluster angewendete Identitätsprofile aufrufen

Die auf den Nutzercluster angewendeten Identitätsprofile können über die Seite Identität und Zugriff aufgerufen werden.

Wählen Sie den Tab Cluster aus, ermitteln Sie den Nutzercluster, den Sie prüfen möchten, und klicken Sie auf Konfigurationsdetails anzeigen für diesen Nutzercluster.

Konfigurationsdatei für die Anmeldung beim Nutzercluster herunterladen

Klicken Sie in der eingeblendeten Seite Konfigurationsdetails anzeigen auf Anmeldekonfiguration herunterladen.

OIDC-Konfiguration aus einer Datei angeben

Erstellen Sie eine Datei, die Folgendes enthält: Speichern Sie diese Datei als user-cluster-oidc-config.yaml:

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos isolated mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Dabei gilt:

• CONFIGURATION_NAME: Der Name der zu erstellenden OIDC-Konfiguration.
• CLIENT_ID: Die ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet.
• CLIENT_SECRET: Secret für die Clientanwendung.
• EXTRA_PARAMS: zusätzliche Schlüssel/Wert-Parameter (durch Kommas getrennt), die an den OpenID-Anbieter gesendet werden sollen.
• ISSUER_URI: URL, wo Autorisierungsanfragen an Ihre OpenID gesendet werden.
• SCOPES: zusätzliche Bereiche (durch Kommas getrennt), die an den OpenID-Anbieter gesendet werden sollen.
• USER_CLAIM: JWT-Anspruch zur Verwendung als Nutzername. Je nach OpenID-Anbieter können Sie andere Anforderungen auswählen, beispielsweise E-Mail-Adresse oder Name. Allerdings wird anderen Anforderungen als der E-Mail-Adresse die Aussteller-URL vorangestellt, um Namenskonflikte zu vermeiden.
• GROUPS_CLAIM: Name des Anspruchs im OIDC-ID-Token, das die Informationen der Nutzergruppe enthält.
• CERT_AUTHORITY_DATA: Ein optionales base64- und PEM-codiertes Zertifikat für den OIDC-Anbieter. Entfernen Sie es, wenn es nicht erforderlich ist. Codieren Sie das Zertifikat, einschließlich der Header, in base64, um den String zu erstellen. Fügen Sie den erstellten String in certificateAuthorityData als eine Zeile ein.

Nachdem Sie die Datei mit der gewünschten Konfiguration bearbeitet haben, führen Sie den folgenden Befehl aus:

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Dabei gilt:

• USER_CLUSTER_KUBECONFIG: Pfad zur Kubeconfig-Datei des Nutzerclusters.
• OIDC_CONFIG: Pfad zur erstellten Konfigurationsdatei.

RBAC auf dem Nutzercluster einrichten

In diesem Abschnitt wird anhand eines Beispiels erläutert, wie Sie RBAC einrichten, um Zugriff auf einzelne Namespaces zu erteilen. Ausführliche Informationen finden Sie in der Kubernetes RBAC-Dokumentation.

Angenommen, es gibt zwei Namespaces, workload-a und workload-b. Das Ziel besteht darin, die Ressourcen im Namespace workload-a zu erstellen, die der Nutzer [e-mail] kann lesen und schreiben undworkload-b erstellen, die lesbar für den Nutzer [e-mail]. [e-mail] kann nicht auf workload-b zugreifen und [e-mail] kann nicht auf workload-a zugreifen.

Erstellen Sie die Namespaces im Nutzercluster:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

Um den Zugriff auf jeden Namespace zu beschränken, muss die Berechtigung für jeden Namespace definiert werden. In Kubernetes kann dies durch Erstellen einer Rolle durchgeführt werden.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

Die für foo-full-access definierten verbs definieren alle Aktionen, die diese Rolle im Namespace ausführen darf.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

Der für b-read-access angegebene Verben erlauben es der Rolle nur, Ressourcen abzufragen.

Damit Nutzer Berechtigungen erhalten können, müssen RoleBindings erstellt werden. RoleBindings können einzelne Nutzer und Gruppen enthalten. In diesem Beispiel werden einzelne Nutzer angezeigt.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Mit dem obigen RoleBinding (a-full-access-users) werden dem Nutzer [e-mail] die in der Rolle a-full-access definierten Berechtigungen gewährt. Dies bedeutet, dass der Nutzer [e-mail] Lese- und Schreibzugriff auf Ressourcen im Namespace workload-a ausführen kann.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Mit diesem RoleBinding (b-read-access-users) werden dem Nutzer [e-mail] die in der Rolle b-read-access definierten Berechtigungen gewährt. Daher kann der Nutzer [e-mail] nur Ressourcen aus dem Namespace workload-b lesen.

Hinweis: In der Produktion empfehlen wir, Rollen an Gruppen zu binden anstelle von an einzelne Nutzer. Wenden Sie sich an Ihren OIDC-Anbieter, um zu erfahren, wie Sie Gruppen freigeben.

Mit dem OIDC-Anbieter anmelden

Rufen Sie als Administrator des Nutzerclusters die Konfigurationsdatei für die Anmeldung ab, die von allen Nutzern des Nutzerclusters für die Anmeldung verwendet werden soll. Unter Konfigurationsdatei für die Anmeldung beim Nutzercluster herunterladen erfahren Sie, wie Sie die Anmeldekonfiguration aus der UI des Management Center im privaten Anthos-Modus abrufen. Alternativ können Sie die Konfigurationsdatei für die Anmeldung erstellen und dafür Folgendes ausführen:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

Verteilen Sie user-cluster-anthos-config.yaml an die Nutzer des Nutzerclusters.

Authentifizieren Sie sich beim OIDC-Anbieter und folgen Sie der Anleitung in der Befehlszeile:

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

Ersetzen Sie USER_CLUSTER_NAME durch den Namen des Nutzerclusters, wie in der Admin-Konsole angezeigt. --kubeconfig=user-cluster-oidc-kubeconfig ist der Name der Kubeconfig-Ausgabedatei.

Warnung: Die Ausgabe Kubeconfig (user-cluster-oidc-kubeconfig oben) enthält Nutzeranmeldedaten und sollte nicht freigegeben werden.

Verwenden Sie das neue Kubeconfig mit kubectl so:

kubectl --kubeconfig=./user-cluster-oidc-kubeconfig get pods -A

Mit Google SSO authentifizieren

Beachten Sie, dass Google SSO im isolierten Modus nicht verfügbar ist und dieser Abschnitt nur für Demo- und Testzwecke gedacht ist. Wenn Sie die Google SSO verwenden möchten, müssen der Cluster und die Browser in der Lage sein, die SSO-Server von Google zu kontaktieren. Die SSO-Server von Google müssen nicht die Nutzercluster kontaktieren können.

1. Melden Sie sich bei der Google Cloud Console an und wählen Sie ein gültiges Projekt aus.
2. Auf den Abschnitt "API & Dienste > OAuth-Zustimmungsbildschirm" zugreifen
3. Erstellen Sie einen neuen OAuth-Zustimmungsbildschirm. Diese Informationen werden Nutzern normalerweise angezeigt.
   1. Legen Sie für die Anwendungsstartseite die Administrator-URL fest.
4. Führen Sie im Bereich API und Dienste > Anmeldedaten Folgendes aus:
   1. Klicken Sie auf Anmeldedaten erstellen.
   2. Erstellen Sie eine neue OAuth-Client-ID.
   3. Legen Sie für den Anwendungstyp Webanwendung fest.
   4. Relevanten Namen auswählen
   5. Legen Sie für die JavaScript-Quellen https://anthos.example.com fest. Dafür ist https://anthos.example.com der Domainname für das Management Center.
   6. Legen Sie für die autorisierten Weiterleitungs-URIs Folgendes fest:
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
5. Client-ID und Client-Schlüssel in die AdminUI-Konfiguration kopieren
6. Legen Sie die URL des OIDC-Anbieters auf https://accounts.google.com fest.
7. Setzen Sie Username Claim auf email und Scopes auf openid email.
8. Setzen Sie die zusätzlichen Parameter auf prompt=consent,access_type=offline. Andernfalls können Sie sich nicht mit dem Kubernetes API-Server anmelden.
9. Fügen Sie die erste Liste der Nutzer-E-Mail-Adressen durch Kommas getrennt hinzu, um Plattformadministrator-Berechtigungen zu erhalten.
10. Klicken Sie auf Save.

Audit-Logging

Auditing in Kubernetes ist für den privaten Anthos-Modus aktiviert und bietet die Möglichkeit, den Administratorzugriff und die Aktionen auf der Plattform zu prüfen.

Das Audit-Logging kann derzeit nicht für Parameter wie Aufbewahrungsdauer, Aktualisierungsrate oder Chunk-Größe konfiguriert werden. Die Audit-Ebene ist Metadata. Hier werden Metadaten von Anfragen (anfragender Nutzer, Zeitstempel, Ressource, Verb), aber kein Anfrage- oder Antworttext erfasst.

Hinweis: Es wird das k8s-Audit-Logging sowohl von Administrator- als auch von Nutzerclustern exportiert.

Audit-Logging ist im privaten Modus von Anthos standardmäßig aktiviert. Ausführliche Schritte für den Zugriff auf Audit-Logs finden Sie unter Logging und Monitoring.

Hinweis: Dies ist derzeit kein sicherer Speicherort für Audit-Logs. Personen mit ausreichenden k8s-Berechtigungen (z. B. IO) können Audit-Logs löschen oder manipulieren.