Uso del control de acceso basado en roles con Oracle Cloud Native Environment

Introducción

A medida que aumenta el número de despliegues en el cluster de Kubernetes, puede que necesite ayuda para gestionarlo. La API de Kubernetes proporciona la capacidad de agregar usuarios y definir sus permisos para el cluster.

Una vez que el usuario se ha autenticado, Kubernetes verifica las acciones que el usuario está autorizado a realizar. El control de acceso basado en roles (RBAC) está soportado de forma nativa por Kubernetes y activado por defecto en Oracle Cloud Native Environment (Oracle CNE). Convertirlo en uno de los métodos de control de acceso más utilizados. RBAC permite gestionar el acceso a los recursos desplegados en el entorno de Kubernetes mediante la aplicación de reglas que restringen el acceso de los usuarios a los recursos de cluster. Estas reglas se pueden restringir al espacio de nombres mediante un rol o a todo el cluster mediante un ClusterRole.

Le resultará útil conocer los componentes clave del control de acceso basado en roles (RBAC) en Kubernetes, que son:

Roles: conjunto definido de permisos que definen acciones permitidas dentro de un espacio de nombres.
RoleBindings: se utiliza para enlazar un rol a un usuario o cuenta de servicio dentro de un espacio de nombres.
ClusterRole: juego definido de permisos que definen acciones permitidas en todos los espacios de nombres del cluster.
ClusterRoleBindings: se utiliza para enlazar un ClusterRole a un usuario o cuentas de servicio en todos los espacios de nombres del cluster.
Asuntos: son usuarios, grupos o cuentas de servicio que están enlazados a roles o ClusterRoles.
Permisos: definen las acciones permitidas que un rol, o ClusterRole, puede realizar en un recurso especificado. Están asociados a roles y roles de cluster en lugar de a usuarios o cuentas de servicio.

Otra forma de gestionar el acceso al cluster de Kubernetes es el control de acceso basado en atributos (ABAC), que permite un ajuste más preciso de las políticas en comparación con el RBAC. Pero esto está fuera del alcance de este tutorial.

En este tutorial se tratan los conceptos básicos del uso de RBAC para gestionar el acceso al cluster de Kubernetes y se muestra un caso de uso sencillo.

Para obtener más información sobre Oracle Cloud Native Environment 2, consulte el sitio de documentación de la versión actual.

Objetivos

En este tutorial, aprenderá a:

Cree un rol para demostrar la restricción de permisos de usuario por espacio de nombres.
Cree un archivo ClusterRole para demostrar la concesión de permisos de usuario en todo el cluster.

Requisitos

Instalación de Oracle Cloud Native Environment (Oracle CNE)
Un único nodo de control y un nodo de trabajador

Configurar Oracle Cloud Native Environment

Nota: Si se ejecuta en su propio arrendamiento, lea el proyecto linux-virt-labs GitHub README.md y complete los requisitos antes de desplegar el entorno de prácticas.

Abra un terminal en el escritorio Luna.

Clone el proyecto linux-virt-labs GitHub.

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

Cambie al directorio de trabajo.
```
cd linux-virt-labs/ocne2
```

Instale las recopilaciones necesarias.

ansible-galaxy collection install -r requirements.yml

Despliegue el entorno de prácticas.
```
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'"
```
El entorno de prácticas libres necesita la variable adicional local_python_interpreter, que define ansible_python_interpreter para las reproducciones que se ejecutan en localhost. Esta variable es necesaria porque el entorno instala el paquete RPM para el SDK para Python de Oracle Cloud Infrastructure, que se encuentra en los módulos python3.6.

La unidad de despliegue por defecto utiliza la CPU AMD y Oracle Linux 8. Para utilizar una CPU Intel u Oracle Linux 9, agregue -e instance_shape="VM.Standard3.Flex" o -e os_version="9" al comando de despliegue.

Importante: Espere a que el cuaderno de estrategias se ejecute correctamente y alcance la tarea de pausa. En esta etapa del manual, se ha completado la instalación del CNE de Oracle y las instancias están listas. Tome nota de la reproducción anterior, que imprime las direcciones IP públicas y privadas de los nodos que despliega y cualquier otra información de despliegue necesaria al ejecutar el ejercicio práctico.

Acceso al cluster de Kubernetes

Abra un terminal y conéctese mediante SSH a la instancia de ocne.
```
ssh oracle@<ip_address_of_instance>
```
Espere a que el cluster se estabilice y a que todos los pods se informen en estado de ejecución.
```
watch kubectl get pods -A
```
Una vez que todos los pods muestren un STATUS de Running, escriba Ctrl-C para salir del comando watch.
Confirme cuántos nodos están presentes.
```
kubectl get nodes
```

Confirmación de la configuración actual de RBAC

RBAC gestiona los permisos para las acciones que realiza en los recursos desplegados en el cluster de Kubernetes. Comprobará que RBAC esté activado y revisará los roles por defecto del cluster.

Confirmar que RBAC está activado.

Si la API rbac.authorization.k8s.io está visible, significa que RBAC está configurado y se utiliza para controlar qué acciones pueden realizar los usuarios o las cuentas de servicio en los recursos del cluster.
```
kubectl api-versions | grep rbac
```
Salida de ejemplo:
```
[oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1
```

Mostrar los roles de cluster incorporados.

kubectl get clusterroles | grep admin

Salida de ejemplo:

[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

Los usuarios normales utilizan los roles admin y cluster-admin, mientras que la API de RBAC reserva los roles system: para los componentes internos.

Muestre los permisos para cluster-admin.
```
kubectl describe clusterrole cluster-admin
```
Salida de ejemplo:
```
[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
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]
```
Los asteriscos en las columnas Verbos y Recursos significan que el rol cluster-admin puede realizar cualquier acción. Una lista de alto nivel de las operaciones (verbos) disponibles para cada versión de Kubernetes está disponible en la visión general de API de esa versión. Por ejemplo, en Kubernetes v1.33.0. Para obtener una lista detallada de las operaciones válidas (Verbos) disponibles para cada tipo de Recurso, ejecute kubectl api-resources -o wide desde la línea de comandos.

Sin embargo, debido a que no se conecta a kubectl, ¿cómo sabe Kubernetes quién es el usuario que ejecuta el comando? Los sistemas de producción suelen utilizar un servidor LDAP para la autenticación. Se puede utilizar ServiceAccount si no hay un sistema de autenticación externo disponible.

Nota: Las cargas de trabajo automatizadas, como los pipelines de integración y despliegue continuos, utilizan ServiceAccounts, pero también se pueden utilizar para realizar pruebas.

Crear un rol

Un rol es un recurso restringido al espacio de nombres que define los permisos para acceder a los recursos de Kubernetes dentro de un único espacio de nombres.

Creación de un espacio de nombres y un rol

Crear un espacio de nombres.

Cree un nuevo espacio de nombres para este ejemplo.
```
kubectl create namespace rbac-example
```
Crear un rol.

Cree un rol que otorgue acceso de solo lectura ("permisos get" y "list") a pods y deployments dentro del espacio de nombres 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
```
Dónde:
- rules:: define los permisos otorgados al rol. En este ejemplo, se definen dos reglas (consulte a continuación).
- apiGroups: [""]: permite al usuario o a la cuenta de servicio enlazados a esta regla recuperar y mostrar pods en el espacio de nombres rbac-example.
- apiGroups: ["apps"]: permite al usuario o a la cuenta de servicio enlazados a esta regla recuperar y mostrar los despliegues en el espacio de nombres rbac-example.
Aplique el archivo.
```
kubectl apply -f pod-reader-role.yaml
```

Compruebe los permisos para el rol pod-reader recién creado.

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

Salida de ejemplo:

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

Creación de un usuario y enlace al rol

Cree un nuevo usuario ServiceAccount denominado pod-reader-user y enlácelo al rol 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
```
Dónde:
- ServiceAccount crea la cuenta de servicio.
  - name:: nombre del usuario de la cuenta de servicio (pod-reader-user).
  - namespace: espacio de nombres donde se crea (rbac-example).
- RoleBinding otorga los permisos relacionados con el espacio de nombres a la cuenta de servicio.
  - roleRef:: especifica el rol de enlace. En este ejemplo, hace referencia a un rol denominado pod-reader.
  - subjects:: especifica la entidad para otorgar permisos. En este ejemplo, una cuenta de servicio denominada pod-reader-user.
Aplique el archivo.
```
kubectl apply -f pod-reader-user.yaml
```

Pruebe RoleBinding

A continuación, pruebe RoleBinding mediante la creación de un nuevo pod y el acceso a él mediante la cuenta de servicio pod-reader-user recién creada.

Crear un nuevo despliegue de prueba.
```
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
```
Dónde:
- spec: define el estado deseado del pod.
  - containers:: especifica la lista de contenedores que se van a ejecutar en el pod. En este ejemplo, solo hay un contenedor.
    - name:: nombre del contenedor (test-container).
    - image:: imagen que se va a utilizar (ghcr.io/oracle/oraclelinux9-nginx:1.20).
    - ports:: especifica el puerto expuesto por el contenedor. En este ejemplo, es el puerto 80 (containerPort: 80).
  - serviceAccountName:: especifica la cuenta de servicio que se utilizará para el pod. En esta configuración, el pod utiliza los permisos y las credenciales asignados a la cuenta de servicio pod-reader-user.
Aplique el archivo.
```
kubectl apply -f testpod.yaml
```
Ahora, intente acceder al pod mediante el pod-reader-user ServiceAccount.
```
kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
```
Debe ver yes como la salida, lo que indica que pod-reader-user tiene permiso para acceder al pod.

Nota: Utilice la funcionalidad kubectl auth can-i para ejecutar comandos como la cuenta de usuario ServiceAccount recién creada para verificar que se permite una acción.

Confirme que ServiceAccount funciona como se esperaba.

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

Salida de ejemplo:

[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

Intente suprimir un pod mediante el rol pod-reader-user.

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

Salida de ejemplo:

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

El rol pod-reader-user no puede suprimir pods en rbac-example. ¿Pueden empezar nuevos pods?

Intente ejecutar un pod con el rol pod-reader-role.

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

Salida de ejemplo:

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

Este error es correcto porque el rol pod-reader-user solo puede realizar acciones get y list en recursos de pod en el espacio de nombres rbac-example del cluster. Cualquier otra acción, delete o create, no está permitida.

Crear un ClusterRole

ClusterRoles son similares a los roles, pero definen los permisos permitidos en los recursos de todo el cluster.

Nota: Tenga cuidado al otorgar permisos demasiado amplios. En su lugar, utilice el principio de privilegio mínimo para otorgar a los usuarios y las cuentas de servicio solo los permisos necesarios para completar las tareas asignadas.

Cree ClusterRole y ClusterRoleBinding

En el ejemplo anterior se mostraba cómo crear un rol y un usuario específicos del espacio de nombres. En los siguientes pasos se muestra cómo crear un archivo ClusterRole y enlazarlo a un usuario para otorgarles acceso de administrador a todo el cluster.

Cree un nuevo ClusterRole.

Esta opción ClusterRole permite a los usuarios agregados realizar cualquier acción en todos los recursos del 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
```
Dónde:
- rules:: define los permisos otorgados a ClusterRole. Este ejemplo solo tiene una regla:
  - apiGroups: ["*"]: especifica que la regla se aplica a todos los grupos de API.
  - resources: ["*"]: especifica que la regla se aplica a todos los recursos de los grupos de API.
  - verbs: ["*"]: especifica que la regla otorga todos los verbos posibles en los recursos, incluidos get, list, create, delete, etc.

Aplique el archivo.

kubectl apply -f cluster-admin-clusterrole.yaml

Cree un ClusterRoleBinding para enlazar el ClusterRole a un nuevo usuario.

ClusterRoleBinding es similar al RoleBinding que ha creado anteriormente, pero tiene un ámbito de 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

Dónde:

subjects:: define las entidades para otorgar permisos en ClusterRole. En este ejemplo, es la cuenta de servicio cluster-admin-user.

Aplique el archivo.

kubectl apply -f cluster-admin-user.yaml

Pruebe ClusterRoleBinding

Pruebe el rol de cluster intentando acceder a un recurso en un espacio de nombres diferente. Por ejemplo, el espacio de nombres default.
```
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default
```
Debe ver yes como la salida, lo que indica que cluster-admin-user tiene acceso de cluster-admin.

Confirme que ClusterRole recién creado funciona como se esperaba.

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

Salida de ejemplo:

[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

Esta salida confirma que el ClusterRole recién creado puede acceder a todos los espacios de nombres definidos en el cluster.

Confirme que el usuario ClusterRole puede crear un nuevo despliegue

Pruebe ClusterRole para ver si permite a los usuarios asignados crear un nuevo despliegue. A continuación, intente acceder a él mediante el ClusterRole recién creado.

Crear un nuevo despliegue de prueba.

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

Tenga en cuenta que este despliegue se despliega en el espacio de nombres 'default' y no en el espacio de nombres rbac-example utilizado anteriormente.

Aplique el archivo.
```
kubectl apply -f testpod2.yaml
```

Confirme que el despliegue se ha realizado correctamente.

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

Salida de ejemplo:

[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

Confirmando que el nuevo ClusterRole permite nuevos despliegues en un espacio de nombres diferente.

Pasos Siguientes

En este tutorial se ha demostrado cómo configurar y utilizar el control de acceso basado en roles (RBAC) con Kubernetes mediante la creación de roles para gestionar el acceso a los recursos de Kubernetes. Para ello, ha definido roles y enlaces para controlar qué acciones permitidas se permitían en los recursos dentro de un espacio de nombres o en todo el cluster. De esta forma, el control granular que proporciona RBAC es esencial para proteger su entorno de Kubernetes, especialmente para grandes despliegues. Consulte la estación de formación de Oracle Linux para obtener tutoriales y contenido adicionales.

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Use Role-Based Access Control with Oracle Cloud Native Environment

G40836-01

Oracle y/o sus filiales.

Uso del control de acceso basado en roles con Oracle Cloud Native Environment

Introducción

Objetivos

Requisitos

Configurar Oracle Cloud Native Environment

Acceso al cluster de Kubernetes

Confirmación de la configuración actual de RBAC

Crear un rol

Creación de un espacio de nombres y un rol

Creación de un usuario y enlace al rol

Pruebe RoleBinding

Crear un ClusterRole

Cree ClusterRole y ClusterRoleBinding

Pruebe ClusterRoleBinding

Confirme que el usuario ClusterRole puede crear un nuevo despliegue

Pasos Siguientes

Enlaces relacionados

Más recursos de aprendizaje