El control de acceso basado en roles (RBAC) es un mecanismo para definir las acciones que las cuentas de usuario pueden realizar dentro de su clúster de Kubernetes. Habilitar RBAC reduce el riesgo asociado con el robo de credenciales y la apropiación de cuentas. Otorgar a cada usuario el conjunto mínimo de permisos que necesita evita que las cuentas adquieran privilegios excesivos.
Las distribuciones de Kubernetes más populares comienzan con una sola cuenta de usuario a la que se le otorga acceso de superusuario al clúster. Autenticarse como esta cuenta le permite realizar cualquier acción, pero puede representar un riesgo de seguridad sustancial.
En este artículo, le mostraremos cómo habilitar y configurar la API de RBAC de Kubernetes para que pueda definir con precisión las capacidades del usuario. es común que algunos usuarios solo creen y enumeren Pods, mientras que los administradores también pueden eliminar elementos. Puede configurar y aplicar estas políticas mediante el sistema RBAC.
Habilitación de RBAC en Kubernetes
RBAC es una función opcional de Kubernetes, pero la mayoría de las principales distribuciones se entregan con ella activada de forma predeterminada, incluidas las de proveedores de nube gestionada. Puede verificar si RBAC está disponible en su clúster ejecutando el siguiente comando con Kubectl:
$ kubectl api-versions | grep rbac.authorization.k8s rbac.authorization.k8s.io/v1
El comando debe emitir rbac.authorization.k8s.io/v1 como su salida si RBAC está habilitado. RBAC se apaga si el comando no produce ningún resultado. Puedes activarlo por iniciando el servidor API de Kubernetes con el --authorization-mode=RBAC bandera:
$ kube-apiserver --authorization-mode=RBAC
Consulte la documentación de su distribución de Kubernetes si no está seguro de cómo personalizar los argumentos de inicio del servidor API.
Objetos RBAC de Kubernetes
La implementación de Kubernetes RBAC gira en torno a cuatro tipos de objetos diferentes. Puede administrar estos objetos con Kubectl, de manera similar a otros recursos de Kubernetes como Pods, Deployments y ConfigMaps.
- Role – Un rol es un conjunto de reglas de control de acceso que definen acciones que los usuarios pueden realizar.
- Enlace de roles – Un “enlace” es un vínculo entre un rol y uno o más sujetos, que pueden ser usuarios o cuentas de servicio. El enlace permite a los sujetos realizar cualquiera de las acciones incluidas en el rol objetivo.
Roles y RoleBindings son objetos con espacio de nombres. Deben existir dentro de un espacio de nombres particular y controlan el acceso a otros objetos dentro de él. RBAC se aplica a los recursos de nivel de clúster, como los propios nodos y espacios de nombres, utilizando ClusterRoles y ClusterRoleBindings. Estos funcionan de manera similar a Roles y RoleBindings, pero se dirigen a objetos sin espacio de nombres.
Creación de una cuenta de servicio
Un Kubernetes cuenta de servicio es un tipo de usuario administrado por la API de Kubernetes. Cada cuenta de servicio tiene un token único que se usa como sus credenciales. Tú no puedo agregar usuarios normales a través de la API de Kubernetes, por lo que usaremos una cuenta de servicio para este tutorial.
Use Kubectl para crear una nueva cuenta de servicio:
$ kubectl create serviceaccount demo
Esto produce una nueva cuenta llamada demo. A continuación, debe recuperar el token que utilizará para autenticarse como esta cuenta. Primero busque el nombre del secreto que almacena el token:
$ kubectl describe serviceaccount demo Name: demo Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: demo-token-w543b Tokens: demo-token-w543b Events: <none>
El token de esta cuenta de servicio se almacena en el secreto llamado demo-token-w543b. Puede recuperar el token obteniendo el valor del secreto con este comando:
$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk '{print $2}')
El token ahora está almacenado en el TOKEN variable en su shell. Puede usar esta variable para agregar un nuevo contexto de Kubectl que le permitirá autenticarse como su cuenta de servicio:
$ kubectl config set-credentials demo --token=$TOKEN User "demo" set. $ kubectl config set-context demo --cluster=default --user=demo Context "demo" created.
Debes cambiar el valor de --cluster marca para que coincida con el nombre de su conexión de clúster de Kubectl activa. esto suele ser default o el nombre de su contexto actualmente seleccionado. Puede verificar el contexto seleccionado ejecutando kubectl config current-context.
Cambie a su nuevo contexto para autenticarse como su demo cuenta de servicio Anote primero el nombre de su contexto seleccionado actualmente, para que pueda volver a su cuenta de superusuario más adelante.
$ kubectl config current-context default $ kubectl config use-context demo Switched to context "demo".
Los comandos de Kubectl ahora se autenticarán como el demo cuenta de servicio Intente recuperar la lista de Pods en su clúster:
$ kubectl get pods Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"
La operación ha sido prohibida porque el demo la cuenta de servicio carece de un rol que le permita acceder a los Pods.
Agregar un rol
Los roles se crean de la misma manera que cualquier otro objeto de Kubernetes. Escribe un archivo YAML que define el rol y los permisos que proporciona. Cada función contiene una o más reglas que permiten realizar acciones específicas en un conjunto de recursos. Aquí hay un rol simple que le permite a un usuario recuperar detalles de Pods existentes:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]
los get y list verbos aplicados a la pods recurso significa que podrá ejecutar comandos como get pod y describe pod. Se prohibirá intentar crear un nuevo Pod o eliminar uno existente porque el create y delete los verbos se omiten del rol.
Vuelva a su contexto Kubectl original para que pueda agregar el rol a su clúster usando su cuenta administrativa:
$ kubectl config use-context default Switched to context "default".
Ahora agregue el rol:
$ kubectl apply -f role.yaml role.rbac.authorization.k8s.io/demo-role created
Vinculación de roles a usuarios y cuentas de servicio
Ahora puede asociar su rol con su demo cuenta de servicio creando un nuevo RoleBinding. Cree el siguiente archivo YAML para definir su enlace:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: demo-role-binding subjects: - kind: ServiceAccount name: demo apiGroup: "" roleRef: kind: Role name: demo-role apiGroup: ""
RoleBindings debe incluir uno o más sujetos que identifiquen a los usuarios y las cuentas de servicio a los que se dirige el enlace. los roleRef El campo hace referencia al rol que desea asignar a cada uno de esos usuarios.
Role y RoleBinding deben existir en el mismo espacio de nombres. Utilice un ClusterRole y un ClusterRoleBinding en su lugar para los recursos sin espacio de nombres.
siguiente carrera kubectl apply para agregar RoleBinding a su clúster. Entrará en vigor inmediatamente, otorgándose la demo cuenta de servicio las capacidades declaradas en el demo-role Role:
$ kubectl apply -f role-binding.yaml rolebinding.rbac.authorization.k8s.io/demo-role-binding created
Prueba de su regla RBAC
Pruebe su implementación simple de RBAC volviendo al nuevo contexto de Kubectl que creó para el demo cuenta:
$ kubectl config use-context demo Switched to context "demo".
Ahora repite el get pods comando de antes:
$ kubectl get pods No resources found in default namespace.
Esta vez el comando ha tenido éxito. los demo la cuenta de servicio ahora puede recuperar listas de Pod porque está vinculada a la demo-role Role. Aún verá un error Prohibido si intenta crear un nuevo Pod porque esa operación no está incluida en ningún rol vinculado a la cuenta:
$ kubectl run nginx --image=nginx Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"
Puede resolver esto asignando al usuario otro rol que incluya el create verbo para el pods recurso. Como alternativa, puede editar el archivo YAML de su rol existente y aplicar la versión modificada a su clúster:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list"]
También puede agregar reglas adicionales a su rol para crear diferentes combinaciones de grupos de recursos y acciones permitidas.
Resumen
RBAC le permite definir las capacidades de software disponibles para cuentas de usuario individuales. El sistema RBAC de Kubernetes proporciona controles muy precisos para limitar los tipos de recursos a los que pueden acceder las cuentas y las acciones que pueden realizar.
La adopción de RBAC refuerza la seguridad en torno a su clúster y crea un entorno operativo menos riesgoso. Sin embargo, aún debe tener en cuenta las mejores prácticas para evitar la introducción de nuevos problemas. Debe auditar regularmente su clúster para identificar cuentas con privilegios excesivos y limpiar roles redundantes. Esto ayudará a evitar confusiones y le permitirá obtener una imagen clara de las acciones que puede realizar cada cuenta.
Las implementaciones efectivas de RBAC deben basarse en la menor cantidad posible de roles, y cada rol debe tener el conjunto mínimo de acciones necesarias para su área específica de funcionalidad. Asignar demasiados privilegios a cada cuenta anula los beneficios de RBAC, por lo que vale la pena dedicar tiempo a planificar los requisitos de cada usuario antes de comenzar a crear roles y enlaces.
