Utiliser le contrôle d'accès basé sur les rôles avec Oracle Cloud Native Environment

Présentation

Avec l'augmentation du nombre de déploiements dans votre grappe Kubernetes, vous aurez peut-être besoin d'aide pour la gérer. L'API Kubernetes permet d'ajouter des utilisateurs et de définir leurs autorisations à la grappe.

Une fois l'utilisateur authentifié, Kubernetes vérifie les actions que l'utilisateur est autorisé à effectuer. Le contrôle d'accès basé sur le rôle est pris en charge de manière native par Kubernetes et activé par défaut dans Oracle Cloud Native Environment (Oracle CNE). Ce qui en fait l'une des méthodes de contrôle d'accès couramment utilisées. Le contrôle d'accès par rôle (RBAC) vous permet de gérer l'accès aux ressources déployées dans l'environnement Kubernetes en appliquant des règles qui limitent l'accès des utilisateurs aux ressources de grappe. Ces règles peuvent être restreintes à l'espace de noms à l'aide d'un rôle ou à l'échelle de la grappe à l'aide d'un ClusterRole.

Vous trouverez utile de comprendre les principaux composants du contrôle d'accès basé sur les rôles (RBAC) dans Kubernetes, à savoir :

Un autre moyen de gérer l'accès à la grappe Kubernetes est le contrôle d'accès basé sur les attributs, qui permet un réglage plus fin des politiques par rapport au contrôle d'accès basé sur les attributs. Mais cela sort du cadre de ce tutoriel.

Ce tutoriel présente les bases de l'utilisation du contrôle d'accès par rôle (RBAC) pour gérer l'accès à votre grappe Kubernetes et présente un cas d'utilisation simple.

Pour plus d'informations sur Oracle Cloud Native Environment 2, veuillez consulter la documentation de version actuelle.

Objectifs

Dans ce tutoriel, vous apprendrez à :

Préalables

Configurer Oracle Cloud Native Environment

Note : Si vous exécutez votre propre location, lisez les préalables du projet linux-virt-labs GitHub README.md et remplissez les conditions requises avant de déployer l'environnement de laboratoire.

  1. Ouvrez un terminal sur le Luna Desktop.

  2. Clonez le projet linux-virt-labs GitHub.

    git clone https://github.com/oracle-devrel/linux-virt-labs.git

  3. Accédez au répertoire de travail.

    cd linux-virt-labs/ocne2

  4. Installez les collections requises.

    ansible-galaxy collection install -r requirements.yml

  5. Déployez l'environnement de l'exercice.

    ansible-playbook create_instance.yml -e localhost_python_interpreter="/usr/bin/python3.6" -e install_ocne_rpm=true -e create_ocne_cluster=true -e "ocne_cluster_node_options='-n 1 -w 1'"

    L'environnement de laboratoire gratuit nécessite la variable supplémentaire local_python_interpreter, qui définit ansible_python_interpreter pour les lectures exécutées sur localhost. Cette variable est nécessaire car l'environnement installe l'ensemble RPM pour la trousse SDK Oracle Cloud Infrastructure pour Python, située sous les modules python3.6.

    La forme de déploiement par défaut utilise le processeur AMD et Oracle Linux 8. Pour utiliser une unité centrale Intel ou Oracle Linux 9, ajoutez -e instance_shape="VM.Standard3.Flex" ou -e os_version="9" à la commande de déploiement.

    Important : Attendez que le livre de jeu s'exécute avec succès et atteignez la tâche Mettre en pause. À ce stade du livre de jeux, l'installation du CNE Oracle est terminée et les instances sont prêtes. Prenez note de la lecture précédente, qui imprime les adresses IP publiques et privées des noeuds qu'il déploie et toutes les autres informations de déploiement nécessaires lors de l'exécution de l'exercice.

Accéder à la grappe Kubernetes

  1. Ouvrez un terminal et connectez-vous au moyen de SSH à l'instance ocne.

    ssh oracle@<ip_address_of_instance>

  2. Attendez que la grappe se stabilise et que tous les pods soient en cours d'exécution.

    watch kubectl get pods -A

    Une fois que tous les pods affichent le statut STATUS En cours d'exécution, entrez Ctrl-C pour quitter la commande watch.

  3. Vérifiez le nombre de noeuds présents.

    kubectl get nodes

Confirmer la configuration RBAC courante

RBAC gère les autorisations pour les actions que vous effectuez sur les ressources déployées sur votre grappe Kubernetes. Vous allez vérifier que RBAC est activé et vérifier les rôles par défaut dans votre grappe.

  1. Confirmer que le contrôle d'accès par rôle (RBAC) est activé.

    Si l'API rbac.authorization.k8s.io est visible, cela signifie que RBAC est configuré et utilisé pour contrôler les actions que les utilisateurs ou les comptes de service peuvent effectuer sur les ressources de grappe.

    kubectl api-versions | grep rbac

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1

  2. Afficher les rôles de grappe intégrés.

    kubectl get clusterroles | grep admin

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl get clusterroles | grep admin
admin                                                                  2025-07-23T10:21:55Z
cluster-admin                                                          2025-07-23T10:21:55Z
system:aggregate-to-admin                                              2025-07-23T10:21:55Z
system:kubelet-api-admin                                               2025-07-23T10:21:55Z

    Les utilisateurs normaux utilisent les rôles admin et cluster-admin, tandis que l'API RBAC réserve les rôles system: pour les composants internes.

  3. Listez les autorisations pour cluster-admin.

    kubectl describe clusterrole cluster-admin

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

    Les astérisques des colonnes Verbes et Ressources signifient que le rôle cluster-admin peut effectuer n'importe quelle action. Une liste de haut niveau des opérations (verbes) disponibles pour chaque version de Kubernetes est disponible dans l'aperçu de l'API pour cette version. Par exemple, dans Kubernetes v1.33.0. Une liste détaillée des opérations valides (Verbes) disponibles pour chaque type de ressource est disponible en exécutant kubectl api-resources -o wide à partir de la ligne de commande.

    Toutefois, comme vous ne vous connectez pas à kubectl, comment Kubernetes sait-il qui est l'utilisateur qui exécute la commande? Les systèmes de production utilisent généralement un serveur LDAP pour l'authentification. Un fichier ServiceAccount peut être utilisé si un système d'authentification externe n'est pas disponible.

    Note : ServiceAccounts sont utilisés par les charges de travail automatisées, telles que les pipelines d'intégration et de développement en continu, mais peuvent également être utilisés pour les tests.

Créer un rôle

Un rôle est une ressource restreinte à l'espace de noms qui définit les autorisations d'accès aux ressources Kubernetes dans un espace de noms unique.

Créer un espace de noms et un rôle

  1. Créez un espace de noms.

    Créez un espace de noms pour cet exemple.

    kubectl create namespace rbac-example

  2. Créer un rôle.

    Créez un rôle qui accorde l'accès en lecture seule ('get' et 'list' autorisations) aux pods et aux déploiements dans l'espace de noms rbac-exemple.

    cat << EOF | tee pod-reader-role.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: rbac-example
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
EOF

    Où :

    • rules: - Définit les autorisations accordées au rôle. Cet exemple définit deux règles (voir ci-dessous).
    • apiGroups: [""] - Permet à l'utilisateur ou au compte de service lié à cette règle d'extraire et de lister les pods dans l'espace de noms rbac-example.
    • apiGroups: ["apps"] - Permet à l'utilisateur ou au compte de service lié à cette règle d'extraire et de lister les déploiements dans l'espace de noms rbac-example.

  3. Appliquez le fichier.

    kubectl apply -f pod-reader-role.yaml

  4. Vérifiez les autorisations du rôle de lecteur de pod nouvellement créé.

    kubectl describe role/pod-reader -n rbac-example

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl describe role/pod-reader -n rbac-example
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
 pods              []                 []              [get list]
 deployments.apps  []                 []              [get list]

Créer un utilisateur et lier au rôle

  1. Créez un utilisateur ServiceAccount nommé pod-reader-user et liez-le au rôle pod-reader.

    cat << EOF | tee pod-reader-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac-example
roleRef:
  name: pod-reader
  kind: Role
subjects:
- kind: ServiceAccount
  name: pod-reader-user
  namespace: rbac-example
EOF

    Où :

    • ServiceAccount crée le compte de service.
      • name: - Nom de l'utilisateur du compte de service (pod-reader-user).
      • namespace - Espace de noms où il est créé (rbac-example).
    • RoleBinding accorde les autorisations relatives à l'espace de noms au compte de service.
      • roleRef: - Spécifie le rôle de liaison. Dans cet exemple, il référence un rôle nommé pod-reader.
      • subjects: - Spécifie l'entité à laquelle accorder les autorisations. Dans cet exemple, un compte de service nommé pod-reader-user.

  2. Appliquez le fichier.

    kubectl apply -f pod-reader-user.yaml

Tester RoleBinding

Ensuite, testez RoleBinding en créant un nouveau pod et en y accédant à l'aide du nouveau compte de service pod-reader-user.

  1. Créez un nouveau déploiement de test.

    cat << EOF | tee testpod.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: rbac-example
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 80
  serviceAccountName: pod-reader-user
EOF

    Où :

    • spec: définit l'état souhaité du pod.
      • containers: - Spécifie la liste des conteneurs à exécuter dans le pod. Dans cet exemple, il n'y a qu'un seul conteneur.
        • name: - Nom du conteneur (test-container).
        • image: - Image à utiliser (ghcr.io/oracle/oraclelinux9-nginx:1.20).
        • ports: - Spécifie le port exposé par le conteneur. Dans cet exemple, il s'agit du port 80 (containerPort: 80).
      • serviceAccountName: - Spécifie le compte de service à utiliser pour le pod. Dans cette configuration, le pod utilise les autorisations et les données d'identification affectées au compte de service pod-reader-user.

  2. Appliquez le fichier.

    kubectl apply -f testpod.yaml

  3. Maintenant, essayez d'accéder au pod à l'aide de pod-reader-user ServiceAccount.

    kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example

    Vous devez voir yes comme sortie, indiquant que pod-reader-user est autorisé à accéder au pod.

    Note : Utilisez la fonctionnalité kubectl auth can-i pour exécuter des commandes en tant que compte d'utilisateur ServiceAccount nouvellement créé afin de vérifier qu'une action est autorisée.

  4. Vérifiez que ServiceAccount fonctionne comme prévu.

    kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          109s

  5. Essayez de supprimer un pod à l'aide du rôle pod-reader-user.

    kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example
Error from server (Forbidden): pods "test-pod" is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot delete resource "pods" in API group "" in the namespace "rbac-example"

    Le rôle pod-reader-user ne peut pas supprimer les pods dans rbac-example. Peut-être peuvent-ils commencer de nouveaux pods?

  6. Essayez d'exécuter un pod à l'aide du rôle pod-reader-role.

    kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:default:my-serviceaccount -n rbac-example

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot create resource "pods" in API group "" in the namespace "rbac-example"

    Cette erreur est correcte car le rôle pod-reader-user n'est autorisé à effectuer que des actions get et list sur les ressources de pod dans l'espace de noms rbac-example de la grappe. Les autres actions, delete (Supprimer) ou create (Créer), ne sont pas autorisées.

Créer un ClusterRole

ClusterRoles est similaire aux rôles, mais ils définissent les autorisations autorisées sur les ressources dans l'ensemble de la grappe.

Note : Soyez prudent lorsque vous accordez des autorisations trop générales. Utilisez plutôt le moins 'principe du moindre privilège' pour accorder aux utilisateurs et aux comptes de service uniquement les autorisations nécessaires pour effectuer les tâches qui leur sont affectées.

Créer un fichier ClusterRole et ClusterRoleBinding

L'exemple précédent montre comment créer un utilisateur et un rôle propres à un espace de noms. Les étapes suivantes montrent comment créer un fichier ClusterRole et le lier à un utilisateur pour lui accorder un accès administrateur à l'échelle de la grappe.

  1. Créez une nouvelle ClusterRole.

    Cette commande ClusterRole permet aux utilisateurs qui y sont ajoutés d'effectuer toute action sur toutes les ressources de la grappe.

    cat << EOF | tee cluster-admin-clusterrole.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-cr
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

    Où :

    • rules: - Définit les autorisations accordées à ClusterRole. Cet exemple ne comporte qu'une seule règle :
      • apiGroups: ["*"] - Spécifie que la règle s'applique à tous les groupes d'API.
      • resources: ["*"] - Spécifie que la règle s'applique à toutes les ressources des groupes d'API.
      • verbs: ["*"] - Spécifie que la règle accorde tous les verbes possibles sur les ressources, notamment get, list, create, delete, etc.

  2. Appliquez le fichier.

    kubectl apply -f cluster-admin-clusterrole.yaml

  3. Créez un ClusterRoleBinding pour lier ClusterRole à un nouvel utilisateur.

    ClusterRoleBinding est similaire à RoleBinding que vous avez créé précédemment, mais il a une portée de grappe.

    cat << EOF | tee cluster-admin-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-admin-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-crb
roleRef:
  name: cluster-admin-cr
  kind: ClusterRole
subjects:
- kind: ServiceAccount
  name: cluster-admin-user
  namespace: rbac-example
EOF

    Où :

    • subjects: - Définit les entités auxquelles accorder des autorisations dans ClusterRole. Dans cet exemple, il s'agit du compte de service cluster-admin-user.

  4. Appliquez le fichier.

    kubectl apply -f cluster-admin-user.yaml

Tester ClusterRoleBinding

  1. Testez le rôle de grappe en tentant d'accéder à une ressource dans un autre espace de noms. Par exemple, l'espace de noms par défaut.

    kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default

    Vous devriez voir yes comme sortie, indiquant que cluster-admin-user dispose d'un accès cluster-admin.

  2. Vérifiez que le nouveau fichier ClusterRole fonctionne comme prévu.

    kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
kube-flannel   kube-flannel-ds-ptwkz                          1/1     Running   0          6h58m
kube-flannel   kube-flannel-ds-wn2g6                          1/1     Running   0          6h58m
kube-system    coredns-7cbdbfd99c-7xqkl                       1/1     Running   0          6h59m
kube-system    coredns-7cbdbfd99c-k2ssb                       1/1     Running   0          6h59m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          6h59m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          6h59m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          6h59m
kube-system    kube-proxy-48rm5                               1/1     Running   0          6h59m
kube-system    kube-proxy-h4kd2                               1/1     Running   0          6h58m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          6h59m
ocne-system    ocne-catalog-577b7cd5f9-bnvtm                  1/1     Running   0          6h58m
ocne-system    ui-846bddd4b-lnrwm                             1/1     Running   0          6h58m
rbac-example   test-pod                                       1/1     Running   0          6h34m

    Cette sortie confirme que la nouvelle instance ClusterRole peut accéder à tous les espaces de noms définis dans la grappe.

Confirmer que l'utilisateur ClusterRole peut créer un nouveau déploiement

Testez ClusterRole pour voir si les utilisateurs affectés peuvent créer un nouveau déploiement. Essayez ensuite d'y accéder à l'aide de ClusterRole nouvellement créé.

  1. Créez un nouveau déploiement de test.

    cat << EOF | tee testpod2.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
  namespace: default
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 8080
EOF

    Notez que ce déploiement se déploie dans l'espace de noms 'default', et non dans l'espace de noms rbac-example utilisé précédemment.

  2. Appliquez le fichier.

    kubectl apply -f testpod2.yaml

  3. Vérifiez que le déploiement est terminé.

    kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

    Exemple de sortie :

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
default        test-pod2                                      1/1     Running   0          28s
kube-flannel   kube-flannel-ds-shgh7                          1/1     Running   0          38m
kube-flannel   kube-flannel-ds-zzrgh                          1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-jg6lz                       1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-wh5g4                       1/1     Running   0          38m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          38m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          38m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          38m
kube-system    kube-proxy-5qngx                               1/1     Running   0          38m
kube-system    kube-proxy-6fz2q                               1/1     Running   0          38m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          38m
ocne-system    ocne-catalog-577b7cd5f9-vz782                  1/1     Running   0          38m
ocne-system    ui-846bddd4b-bbhtj                             1/1     Running   0          38m
rbac-example   test-pod                                       1/1     Running   0          21m

    Confirmer que le nouveau ClusterRole autorise les nouveaux déploiements dans un autre espace de noms.

Étapes suivantes

Ce tutoriel explique comment configurer et utiliser le contrôle d'accès basé sur les rôles avec Kubernetes en créant des rôles pour gérer l'accès aux ressources Kubernetes. Pour ce faire, vous définissez des rôles et des liaisons pour contrôler les actions autorisées sur les ressources d'un espace de noms ou à l'échelle d'une grappe. De cette façon, le contrôle granulaire fourni par RBAC est essentiel pour sécuriser votre environnement Kubernetes, en particulier pour les déploiements volumineux. Consultez la station de formation Oracle Linux pour obtenir des tutoriels et du contenu supplémentaires.

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.