Todo sobre Apple, Android, Juegos Apks y Sitios de Peliculas

Cómo empezar con Kubernetes RBAC

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 demasiados privilegios.

Las distribuciones de Kubernetes más populares comienzan con una única cuenta de usuario a la que se le otorga acceso de superusuario al clúster. La autenticación como esta cuenta le permite realizar cualquier acción, pero puede representar un riesgo de seguridad sustancial.

En este artículo, mostraremos cómo habilitar y configurar la API 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 hacer cumplir estas políticas utilizando el sistema RBAC.

Habilitación de RBAC en Kubernetes

RBAC es una característica opcional de Kubernetes, pero la mayoría de las distribuciones principales la incluyen activada de forma predeterminada, incluidas las de proveedores de nube administrada. 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 salida si RBAC está habilitado. RBAC se desactiva si el comando no produce ningún resultado. Puedes activarlo por iniciando el servidor API de Kubernetes con la bandera –authorization-mode=RBAC:

$ 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 utilizando 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.
  • Vinculación de roles – Un “vinculación” es un vínculo entre un rol y uno o más sujetos, que pueden ser usuarios o cuentas de servicio. La vinculación permite a los sujetos realizar cualquiera de las acciones incluidas en el rol objetivo.

Roles y RoleBindings son objetos con espacios 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 recursos a nivel de clúster, como los propios nodos y espacios de nombres, utilizando Roles de clúster y Enlaces de roles de clúster. Estos funcionan de manera similar a Roles y RoleBindings, pero apuntan a objetos sin espacios de nombres.

Crear 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 utiliza como 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.

Utilice 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. Puedes 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 la variable TOKEN 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.

Debe cambiar el valor del indicador –cluster para que coincida con el nombre de su conexión de clúster Kubectl activa. Suele ser el nombre predeterminado o el nombre del contexto seleccionado actualmente. Puede verificar el contexto seleccionado ejecutando kubectl config current-context.

Cambie a su nuevo contexto para autenticarse como su cuenta de servicio de demostración. Anote primero el nombre del 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 cuenta de servicio de demostración. 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 la cuenta del servicio de demostración carece de un rol que le permita acceder a los Pods.

Agregar un rol

Los roles se crean de la misma forma que cualquier otro objeto de Kubernetes. Escribe un archivo YAML que define la función y los permisos que proporciona. Cada rol contiene una o más reglas que permiten realizar acciones específicas contra un conjunto de recursos. Aquí hay una función simple que 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 verbos get y list aplicados al recurso pods significan que podrá ejecutar comandos como get pod y describe pod. Intentar crear un nuevo Pod o eliminar uno existente estará prohibido porque los verbos de creación y eliminación se omiten en la función.

Vuelva a su contexto de Kubectl original para poder 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 cuenta de servicio de demostración 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: ""

Los RoleBindings deben incluir uno o más sujetos que identifiquen a los usuarios y las cuentas de servicio a los que se dirige el enlace. El campo roleRef 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 ClusterRole y ClusterRoleBinding en su lugar para recursos sin espacios de nombres.

Luego ejecute kubectl apply para agregar RoleBinding a su clúster. Entrará en vigor de inmediato, otorgando a la cuenta de servicio de demostración las capacidades declaradas en el Rol demo:

$ kubectl apply -f role-binding.yaml

rolebinding.rbac.authorization.k8s.io/demo-role-binding created

Probando su regla RBAC

Pruebe su implementación RBAC simple volviendo al nuevo contexto de Kubectl que creó para la cuenta de demostración:

$ kubectl config use-context demo

Switched to context "demo".

Ahora repita el comando get pods de antes:

$ kubectl get pods

No resources found in default namespace.

Esta vez el comando ha tenido éxito. La cuenta de servicio de demostración ahora puede recuperar listas de pods porque está vinculada al rol de demostración. Seguirás viendo un error Prohibido si intentas crear un nuevo Pod porque esa operación no está incluida en ninguna función vinculada 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 otra función que incluya el verbo de creación para el recurso de pods. Alternativamente, 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 Kubernetes RBAC 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 alrededor de su clúster y crea un entorno operativo menos riesgoso. Sin embargo, aún es necesario tener en cuenta las mejores prácticas para evitar introducir nuevos problemas. Debe auditar periódicamente su clúster para identificar cuentas con privilegios excesivos y limpiar roles redundantes. Esto ayudará a evitar confusiones y le permitirá tener una idea 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 tomarse el tiempo para planificar los requisitos de cada usuario antes de comenzar a crear roles y enlaces.