¿Cuáles son los tipos de roles RBAC?

• El ámbito de un rol de Kubernetes se limita a los recursos de un determinado espacio de nombres, como un despliegue o un servicio.
• El ámbito de un rol de clúster de Kubernetes se limita a los recursos a nivel de clúster como, por ejemplo, nodos de trabajador, o bien a los recursos del espacio de nombres que pueden encontrarse en cada espacio de nombres como, por ejemplo, pods.

¿Qué son las vinculaciones de funciones RBAC y las vinculaciones de funciones de clúster?

Los enlaces de rol aplican los roles RBAC o los roles de clúster a un espacio de nombres específico. Cuando utiliza un enlace de rol para aplicar un rol, asigna a un usuario acceso a un recurso específico en un espacio de nombres específico. Cuando utiliza un enlace de rol para aplicar un rol de clúster, asigna a un usuario acceso a los recursos del ámbito de un espacio de nombres que se encuentran en cada espacio de nombres, como pods, pero solo dentro de un espacio de nombres específico.

Los enlaces de rol de clúster aplican roles de clúster RBAC a todos los espacios de nombres del clúster. Cuando utiliza un enlace de rol de clúster para aplicar un rol de clúster, da a un usuario acceso a los recursos del clúster, como nodos trabajadores, o a los recursos del ámbito del espacio de nombres en cada espacio de nombres, como pods.

¿Cómo son estas funciones en mi cluster?

Si desea que los usuarios puedan interactuar con recursos de Kubernetes desde dentro de un clúster, debe asignar acceso de usuario a uno o más espacios de nombres mediante los roles de acceso al servicio de IBM Cloud IAM. A cada usuario que tenga asignado un rol de acceso al servicio se le asigna automáticamente un rol de clúster de RBAC correspondiente. Estos roles de clúster RBAC están predefinidos y permiten a los usuarios interactuar con los recursos de Kubernetes del clúster. Además, se crea un enlace de rol para aplicar el rol de clúster a un espacio de nombres específico, o se crea un enlace de rol de clúster para aplicar el rol de clúster a todos los espacios de nombres.

Para obtener más información sobre las acciones permitidas por cada función RBAC, consulte el tema de referencia sobre las funciones de acceso a servicios de IAM en IBM Cloud. Para ver los permisos que otorga cada rol de RBAC a recursos de Kubernetes individuales, consulte Permisos de recursos de Kubernetes por rol de RBAC.

¿Puedo crear funciones personalizadas o funciones de clúster?

Si está creando sus propias políticas RBAC personalizadas, asegúrese de que no edita los enlaces de rol de IBM existentes que están en el clúster, o cree enlaces de rol personalizados con el mismo nombre que los enlaces de IBM existentes. Los cambios que realice en los enlaces de rol RBAC proporcionados por IBMno se conservan en las actualizaciones.

Los roles de clúster view, edit, admin y cluster-admin son roles predefinidos que se crean automáticamente cuando asigna a un usuario el correspondiente rol de acceso al servicio de IBM Cloud IAM. Para otorgar otros permisos de Kubernetes, puede crear permisos RBAC personalizados. Los roles de RBAC personalizados se añaden a los roles de RBAC que haya asignado con roles de acceso de servicio, y no los cambian ni los alteran temporalmente. Tenga en cuenta que, para crear permisos de RBAC personalizados, debe tener el rol de acceso al servicio de IAM de Gestor que le proporciona el rol de RBAC de cluster-admin de Kubernetes. Sin embargo, los demás usuarios no necesitan un rol de acceso de servicio de IAM si gestiona sus propios roles de RBAC personalizados de Kubernetes.

¿Cuándo necesito utilizar enlaces de rol de clúster personalizados y enlaces de rol?

Es posible que desee autorizar quién puede crear y actualizar los pods en el clúster. Mediante las restricciones de contexto de seguridad (SCC), puede utilizar enlaces de rol de clúster existentes que vienen con el clúster o puede crear los suyos propios.

Es posible que también desee integrar complementos en el clúster. Por ejemplo, cuando configure Helm en el clúster

Creación de permisos RBAC personalizados para usuarios, grupos o cuentas de servicio

Los roles de clúster view, edit, admin y cluster-admin se crean automáticamente cuando asigna el correspondiente rol de acceso al servicio de IBM Cloud IAM. ¿Necesita que las políticas de acceso de clúster sean más granulares de lo que permiten estos permisos predefinidos? No hay ningún problema. Puede crear roles de clúster y roles RBAC personalizados.

Puede asignar roles RBAC y roles de clúster personalizados a usuarios individuales, grupos de usuarios o cuentas de servicio. Cuando se crea un enlace para un grupo, este afecta a cualquier usuario que se añada o se elimine de dicho grupo. Cuando añade usuarios a un grupo, reciben los derechos de acceso del grupo además de los derechos de acceso individuales que les otorgue. Si se elimina, su acceso se revoca. Tenga en cuenta que no se pueden añadir cuentas de servicio a grupos de acceso.

Si desea asignar acceso a un proceso de contenedor que se ejecuta en pods, como una cadena de herramientas de entrega continua, puede utilizar Kubernetes ServiceAccounts. Para seguir un tutorial que demuestra cómo configurar cuentas de servicio para Travis y Jenkins y asignar funciones RBAC personalizadas a las cuentas de servicio, consulte la entrada del blog Kubernetes ServiceAccounts para su uso en sistemas automatizados.

Para evitar cambios de última hora, no cambie los roles de clúster predefinidos de view, edit, admin y cluster-admin. Los roles RBAC personalizados se añaden a los roles RBAC que haya asignado con roles de acceso de servicio de IBM Cloud IAM, y no los cambian ni los alteran temporalmente.

• Acceso a espacios de nombres: Para permitir que un usuario, un grupo de acceso o una cuenta de servicio acceda a un recurso dentro de un espacio de nombres específico, elija una de las combinaciones siguientes:

  • Cree un rol y aplíquelo con un enlace de rol. Esta opción resulta útil para controlar el acceso a un recurso exclusivo que solo existe en un espacio de nombres, como un despliegue de app.
  • Cree un rol de clúster y aplíquelo con un enlace de rol. Esta opción resulta útil para controlar el acceso a recursos generales de un espacio de nombres, como pods.

• Acceso a clúster: Para permitir que un usuario o un grupo de acceso acceda a los recursos de todo el clúster o a los recursos de clúster de todos los espacios de nombres, cree un rol de clúster y aplíquelo con un enlace de rol de clúster. Esta opción resulta útil para controlar el acceso a recursos que no se circunscriben a espacios de nombres, como nodos trabajadores, o a recursos de todos los espacios de nombres de su clúster, como los pods de cada espacio de nombres.

• Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

• Asegúrese de que dispone de la función de acceso al servicio Manager IAM para todos los espacios de nombres.

• Para asignar acceso a usuarios individuales o a usuarios de un grupo de acceso, asegúrese de que al usuario o grupo se le ha asignado al menos una función de acceso a la plataforma IAM en el nivel de servicio Red Hat OpenShift on IBM Cloud.

Para crear permisos RBAC personalizados,

1. Cree un archivo .yaml similar al siguiente para definir role o 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"]
   

   Comprender los parámetros YAML

   Parámetro	Descripción
   kind	Utilice Role para otorgar acceso a los recursos dentro de un espacio de nombres específico. Utilice ClusterRole para otorgar acceso a los recursos de todo el clúster, como nodos trabajadores, o a recursos del ámbito del espacio de nombres, como pods de todos los espacios de nombres.
   metadata.namespace	Solo para el tipo Role: especifique el espacio de nombres de Kubernetes al que se otorga acceso.
   rules.apiGroups	Especifique los grupos de la API Kubernetes con los que desea que los usuarios puedan interactuar, como "apps", "batch" o "extensions". Para acceder al grupo de API principal en la vía de acceso de REST api/v1, deje el grupo en blanco: [""].
   rules.resources	Especifique los tipos de recursos de Kubernetes a los que desea conceder acceso, como "daemonsets", "deployments", "events" o "ingresses". Si especifica "nodes", entonces el tipo debe ser ClusterRole.
   rules.verbs	Especifique los tipos de acciones que desea que los usuarios puedan realizar, como "get", "list", "describe", "create" o "delete".

2. Cree el rol o rol de clúster en el clúster.

   oc apply -f my_role.yaml
   

3. Verifique que se ha creado el rol o rol de clúster.

   • Rol:

     oc get roles -n <namespace>
     

   • Rol de clúster:

     oc get clusterroles
     

4. Enlace usuarios al rol o rol de clúster creando un archivo .yaml. Anote el URL exclusivo que se debe utilizar para el nombre de cada sujeto.

   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
   

   Comprender los parámetros YAML

   Parámetro	Descripción
   kind	Especifique RoleBinding para un Role o ClusterRole específico de espacio de nombres. Especifique ClusterRoleBinding para un ClusterRole de todo el clúster.
   apiVersion	Para clústeres que ejecutan Kubernetes 1.8 o posterior, utilice rbac.authorization.k8s.io/v1. Para versiones anteriores, utilice apiVersion: rbac.authorization.k8s.io/v1beta1.
   metadata.namespace	Para el tipo RoleBinding: especifique el espacio de nombres de Kubernetes al que se otorga el acceso. Para el tipo ClusterRoleBinding: no utilice el campo namespace.
   metadata.name	Nombre el enlace de rol o del enlace de rol de clúster.
   subjects.kind	Especifique el tipo como una de las opciones siguientes: User: enlace el rol de RBAC o de clúster con un usuario individual de la cuenta. Group: enlace el rol de RBAC o el rol de clúster con un Grupo de acceso de IBM Cloud IAM en su cuenta. ServiceAccount: enlace el rol de RBAC o el rol de clúster con una cuenta de servicio en un espacio de nombres del clúster.
   subjects.name	Para User: añada la dirección de correo electrónico del usuario individual a IAM# de la siguiente manera: IAM#user@email.com. Para Group: especifique el nombre del grupo de acceso de IBM Cloud IAM en su cuenta. Para ServiceAccount: especifique el nombre de la cuenta de servicio.
   subjects.apiGroup	Para User o Group: utilice rbac.authorization.k8s.io. Para ServiceAccount: no incluya este campo.
   subjects.namespace	Solo para ServiceAccount: especifique el nombre del espacio de nombres de Kubernetes en el que se despliega la cuenta de servicio.
   roleRef.kind	Especifique el mismo valor que el de kind en el archivo .yaml de roles: Role o ClusterRole.
   roleRef.name	Especifique el nombre del archivo .yaml de roles.
   roleRef.apiGroup	Utilice rbac.authorization.k8s.io.

5. Cree el recurso de enlace de rol o de enlace de rol de clúster en el clúster.

   oc apply -f my_role_binding.yaml
   

6. Verifique que se ha creado el enlace.

   oc get rolebinding -n <namespace>
   

7. Opcional: Para imponer el mismo nivel de acceso de usuario en otros espacios de nombres, puede copiar los enlaces de rol para dichos roles o roles de clúster en otros espacios de nombres.

   1. Copie el enlace de rol de un espacio de nombres a otro espacio de nombres.

      oc get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | oc -n <namespace_2> create -f -
      

      Por ejemplo, copie la vinculación de rol custom-role del espacio de nombres default al espacio de nombres testns.

      oc get rolebinding custom-role -o yaml | sed 's/default/testns/g' | oc -n testns create -f -
      

   2. Verifique que se copia el enlace de rol. Si ha añadido un grupo de acceso de IBM Cloud IAM al enlace de rol, cada usuario de dicho grupo se añade individualmente, no como un ID de grupo de acceso.

      oc get rolebinding -n <namespace_2>
      

Ahora que ha creado y enlazado un rol de RBAC o un rol de clúster de Kubernetes personalizado, siga con los usuarios. Pídales que prueben una acción que tengan permiso para realizar debido al rol, como suprimir un pod.

Ampliación de los permisos existentes mediante la agregación de roles de clúster

Puede ampliar los permisos existentes de los usuarios agregando roles de clúster o combinando roles de clúster con otros roles de clúster. Cuando asigna a un usuario un rol de acceso al servicio de IBM Cloud, el usuario se añade a un rol de clúster RBAC de Kubernetes correspondiente. Sin embargo, es posible que desee permitir a determinados usuarios realizar operaciones adicionales.

Por ejemplo, un usuario con el rol de clúster admin con ámbito de espacio de nombres no puede utilizar el mandato oc top pods para ver las métricas de pod de todos los pods del espacio de nombres. Puede agregar un rol de clúster para que los usuarios con el rol de clúster admin tengan autorización para ejecutar el mandato top pods. Para más información, consulte la documentación de Kubernetes.

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"

Comprobación de los roles de RBAC

Verifique el acceso al servicio de IAM sincronizado o RBAC personalizado a los roles de RBAC en el clúster de Red Hat OpenShift on IBM Cloud.

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

Roles de acceso al servicio de Kubernetes y roles RBAC correspondientes

En la tabla siguiente se muestran los permisos de recursos de Kubernetes que asigna cada rol de acceso al servicio y su rol de RBAC correspondiente.