Description des droits RBAC
Les rôles d'accès aux services IAM correspondent au contrôle d'accès basé sur les rôles (RBAC) de Kubernetes au sein des clusters IBM Cloud Kubernetes Service. Les rôles RBAC et les rôles de cluster définissent un ensemble de droits pour déterminer comment les utilisateurs peuvent interagir avec les ressources Kubernetes dans votre cluster.
Avec IBM Cloud IAM, vous pouvez gérer automatiquement RBAC à partir de IBM Cloud, en attribuant aux utilisateurs des rôles d'accès au service IAM. Vous souhaitez peut-être avoir une meilleure compréhension du contrôle d'accès à base de rôles (RBAC) pour personnaliser l'accès aux ressources du cluster, telles que les comptes de service.
- Les rôles IBM Cloud IAM ne peuvent pas être affectés à un compte de service. Vous pouvez à la place affecter directement des rôles RBAC aux comptes de service.
- Les utilisateurs doivent exécuter la commande
ibmcloud ks cluster config
pour que leurs modifications de rôle prennent effet.
Quels sont les types de rôles RBAC?
- Un rôle Kubernetes s'applique aux ressources d'un espace de nom spécifique, tel qu'un déploiement ou un service.
- Un rôle de cluster Kubernetes s'applique aux ressources de l'ensemble du cluster, telles que les nœuds workerk ou aux ressources de portée de l'espace de nom qui se trouvent dans chaque espace de nom, comme les pods.
Que sont les liaisons de rôles RBAC et les liaisons de rôles de cluster?
Les liaisons de rôle appliquent des rôles RBAC ou des rôles de cluster à un espace de noms spécifique. Lorsque vous utilisez une liaison de rôle pour appliquer un rôle, vous octroyez à un utilisateur l'accès à une ressource spécifique dans un espace de noms spécifique. Lorsque vous utilisez une liaison de rôle pour appliquer un rôle de cluster, vous octroyez à un utilisateur l'accès aux ressources propres à un espace de noms pouvant se trouver dans chaque espace de noms, par exemple des pods, mais uniquement au sein d'un espace de noms spécifique.
Les liaisons de rôle de cluster appliquent des rôles de cluster RBAC à tous les espaces de noms du cluster. Lorsque vous utilisez une liaison de rôle de cluster pour appliquer un rôle de cluster, vous octroyez l'accès aux ressources à l'échelle du cluster, par exemple des noeuds worker, ou aux ressources d'espace de noms dans tous les espaces de noms, par exemple des pods.
À quoi ressemblent ces rôles dans mon cluster?
Si vous souhaitez que les utilisateurs soient en mesure d'interagir avec des ressources Kubernetes depuis un cluster, vous devez leur affecter l'accès à un ou plusieurs espaces de noms via des rôles d'accès au service IBM Cloud IAM. Tous les utilisateurs auxquels est affecté un rôle d'accès au service bénéficient automatiquement d'un rôle de cluster RBAC correspondant. Ces rôles de cluster RBAC sont prédéfinis et permettent aux utilisateurs d'interagir avec les ressources Kubernetes dans votre cluster. En outre, une liaison de rôle est créée pour appliquer le rôle de cluster à un espace de noms spécifique ou à tous les espaces de noms.
Pour en savoir plus sur les actions autorisées par chaque rôle RBAC, consultez la rubrique de référence IBM Cloud IAM service access roles. Pour afficher les droits octroyés par chaque rôle RBAC à des ressources Kubernetes individuelles, consultez Droits sur les ressources Kubernetes par rôle RBAC.
Puis-je créer des rôles personnalisés ou des rôles de groupe?
Si vous créez vos propres règles RBAC personnalisées, veillez à ne pas éditer les liaisons de rôle IBM existantes qui se trouvent dans le cluster ou à créer des liaisons de rôle personnalisé portant le même nom que les liaisons IBM existantes. Les modifications que vous apportez aux liaisons de rôle RBAC fournies par IBMne sont pas conservées dans les mises à jour.
Les rôles de cluster view
, edit
, admin
et cluster-admin
sont des rôles prédéfinis qui sont automatiquement créés lorsque vous affectez à un utilisateur le rôle d'accès au service IBM Cloud
IAM correspondant. Pour octroyer d'autres droits Kubernetes, vous pouvez créer vos propres droits RBAC personnalisés. Les rôles RBAC personnalisés s'ajoutent et ne remplacent pas les rôles RBAC que vous avez affectés avec
les rôles d'accès au service. Notez que pour créer des droits RBAC personnalisés, vous devez disposer du rôle d'accès au service IAM Manager qui vous donne le rôle RBAC Kubernetes cluster-admin
. Cependant, les
autres utilisateurs n'ont pas besoin d'un rôle d'accès au service IAM si vous gérez vos propres rôles personnalisés Kubernetes RBAC.
Quand dois-je utiliser des liaisons de rôle de cluster et des liaisons de rôle personnalisées?
Vous envisagerez peut-être d'autoriser certaines personnes à créer et à mettre à jour des pods dans votre cluster. Avec les politiques de sécurité des pods (PSP), vous pouvez utiliser les liaisons de rôles de cluster existantes qui sont fournies avec votre cluster, ou créer les vôtres.
Vous pouvez également souhaiter intégrer des modules complémentaires dans votre cluster. Par exemple, lorsque vous configurez Helm dans votre cluster.
Création de droits RBAC personnalisés pour les utilisateurs, les groupes ou les comptes de service
Les rôles de cluster view
, edit
, admin
et cluster-admin
sont automatiquement créés lorsque vous affectez le rôle d'accès au service IBM Cloud IAM correspondant. Vous avez besoin que les règles
d'accès à votre cluster soient plus granulaires que ne le permettent les droits d'accès prédéfinis ? Pas de problème ! Vous pouvez créer des rôles RBAC et des rôles de cluster personnalisés.
Vous pouvez affecter des rôles RBAC personnalisés et des rôles de cluster à des utilisateurs individuels, à des groupes d'utilisateurs ou à des comptes de service. Lorsqu'une liaison est créée pour un groupe, elle concerne tout utilisateur qui est ajouté ou supprimé dans ce groupe. Lorsque vous ajoutez des utilisateurs dans un groupe, ils ont accès aux droits du groupe en plus des droits d'accès individuels que vous leur octroyez. S'ils sont supprimés, leur accès est révoqué. Notez que vous ne pouvez pas ajouter des comptes de service à des groupes d'accès.
Si vous souhaitez attribuer un accès à un processus de conteneur qui s'exécute dans des pods, tel qu'une chaîne d'outils de livraison continue, vous pouvez utiliser Kubernetes ServiceAccounts
. Pour suivre un tutoriel qui montre comment configurer des comptes de service pour Travis et Jenkins et attribuer des rôles RBAC personnalisés aux comptes de service,
voir l'article de blog Kubernetes ServiceAccounts
pour une utilisation dans des systèmes automatisés.
Pour éviter les modifications de rupture, ne modifiez pas les rôles de cluster prédéfinis view
, edit
, admin
et cluster-admin
. Les rôles RBAC personnalisés s'ajoutent et ne remplacent pas les
rôles RBAC que vous avez affectés avec les rôles d'accès au service IBM Cloud IAM.
-
Accès dans un espace de nom : pour autoriser un utilisateur, un groupe d'accès ou un compte de service à accéder à une ressource dans un espace de noms spécifique, choisissez l'une des combinaisons suivantes :
- Créez un rôle et appliquez-le avec une liaison de rôle. Cette option est utile pour contrôler l'accès à une ressource unique qui n'existe que dans un espace de noms, par exemple un déploiement d'application.
- Créez un rôle de cluster et appliquez-le avec une liaison de rôle. Cette option est utile pour contrôler l'accès à des ressources générales dans un espace de noms, par exemple des pods.
-
Accès à l'échelle du cluster : pour autoriser un utilisateur ou un groupe d'accès à accéder à des ressources à l'échelle du cluster ou à des ressources dans tous les espaces de noms, créez un rôle de cluster et appliquez-le avec une liaison de rôle de cluster. Cette option est utile pour contrôler l'accès aux ressources qui ne sont pas limitées aux espaces de noms, par exemple des noeuds worker, ou à des ressources dans tous les espaces de noms de votre cluster, par exemple des pods dans chaque espace de noms.
-
Assurez-vous que vous avez le rôle d'accès au service Manager IAM pour tous les espaces de noms.
-
Pour attribuer un accès à des utilisateurs individuels ou à des utilisateurs d'un groupe d'accès, il faut s'assurer que l'utilisateur ou le groupe s'est vu attribuer au moins un rôle d'accès à la plate-forme IAM au niveau du service IBM Cloud Kubernetes Service.
Pour créer des droits RBAC personnalisés :
-
Créez un fichier
.yaml
similaire au suivant pour définirrole
oucluster role
.kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: my_role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] - apiGroups: ["apps", "extensions"] resources: ["daemonsets", "deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Comprendre les paramètres YAML Paramètre Description kind
Utilisez Role
pour octroyer l'accès aux ressources dans un espace de noms spécifique. UtilisezClusterRole
pour octroyer l'accès aux ressources à l'échelle du cluster, par exemple des noeuds worker, ou à des ressources limitées à des espaces de noms, par exemple des pods dans tous les espaces de noms.metadata.namespace
Pour la section kind Role
uniquement : indiquez l'espace de noms Kubernetes auquel l'accès est octroyé.rules.apiGroups
Spécifiez les groupes de l'API Kubernetes avec lesquels vous souhaitez que les utilisateurs puissent interagir, tels que "apps"
,"batch"
ou"extensions"
. Pour accéder au groupe d'API principal sur le chemin RESTapi/v1
, laissez le groupe vide :[""]
.rules.resources
Indiquez les types de ressources Kubernetes auxquels vous souhaitez accorder l'accès, tels que "daemonsets"
,"deployments"
,"events"
ou"ingresses"
. Si vous spécifiez"nodes"
, la valeur de kind doit êtreClusterRole
.rules.verbs
Spécifiez les types d' actions que vous voulez que les utilisateurs puissent effectuer, tels que "get"
,"list"
,"describe"
,"create"
, ou"delete"
. -
Créez le rôle ou le rôle de cluster dans votre cluster.
kubectl apply -f my_role.yaml
-
Vérifiez que le rôle ou le rôle de cluster est créé.
- Rôle :
kubectl get roles -n <namespace>
- Rôle de cluster :
kubectl get clusterroles
- Rôle :
-
Liez les utilisateurs au rôle ou au rôle de cluster en créant un fichier
.yaml
. Notez l'unique URL à utiliser pour chaque nom dans 'subjects'.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: my_role_binding namespace: default subjects: - kind: User name: IAM#user1@example.com apiGroup: rbac.authorization.k8s.io - kind: Group name: team1 apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount name: <service_account_name> namespace: <kubernetes_namespace> roleRef: kind: Role name: my_role apiGroup: rbac.authorization.k8s.io
Comprendre les paramètres YAML Paramètre Description kind
- Spécifiez
RoleBinding
Role
ouClusterRole
d'espace de nom. - Indiquez
ClusterRoleBinding
pour un rôle de cluster (ClusterRole
) à l'échelle d'un cluster.
apiVersion
- Pour les clusters qui exécutent Kubernetes 1.8 ou version ultérieure, utilisez
rbac.authorization.k8s.io/v1
. - Pour les versions antérieures, utilisez
apiVersion: rbac.authorization.k8s.io/v1beta1
.
metadata.namespace
- Pour le type
RoleBinding
: zpécifiez l'espace de nom Kubernetes auquel l'accès est accordé. - Pour la section kind
ClusterRoleBinding
: n'utilisez pas la zonenamespace
.
metadata.name
Nommez la liaison de rôle ou la liaison de rôle de cluster. subjects.kind
Indiquez le type de rôle suivant :
User
: liez le rôle RBAC ou le rôle de cluster à un utilisateur individuel dans votre compte.Group
: liez le rôle RBAC ou le rôle de cluster à un groupe d'accès IBM Cloud IAM dans votre compte.ServiceAccount
: liez le rôle RBAC ou le rôle de cluster à un compte de service dans un espace de nom de votre cluster.
subjects.name
- Pour
User
: ajoutez l'adresse électronique de l'utilisateur individuel àIAM#
comme suit :IAM#user@email.com
. - Pour
Group
: indiquez le nom du groupe d'accès IBM Cloud IAM dans votre compte. - Pour
ServiceAccount
: spécifiez le nom du compte de service.
subjects.apiGroup
- Pour
User
ouGroup
: utilisezrbac.authorization.k8s.io
. - Pour
ServiceAccount
: n'incluez pas cette zone.
subjects.namespace
Pour ServiceAccount
uniquement : indiquez le nom de l'espace de noms Kubernetes dans lequel est déployé le compte de service.roleRef.kind
Entrez la même valeur que pour kind
dans le fichier.yaml
du rôle :Role
ouClusterRole
.roleRef.name
Entrez le nom du fichier .yaml
du rôle.roleRef.apiGroup
Utilisez rbac.authorization.k8s.io
. - Spécifiez
-
Créez la ressource de liaison de rôle ou de liaison de rôle de cluster dans votre cluster.
kubectl apply -f my_role_binding.yaml
-
Vérifiez que la liaison est créée.
kubectl get rolebinding -n <namespace>
-
Facultatif : pour imposer le même niveau d'accès utilisateur dans d'autres espaces de noms, vous pouvez copier les liaisons de rôle pour ces rôles ou rôles de cluster dans d'autres espaces de noms.
- Copiez la liaison de rôle d'un espace de noms à un autre.
Par exemple, copiez la liaison de rôlekubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -
custom-role
de l'espace de nomsdefault
dans l'espace de nomstestns
.kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
- Vérifiez que la liaison de rôle a été copiée. Si vous avez ajouté un groupe d'accès IBM Cloud IAM dans la liaison de rôle, chaque utilisateur de ce groupe est ajouté individuellement, et non pas en tant qu'ID de groupe d'accès.
kubectl get rolebinding -n <namespace_2>
- Copiez la liaison de rôle d'un espace de noms à un autre.
Vous venez de créer et de lier un rôle de cluster ou un rôle RBAC Kubernetes personnalisé, effectuez à présent le suivi auprès des utilisateurs. Demandez-leur de tester une action qu'ils ont le droit d'effectuer en fonction du rôle, par exemple, supprimer un pod.
Extension des droits existants en agrégeant des rôles de cluster
Vous pouvez étendre les droits existantes de vos utilisateurs en agrégeant ou en combinant des rôles de cluster à d'autres rôles de cluster. Lorsque vous affectez un rôle d'accès au service IBM Cloud à un utilisateur, celui-ci est ajouté à un rôle de cluster RBAC Kubernetes correspondant. Cependant, vous souhaiterez peut-être autoriser certains utilisateurs à effectuer des opérations supplémentaires.
Par exemple, un utilisateur avec le rôle de cluster admin
au niveau de l'espace de nom ne peut pas utiliser la commande kubectl top pods
pour afficher les mesures de tous les pods de l'espace de nom. Vous pouvez agréger
un rôle de cluster de manière à autoriser les utilisateurs dotés du rôle de cluster admin
à exécuter la commande top pods
. Pour plus d'informations, consultez la documentation de Kubernetes.
Quelles sont les opérations courantes pour lesquelles je pourrais souhaiter étendre les autorisations pour un rôle de cluster par défaut?
Passez en revue les opérations autorisées par chaque rôle de cluster RBAC par défaut afin d'obtenir une bonne idée de ce que vos utilisateurs peuvent faire, puis comparez ces opérations autorisées à celles que vos utilisateurs doivent pouvoir effectuer.
Si vos utilisateurs disposant du même rôle de cluster rencontrent des erreurs semblables aux suivantes pour le même type d'opération, vous souhaiterez peut-être étendre le rôle de cluster afin d'inclure cette opération.
Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAM#myname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"
Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
-
Créez un fichier YAML de rôle de cluster. Dans la section
labels
, spécifiez le rôle de cluster existant auquel vous souhaitez agréger des droits. L'exemple suivant étend le rôle de clusteradmin
prédéfini pour autoriser les utilisateurs à exécuterkubectl top pods
. Pour plus d'exemples, voir la documentation de Kubernetes.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: view-pod-metrics labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rules: - apiGroups: - "metrics.k8s.io" resources: - pods verbs: - list
Comprendre les paramètres YAML Paramètre Description metadata.name
Entrez un nom pour le rôle de cluster. N'utilisez pas utilise les noms de rôle de cluster prédéfinis : view
,edit
,admin
etcluster-admin
.metadata.labels
Ajoutez un libellé qui correspond au rôle de cluster que vous souhaitez agréger au format
rbac.authorization.k8s.io/aggregate-to-<cluster_role>: "true"
. Les libellés des rôles de cluster prédéfinis sont les suivants.- Rôle d'accès au service IAM Manager, étendu à un espace de nom :
rbac.authorization.k8s.io/aggregate-to-admin: "true"
- Rôle d'accès au service IAM Writer :
rbac.authorization.k8s.io/aggregate-to-edit: "true"
- Rôle d'accès au service IAM Reader :
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules.apiGroups
Spécifiez les groupes de l'API Kubernetes avec lesquels vous souhaitez que les utilisateurs puissent interagir, tels que "apps"
,"batch"
ou"extensions"
. Pour accéder au groupe d'API principal sur le chemin RESTapi/v1
, laissez le groupe vide :[""]
.rules.resources
Indiquez les types de ressources Kubernetes auxquels vous souhaitez accorder l'accès, tels que "daemonsets"
,"deployments"
,"events"
ou"ingresses"
.rules.verbs
Spécifiez les types d' actions que vous voulez que les utilisateurs puissent effectuer, tels que "get"
,"list"
,"describe"
,"create"
, ou"delete"
. - Rôle d'accès au service IAM Manager, étendu à un espace de nom :
-
Créez le rôle de cluster dans votre cluster. Tout utilisateur ayant une liaison de rôle au rôle de cluster
admin
dispose à présent des droits supplémentaires issus du rôle de clusterview-pod-metrics
.kubectl apply -f <cluster_role_file.yaml>
-
Assurez le suivi des utilisateurs qui disposent du rôle de cluster
admin
. Demandez-leur d'actualiser leur configuration de cluster et de tester l'action, par exemple,kubectl top pods
.
Vérification des rôles RBAC
Vérifiez vos rôles RBAC personnalisés ou l'accès au service IAM synchronisé avec les rôles RBAC dans votre cluster IBM Cloud Kubernetes Service.
Vérification des rôles du contrôle d'accès à base de rôles (RBAC) à partir de l'interface utilisateur
-
Connectez-vous à la console.
-
Cliquez sur le cluster incluant les rôles du contrôle d'accès à base de rôles (RBAC) à vérifier.
-
Cliquez sur Tableau de bord Kubernetes.
Si vous disposez d'un cluster qui fonctionne uniquement avec un réseau privé, vous ne pourrez peut-être pas ouvrir le tableau de bord sauf si vous vous trouvez dans un réseau privé virtuel (VPN). Voir Accès aux clusters via le noeud final de service cloud privé.
-
Dans la section Cluster, consultez les liaisons de rôle de cluster, les rôles de cluster, les liaisons de rôle et les rôles.
Vérification des rôles du contrôle d'accès à base de rôles (RBAC) à l'aide de l'interface de ligne de commande
-
Vérifiez que l'utilisateur est ajouté au rôle du contrôle d'accès à base de rôles (RBAC). Les utilisateurs ne sont pas ajoutés à une liaison de rôle s'ils disposent de droits supérieurs. Par exemple, si les utilisateurs disposent d'un rôle de cluster et se trouvent dans une liaison de rôle de cluster, ils ne sont pas non plus ajoutés à chaque liaison de rôle d'espace de noms individuelle.
Vous devez être administrateur de cluster (rôle d'accès au service Responsable dans tous les espaces de nom) pour vérifier les liaisons de rôle et les liaisons de rôle de cluster.
- Lecteur:
kubectl get rolebinding ibm-view -o yaml -n <namespace>
- Writer :
kubectl get rolebinding ibm-edit -o yaml -n <namespace>
- Manager, avec une portée définie à l'espace de noms :
kubectl get rolebinding ibm-operate -o yaml -n <namespace>
- Manager, pour tous les espaces de nom :
kubectl get clusterrolebinding ibm-admin -o yaml
- Lecteur:
Exemple de sortie
Si vous affectez à l'utilisateur user@email.com
et au groupe d'accès team1
le rôle d'accès au service Lecteur et que vous exécutez la commande kubectl get rolebinding ibm-view -o yaml -n default
,
vous obtenez l'exemple de sortie suivant.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: 2018-05-23T14:34:24Z
name: ibm-view
namespace: default
resourceVersion: "8192510"
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/ibm-view
uid: 63f62887-5e96-11e8-8a75-b229c11ba64a
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: IAM#user@email.com
- apiGroup: rbac.authorization.k8s.io
kind: group
name: team1
Rôles d'accès au service Kubernetes et rôles RBAC correspondants
Le tableau suivant présente les droits d'accès aux ressources Kubernetes qui sont octroyés par chaque rôle d'accès au service et le rôle RBAC correspondant.
Rôle d'accès au service | Rôle RBAC correspondant, liaison et portée | Droits sur les ressources Kubernetes |
---|---|---|
Rôle Lecteur |
Lorsqu'il s'applique à un espace de nom : le rôle de cluster
|
|
Rôle Auteur | Lorsqu'il est limité à un espace de noms : edit rôle de grappe appliqué par la liaison de rôle dans cet espace de noms ibm-edit dans cet espace de noms.
Lorsqu'il est étendu à tous les espaces de noms : |
|
Rôle Gestionnaire | Lorsqu'il s'agit d'un espace de nom: rôle de cluster admin appliqué par la liaison de rôle ibm-operate dans cet espace de nom
Lorsqu'il est appliqué à tous les espaces de nom : rôle de cluster |
Lorsqu'il s'agit d'un espace de noms :
|
Droits d'accès aux ressources Kubernetes par rôle RBAC
Tous les utilisateurs auxquels est affecté un rôle d'accès au service IBM Cloud IAM bénéficient automatiquement d'un rôle Kubernetes RBAC (contrôle d'accès à base de rôles) prédéfini correspondant, dans un espace de noms spécifié. Si vous envisagez de gérer vos propres rôles RBAC Kubernetes personnalisés, voir Création de droits RBAC personnalisés pour les utilisateurs, les groupes ou les comptes de service. Pour plus de détails sur le nom d'utilisateur, voir Détails de l'émetteur IBM Cloud IAM pour les utilisateurs RBAC.
Vous vous demandez si vous disposez des droits appropriés pour exécuter une commande kubectl
spécifique sur une ressource dans un espace de noms ? Exécutez la commande kubectl auth can-i
.
Le tableau suivant présente les droits octroyés par chaque rôle RBAC à des ressources Kubernetes individuelles. Les autorisations sont présentées sous la forme de verbs
(ou actions) qu'un utilisateur ayant ce rôle peut effectuer
sur la ressource, par exemple "obtenir", "lister", "décrire", "créer" ou "supprimer".
Ressources Kubernetes | view |
edit |
admin et cluster-admin |
---|---|---|---|
bindings |
get, list, watch | get, list, watch | obtenir, répertorier, surveiller cluster-admin uniquement: créer, supprimer, mettre à jour |
configmaps |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
cronjobs.batch |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
daemonsets.apps |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
daemonsets.extensions |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.apps |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.apps/rollback |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.apps/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.extensions |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.extensions/rollback |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
deployments.extensions/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
endpoints |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
events |
get, list, watch | get, list, watch | get, list, watch |
horizontalpodautoscalers.autoscaling |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
ingresses.extensions |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
jobs.batch |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
limitranges |
get, list, watch | get, list, watch | get, list, watch |
localsubjectaccessreviews |
|
|
create |
namespaces |
get, list, watch | get, list, watch | get, list, watch cluster-admin uniquement: create, delete |
namespaces/status |
get, list, watch | get, list, watch | get, list, watch |
networkpolicies |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
networkpolicies.extensions |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
node |
Aucun | Aucun | admin étendu à un espace de nom : aucun
|
persistentvolume |
Aucun | Aucun | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
persistentvolumeclaims |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
poddisruptionbudgets.policy |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
pods |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, top , patcher, mettre à jour, surveiller |
pods/attach |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
pods/exec |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
pods/log |
get, list, watch | get, list, watch | get, list, watch |
pods/portforward |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
pods/proxy |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
pods/status |
get, list, watch | get, list, watch | get, list, watch |
replicasets.apps |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicasets.apps/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicasets.extensions |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicasets.extensions/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicationcontrollers |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicationcontrollers/scale |
get, list, watch | cr}eate, delete, deletecollection , get, list, patch, update, watch |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
replicationcontrollers/status |
get, list, watch | get, list, watch | get, list, watch |
replicationcontrollers.extensions/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
resourcequotas |
get, list, watch | get, list, watch | get, list, watch |
resourcequotas/status |
get, list, watch | get, list, watch | get, list, watch |
rolebindings |
|
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
roles |
|
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
secrets |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
serviceaccounts |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller, impersonate |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller, impersonate |
services |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
services/proxy |
|
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
statefulsets.apps |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
statefulsets.apps/scale |
get, list, watch | créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
créer, supprimer, deletecollection , obtenir, lister, patcher, mettre à jour, surveiller |
Détails de l'émetteur IBM Cloud IAM pour les utilisateurs RBAC
Les utilisateurs dotés d'un rôle d'accès au service sur IBM Cloud Kubernetes Service dans IAM reçoivent des rôles utilisateur correspondants dans RBAC. Les détails de l'utilisateur RBAC comprennent un ID d'émetteur,
une réclamation d'identificateur de sujet et un nom d'utilisateur Kubernetes uniques. Ces détails varient en fonction de la version Kubernetes du cluster. Lorsque vous mettez à jour un cluster à partir d'une version précédente, les détails
sont automatiquement mis à jour. Les noms d'utilisateur RBAC sont préfixés avec IAM#
. Pour plus d'informations sur le fonctionnement de l'authentification OpenID, voir la documentation Kubernetes.
Vous pouvez utiliser les informations ci-après si vous générez des outils d'automatisation dans le cluster qui s'appuient sur les détails de l'utilisateur pour s'authentifier auprès du serveur d'API Kubernetes.
Version | Emetteur | Revendication | Casse* |
---|---|---|---|
Kubernetes | https://iam.cloud.ibm.com/identity |
realmed_sub_<account_ID> |
minuscule |
*
: exemple de minuscule : user.name@company.com
. Exemple de casse mixte : User.Name@company.com
.