IBM Cloud Docs
Description des droits RBAC

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.

  • Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

  • 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 :

  1. Créez un fichier .yaml similaire au suivant pour définir role ou cluster 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. Utilisez ClusterRole 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 REST api/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 être ClusterRole.
    rules.verbs Spécifiez les types d' actions que vous voulez que les utilisateurs puissent effectuer, tels que "get", "list", "describe", "create", ou "delete".
  2. Créez le rôle ou le rôle de cluster dans votre cluster.

    kubectl apply -f my_role.yaml
    
  3. 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
      
  4. 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 ou ClusterRole 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 zone namespace.
    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 ou Group : utilisez rbac.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 ou ClusterRole.
    roleRef.name Entrez le nom du fichier .yaml du rôle.
    roleRef.apiGroup Utilisez rbac.authorization.k8s.io.
  5. 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
    
  6. Vérifiez que la liaison est créée.

    kubectl get rolebinding -n <namespace>
    
  7. 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.

    1. Copiez la liaison de rôle d'un espace de noms à un autre.
      kubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -
      
      Par exemple, copiez la liaison de rôle custom-role de l'espace de noms default dans l'espace de noms testns.
      kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
      
    2. 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>
      

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.

  1. 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 cluster admin prédéfini pour autoriser les utilisateurs à exécuter kubectl 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 et cluster-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 REST api/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".
  2. 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 cluster view-pod-metrics.

    kubectl apply -f <cluster_role_file.yaml>
    
  3. 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

  1. Connectez-vous à la console.

  2. Cliquez sur le cluster incluant les rôles du contrôle d'accès à base de rôles (RBAC) à vérifier.

  3. 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é.

  4. 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

  1. Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

  2. 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
      

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.

Droits d'accès aux ressources Kubernetes par service et rôles RBAC correspondants
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 view appliqué par la liaison de rôle ibm-view dans cet espace de nom.

  • Lorsqu'il s'applique à tous les espaces de nom : rôle de cluster view appliqué par la liaison de rôle ibm-view dans chaque espace de nom du cluster. Vous pouvez également afficher le cluster dans la console et l'interface de ligne de commande IBM Cloud.
  • Accès en lecture aux ressources d'un espace de nom
  • Aucun accès en lecture aux rôles et aux liaisons de rôle ou aux secrets de Kubernetes
  • Accès au tableau de bord Kubernetes pour afficher les ressources d'un espace de nom.
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 : edit rôle de grappe appliqué par la liaison de rôle ibm-edit dans chaque espace de noms du cluster

  • Accès en lecture/écriture aux ressources dans un espace de nom
  • Pas d'accès en lecture/écriture aux rôles et aux liaisons de rôle<
  • Accédez au tableau de bord Kubernetes pour afficher les ressources d'un espace de nom.
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 cluster-admin appliqué par la liaison de rôle de cluster ibm-admin qui s'applique à tous les espaces de nom.

Lorsqu'il s'agit d'un espace de noms :

  • Accès en lecture/écriture à toutes les ressources d'un espace de noms, mais pas au quota de ressources ni à l'espace de noms lui-même
  • Création de rôles RBAC et de liaisons de rôles dans un espace de noms
  • Accès au tableau de bord Kubernetes pour visualiser toutes les ressources d'un espace de noms
    Lorsqu'il s'agit de tous les espaces de noms :
  • Accès en lecture/écriture à toutes les ressources de chaque espace de noms
  • Créer des rôles RBAC et des liaisons de rôles dans un espace de noms ou des rôles de cluster et des liaisons de rôles de cluster dans tous les espaces de noms
  • Accéder au tableau de bord Kubernetes
  • Créer une ressource Ingress qui rend les applications publiquement disponibles
  • Examiner les métriques de cluster, par exemple avec les commandes kubectl top pods, kubectl top nodes, ou kubectl get nodes
  • Créer et mettre à jour des pods privilégiés et non privilégiés (restreints)

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".

Droits d'accès aux ressources Kubernetes octroyés par chaque rôle RBAC prédéfini
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

cluster-admin pour tous les espaces de nom : tous les verbes

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.

IBM Cloud Détails de l'émetteur IAM pour les utilisateurs RBAC
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.