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

Introduction

Au fur et à mesure que le nombre de déploiements vers votre cluster Kubernetes augmente, vous aurez peut-être besoin d'aide pour la gérer. L'API Kubernetes permet d'ajouter des utilisateurs et de définir leurs droits d'accès au cluster.

Une fois l'utilisateur authentifié, Kubernetes vérifie les actions qu'il est autorisé à effectuer. Le contrôle d'accès basé sur les rôles (RBAC) est pris en charge nativement par Kubernetes et activé par défaut dans Oracle Cloud Native Environment (Oracle CNE). Il s'agit de l'une des méthodes de contrôle d'accès couramment utilisées. Le contrôle d'accès basé sur les rôles 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 cluster. Ces règles peuvent être restreintes à l'espace de noms à l'aide d'un rôle ou à l'échelle du cluster à l'aide d'un fichier ClusterRole.

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

Rôles : ensemble défini de droits d'accès qui définissent les actions autorisées dans un espace de noms.
RoleBindings : permet de lier un rôle à un utilisateur ou à un compte de service dans un espace de noms.
ClusterRole : ensemble défini de droits d'accès définissant les actions autorisées dans tous les espaces de noms du cluster.
ClusterRoleBindings : permet de lier un élément ClusterRole à des comptes utilisateur ou de service dans tous les espaces de noms du cluster.
Objets : utilisateurs, groupes ou comptes de service liés à des rôles ou à ClusterRoles.
Droits d'accès : ceux-ci définissent les actions autorisées qu'un rôle, ou ClusterRole, peut effectuer sur une ressource spécifiée. Ils sont associés à des rôles et des rôles de cluster plutôt qu'à des utilisateurs ou des comptes de service.

Un autre moyen de gérer l'accès au cluster Kubernetes est le contrôle d'accès basé sur les attributs (ABAC), qui permet un réglage plus fin des stratégies par rapport au contrôle d'accès basé sur les attributs. Mais cela n'entre pas dans le cadre de ce tutoriel.

Ce tutoriel présente les principes de base de l'utilisation du contrôle d'accès basé sur les rôles pour gérer l'accès à votre cluster Kubernetes et présente un cas d'utilisation simple.

Pour plus d'informations sur Oracle Cloud Native Environment 2, reportez-vous au site actuel de la documentation sur les versions.

Objectifs

Dans ce tutoriel, vous allez apprendre à :

Créez un rôle pour démontrer la restriction des droits d'accès utilisateur par espace de noms.
Créez un élément ClusterRole pour démontrer l'octroi de droits d'accès utilisateur à l'échelle du cluster.

Prérequis

Installation d'Oracle Cloud Native Environment (Oracle CNE)
Un noeud de contrôle unique et un noeud de processus actif

Configuration d'Oracle Cloud Native Environment

Remarque : si vous êtes en cours d'exécution dans votre propre location, lisez le projet linux-virt-labs GitHub README.md et complétez les prérequis avant de déployer l'environnement d'exercice.

Ouvrez un terminal sur le bureau Luna.

Clonez le projet linux-virt-labs GitHub.

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

Accédez au répertoire de travail.
```
cd linux-virt-labs/ocne2
```

Installez les ensembles requis.

ansible-galaxy collection install -r requirements.yml

Déployez l'environnement d'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 d'exercice libre requiert 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 le package RPM pour le kit SDK Oracle Cloud Infrastructure pour Python, situé sous les modules python3.6.

La forme de déploiement par défaut utilise l'UC AMD et Oracle Linux 8. Pour utiliser une CPU 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 guide de lecture s'exécute correctement et atteignez la tâche de pause. A ce stade du manuel, l'installation du CNE Oracle est terminée et les instances sont prêtes. Prenez note de la lecture précédente, qui affiche les adresses IP publiques et privées des noeuds qu'elle déploie et toutes les autres informations de déploiement nécessaires lors de l'exécution de l'exercice.

Accéder au cluster Kubernetes

Ouvrez un terminal et connectez-vous via SSH à l'instance ocne.
```
ssh oracle@<ip_address_of_instance>
```
Attendez que le cluster se stabilise et que tous les pods présentent un état d'exécution.
```
watch kubectl get pods -A
```
Une fois que tous les pods affichent le STATUS de Running, saisissez Ctrl-C pour quitter la commande watch.
Vérifiez le nombre de noeuds présents.
```
kubectl get nodes
```

Confirmer la configuration RBAC actuelle

Le contrôle d'accès basé sur les rôles gère les droits d'accès pour les actions que vous effectuez sur les ressources déployées sur le cluster Kubernetes. Vérifiez que RBAC est activé et vérifiez les rôles par défaut dans votre cluster.

Vérifiez que 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 entreprendre sur les ressources de cluster.
```
kubectl api-versions | grep rbac
```
Exemple de résultat :
```
[oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1
```

Affichez les rôles de cluster intégrés.

kubectl get clusterroles | grep admin

Exemple de résultat :

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

Répertoriez les droits d'accès pour cluster-admin.
```
kubectl describe clusterrole cluster-admin
```
Exemple de résultat :
```
[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 dans les colonnes Verbes et Ressources signifient que le rôle cluster-admin peut effectuer n'importe quelle action. Une liste générale des opérations (verbes) disponibles pour chaque version de Kubernetes est disponible dans l'aperçu d'API de 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, étant donné que 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 aucun système d'authentification externe n'est disponible.

Remarque : ServiceAccounts est utilisé par les charges globales automatisées, telles que les pipelines CI/CD, mais peut également être utilisé pour les tests.

Créer un rôle

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

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

Création d'un espace de noms

Créez un espace de noms pour cet exemple.
```
kubectl create namespace rbac-example
```
Créez un rôle.

Créez un rôle qui accorde un accès en lecture seule (autorisations "get" et "list") aux pods et aux déploiements dans l'espace de noms rbac-example.
```
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 droits d'accès accordés 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 répertorier 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 répertorier les déploiements dans l'espace de noms rbac-example.
Appliquez le fichier.
```
kubectl apply -f pod-reader-role.yaml
```

Vérifiez les autorisations pour le rôle pod-reader que vous venez de créer.

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

Exemple de résultat :

[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éation d'un utilisateur et liaison au rôle

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 dans lequel il est créé (rbac-example).
- RoleBinding accorde les droits d'accès liés à l'espace de noms au compte de service.
  - roleRef: : indique le rôle de liaison. Dans cet exemple, il référence un rôle appelé pod-reader.
  - subjects: : indique l'entité à laquelle accorder des droits d'accès. Dans cet exemple, un compte de service nommé pod-reader-user.
Appliquez le fichier.
```
kubectl apply -f pod-reader-user.yaml
```

Testez RoleBinding.

Testez ensuite RoleBinding en créant un pod et en y accédant à l'aide du compte de service pod-reader-user que vous venez de créer.

Créez un 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: : indique la liste des conteneurs à exécuter dans le pod. Dans cet exemple, il n'existe qu'un seul conteneur.
    - name: : nom du conteneur (test-container).
    - image: : image à utiliser (ghcr.io/oracle/oraclelinux9-nginx:1.20).
    - ports: : indique le port exposé par le conteneur. Dans cet exemple, il s'agit du port 80 (containerPort: 80).
  - serviceAccountName: : indique le compte de service à utiliser pour le pod. Dans cette configuration, le pod utilise les autorisations et les informations d'identification affectées au compte de service pod-reader-user.
Appliquez le fichier.
```
kubectl apply -f testpod.yaml
```
Essayez à présent d'accéder au pod à l'aide du fichier 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.

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

Vérifiez que ServiceAccount fonctionne comme prévu.

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

Exemple de résultat :

[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

Essayez de supprimer un pod en utilisant le rôle pod-reader-user.

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

Exemple de résultat :

[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 de pods dans rbac-example. Peut-être peuvent-ils commencer de nouveaux pods ?

Essayez d'exécuter un pod avec le 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 résultat :

[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 est uniquement autorisé à effectuer des actions get et list sur les ressources de pod dans l'espace de noms rbac-example du cluster. Les autres actions, supprimer ou créer, ne sont pas autorisées.

Créer une ClusterRole

ClusterRoles est similaire aux rôles, mais ils définissent les droits d'accès autorisés sur les ressources dans l'ensemble du cluster.

Remarque : soyez prudent lorsque vous accordez des droits d'accès trop larges. Utilisez plutôt le 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éez ClusterRole et ClusterRoleBinding.

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

Créez un élément ClusterRole.

Ce fichier ClusterRole permet aux utilisateurs qui y sont ajoutés d'effectuer toute action sur toutes les ressources du cluster.
```
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 droits d'accès accordés à ClusterRole. Cet exemple ne comporte qu'une seule règle :
  - apiGroups: ["*"] : indique que la règle s'applique à tous les groupes d'API.
  - resources: ["*"] : indique que la règle s'applique à toutes les ressources des groupes d'API.
  - verbs: ["*"] : indique que la règle accorde tous les verbes possibles sur les ressources, y compris get, list, create, delete, etc.

Appliquez le fichier.

kubectl apply -f cluster-admin-clusterrole.yaml

Créez un élément ClusterRoleBinding pour lier l'élément ClusterRole à un nouvel utilisateur.

L'élément ClusterRoleBinding est similaire à l'élément RoleBinding que vous avez créé précédemment, mais il est de portée cluster.

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 droits d'accès dans ClusterRole. Dans cet exemple, il s'agit du compte de service cluster-admin-user.

Appliquez le fichier.

kubectl apply -f cluster-admin-user.yaml

Testez ClusterRoleBinding.

Testez le rôle de cluster en essayant d'accéder à une ressource dans un autre espace de noms. Par exemple, l'espace de noms default.
```
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default
```
Vous devez voir yes comme sortie, indiquant que cluster-admin-user dispose d'un accès cluster-admin.

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 résultat :

[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 le nouveau fichier ClusterRole peut accéder à tous les espaces de noms définis sur le cluster.

Vérifiez que l'utilisateur ClusterRole peut créer un déploiement

Testez ClusterRole pour voir s'il permet aux utilisateurs affectés de créer un déploiement. Ensuite, essayez d'y accéder à l'aide de l'élément ClusterRole nouvellement créé.

Créez un 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.

Appliquez le fichier.
```
kubectl apply -f testpod2.yaml
```

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

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

Exemple de résultat :

[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

Confirmation que le nouveau fichier ClusterRole autorise les nouveaux déploiements vers un autre espace de noms.

Etapes suivantes

Ce tutoriel a expliqué comment configurer et utiliser le contrôle d'accès basé sur les rôles (RBAC) 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 afin de contrôler les actions autorisées sur les ressources d'un espace de noms ou à l'échelle du cluster. De cette façon, le contrôle d'accès basé sur les rôles (RBAC) est essentiel pour sécuriser votre environnement Kubernetes, en particulier pour les déploiements volumineux. Consultez le module de formation Oracle Linux pour obtenir des tutoriels et du contenu supplémentaires.

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

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

Informations relatives au titre et au copyright

Use Role-Based Access Control with Oracle Cloud Native Environment

G40841-01

Oracle et/ou ses affiliés.

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

Introduction

Objectifs

Prérequis

Configuration d'Oracle Cloud Native Environment

Accéder au cluster Kubernetes

Confirmer la configuration RBAC actuelle

Créer un rôle

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

Création d'un utilisateur et liaison au rôle

Testez RoleBinding.

Créer une ClusterRole

Créez ClusterRole et ClusterRoleBinding.

Testez ClusterRoleBinding.

Vérifiez que l'utilisateur ClusterRole peut créer un déploiement

Etapes suivantes

Liens connexes

Ressources de formation supplémentaires