Diese Seite richtet sich an Plattformadministratoren.
Auf dieser Seite wird beschrieben, wie Sie die OIDC-Authentifizierung (OpenID Connect) für Nutzercluster aktivieren und die rollenbasierte Zugriffssteuerung (RBAC) einrichten. 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 mit der Anthos Management Center Console finden Sie unter Nutzercluster 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
Rufen Sie die Seite Identität und Zugriff auf.
Klicken Sie auf Profile auf Cluster anwenden.
Wählen Sie in der Drop-down-Liste Profile die Identitätsprofile aus, die angewendet werden sollen.
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 running in
# disconnected 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
Ersetzen Sie Folgendes:
- 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)"
Ersetzen Sie Folgendes:
- USER_CLUSTER_KUBECONFIG: Pfad zur Kubeconfig-Datei des Nutzerclusters.
- OIDC_CONFIG: Pfad zur erstellten Konfigurationsdatei.
RBAC im 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 alice@example.com kann lesen und schreiben undworkload-b erstellen, die lesbar für den Nutzer bob@example.com.
alice@example.com kann nicht auf workload-b zugreifen und bob@example.com 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: prefix-alice@example.com # 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 alice@example.com die in der Rolle a-full-access definierten Berechtigungen gewährt. Dies bedeutet, dass der Nutzer alice@example.com 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: bob@example.com # 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 bob@example.com die in der Rolle b-read-access definierten Berechtigungen gewährt. Daher kann der Nutzer bob@example.com nur Ressourcen aus dem Namespace workload-b lesen.
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. Wie Sie die Anmeldekonfiguration vom Anthos Management Center abrufen, erfahren Sie unter Konfigurationsdatei für die Anmeldung beim Nutzercluster herunterladen. 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_NAME-actl-auth-login-config.yaml
Verteilen Sie USER_CLUSTER_NAME-actl-auth-login-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_NAME-actl-auth-login-config.yaml \
--cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
--preferred-auth="CONFIGURATION_NAME"
Ersetzen Sie USER_CLUSTER_NAME durch den Namen des Nutzerclusters, wie in der Admin-Konsole angezeigt.
--kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig ist der Name der Kubeconfig-Ausgabedatei.
Ersetzen Sie CONFIGURATION_NAME durch den Namen des Identitätsprofils, das zur Authentifizierung dient. Öffnen Sie USER_CLUSTER_NAME-actl-auth-login-config.yaml, um die Profilnamen zu sehen.
Verwenden Sie das neue Kubeconfig mit kubectl so:
kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A