Geekly articles weekly

Usuarios y autorización de Kubernetes RBAC

Nota perev. : Continuando con el tema recientemente planteado sobre la seguridad de Kubernetes en general y RBAC en particular, estamos publicando una traducción de este material de un consultor francés de la compañía internacional Adaltas Big Data. El autor muestra en detalle cómo crear usuarios, otorgarles derechos y continuar sirviendo.

Configurar e iniciar un clúster de Kubernetes es solo el comienzo: también debe ser explotado. Para asegurar el acceso al clúster, debe establecer las credenciales de usuario y administrar correctamente la configuración de autenticación y autorización.

(Ilustración tomada del blog de CNCF - aprox. Transl.)

Este artículo trata sobre cómo crear usuarios usando certificados de cliente X.509 y cómo administrar la autorización usando las API básicas de RBAC en Kubernetes. También hablaremos sobre algunos proyectos de código abierto que simplifican la administración del clúster: rakkess, kubectl-who-can, rbac-lookup y RBAC Manager.

Precondiciones y supuestos


En primer lugar, es necesario hacer varias suposiciones:


Si no tiene un clúster de Kubernetes listo para usar, le recomiendo que consulte el artículo de un colega (Arthur BUSSER) en el que habla sobre la instalación de Kubernetes en CentOS 7 usando Vagrant.

Hay 4 nodos en nuestro clúster: un maestro y 3 trabajadores. El asistente también se usará como un nodo de borde para interactuar con el clúster.

API de RBAC


El control de acceso basado en roles (RBAC) es un método para controlar el acceso a computadoras y recursos de red, basado en los roles de usuarios individuales en una empresa. RBAC se puede usar con todos los recursos de Kubernetes que admiten CRUD (Crear, Leer, Actualizar, Eliminar). Ejemplos de tales recursos:

  • espacios de nombres
  • Vainas
  • Implementaciones
  • volúmenes persistentes (PersistentVolumes);
  • ConfigMaps

Y aquí hay ejemplos de posibles operaciones con ellos:

  • create
  • get
  • delete (eliminar) ;
  • list (vista de list ) ;
  • update

Para administrar RBAC en Kubernetes, debemos declarar:

  • Role y ClusterRole . Estos son simplemente conjuntos de reglas que representan un conjunto de permisos. Role solo se puede usar para proporcionar acceso a los recursos dentro de los espacios de nombres. ClusterRole puede proporcionar los mismos permisos que Role , y también dar acceso a los recursos disponibles en todo el clúster, y los llamados puntos finales que no son de recursos (como /healthz - aprox. Transl.) .
  • Subjects El sujeto es una entidad que realizará operaciones en un clúster. Pueden ser usuarios, servicios o incluso grupos.
  • RoleBinding y ClusterRoleBinding . Como su nombre lo indica, esto es simplemente un enlace del sujeto a un Rol o ClusterRole.

Kubernetes tiene los siguientes roles predeterminados:

  • view : acceso de solo lectura, excluye secretos;
  • edit : lo anterior + la capacidad de editar la mayoría de los recursos, excluye roles y enlaces de roles;
  • admin : lo anterior + la capacidad de administrar roles y asignaciones de roles a nivel de espacio de nombres;
  • cluster-admin : todos los privilegios posibles.

Por supuesto, puede crear sus propios Roles y ClusterRoles , pero le recomendamos que utilice los roles predeterminados tanto como sea posible, según lo permita la situación. De lo contrario, puede confundirse rápidamente con todo esto.

Ejemplo de uso


Crearemos dos espacios de nombres: my-project-dev y my-project-prod , así como dos usuarios: jean y sarah , con diferentes roles en estos espacios de nombres:

  • my-project-dev:
    • jean: editar
  • my-project-prod:
    • jean: ver
    • sarah: editar

Crear y autenticar usuarios utilizando certificados de cliente X.509


Por lo general, hay dos tipos de usuarios: cuentas de servicio administradas por Kubernetes y usuarios habituales. Nos centraremos en lo último. Así es como se describen en la documentación oficial:

Se supone que los usuarios regulares son administrados por un servicio externo e independiente. El rol puede ser desempeñado por un administrador que distribuye claves privadas, un repositorio de usuarios como Keystone o Cuentas de Google, o incluso un archivo con una lista de nombres de usuario y contraseñas. En este sentido, Kubernetes no tiene objetos que representen a los usuarios comunes. Los usuarios comunes no se pueden agregar al clúster a través de una llamada a la API.

Hay varias formas de administrar usuarios habituales:

  • Autenticación básica:
    • transferir la configuración al servidor API con los siguientes contenidos (o similares): contraseña, nombre de usuario, uid, grupo;
  • Certificado de cliente X.509:
    • creación de una clave secreta de usuario y solicitud de firma de certificado;
    • certificación en una autoridad de certificación (Kubernetes CA) para obtener un certificado de usuario;
  • Fichas de portador (JSON Web Tokens, JWT):
    • OpenID Connect
    • capa de autenticación sobre OAuth 2.0;
    • webhooks

En este artículo, utilizaremos los certificados X.509 y OpenSSL debido a su simplicidad. La creación de usuarios se lleva a cabo en varias etapas: los revisaremos todos. Las operaciones deben realizarse bajo la cuenta de usuario con privilegios de administrador del clúster (cluster-admin). Estos son todos los pasos para crear un usuario (usando jean como ejemplo):

  • Cree un usuario en el asistente y luego vaya a su directorio de inicio para completar los pasos restantes:

     useradd jean && cd /home/jean
  • Crea una clave privada:

     openssl genrsa -out jean.key 2048
  • Cree una solicitud de firma de certificado (CSR). CN es el nombre de usuario, O es el grupo. Puede establecer permisos por grupo. Esto simplificará el trabajo si, por ejemplo, tiene muchos usuarios con los mismos permisos:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • Firme CSR en Kubernetes CA. Debemos utilizar el certificado y la clave de CA, que generalmente se encuentran en /etc/kubernetes/pki . El certificado será válido por 500 días:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • Crea el directorio .certs . En él almacenaremos las claves públicas y privadas del usuario:

     mkdir .certs && mv jean.crt jean.key .certs
  • Crea un usuario dentro de Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • Establecer contexto para el usuario:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • Edite el archivo de configuración del usuario. Contiene la información necesaria para la autenticación en un clúster. Puede usar el archivo de configuración del clúster, que generalmente se encuentra en /etc/kubernetes : las variables de server y certificate-authority-data deben ser las mismas que en el archivo mencionado:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    Ahora necesita copiar la configuración anterior en el directorio .kube :

     mkdir .kube && vi .kube/config
  • Queda por hacer que el usuario sea el propietario de todos los archivos y directorios creados:

     chown -R jean: /home/jean/

El usuario jean creó con éxito. Haremos lo mismo por sarah . Hay bastantes pasos, y crear una gran cantidad de usuarios puede llevar mucho tiempo. Por lo tanto, escribí scripts de Bash que automatizan el proceso: se pueden encontrar en el repositorio en GitHub .

Nota perev. : Como escribimos en nuestro artículo reciente , este procedimiento puede simplificarse de una manera más "nativa" para Kubernetes, a través de nuevas funciones en la utilidad de consola kubeadm . Sin embargo, recuerde que al momento de la publicación de esta traducción, están disponibles en forma alfa. Un ejemplo de un comando para crear un usuario es kubeadm alpha kubeconfig user .

Ahora tenemos usuarios, y podemos pasar a crear dos espacios de nombres:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

Como aún no hemos determinado la autorización del usuario, no deberían tener acceso a los recursos del clúster:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

Creación de Role y ClusterRole


Utilizaremos ClusterRole , disponible por defecto. Sin embargo, también mostramos cómo crear su propio Role y ClusterRole . En esencia, Role y ClusterRole son solo un conjunto de acciones (llamadas verbs , es decir, verbos - verbos) que están permitidos para ciertos recursos y espacios de nombres. Aquí hay un archivo YAML de ejemplo:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

Para crearlos, ejecute el comando:

 kubectl create -f /path/to/your/yaml/file

Enlace de rol o clúster a usuarios


Ahora enlace el ClusterRole predeterminado ( edit y view ) a nuestros usuarios de la siguiente manera:

  • jean :
    • edit - en el espacio de nombres my-project-dev ;
    • view - en el espacio de nombres my-project-prod ;
  • sarah :
    • edit : en el espacio de nombres my-project-prod .

Los RoleBindings deben especificarse por espacios de nombres, no por usuarios. En otras palabras, para autorizar jean crearemos dos RoleBindings. Un ejemplo de un archivo YAML que define RoleBindings para jean :

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

jean que jean view my-project-prod y edite my-project-dev . Lo mismo debe hacerse con las autorizaciones para sarah . Para activarlos, ejecute el comando:

 kubectl apply -f /path/to/your/yaml/file

En este caso, se utilizó kubectl apply lugar de kubectl create . La diferencia entre los dos es que create crea el objeto y no hace nada más, y apply : no solo crea el objeto (si no existe), sino que también lo actualiza si es necesario.

Verifiquemos si nuestros usuarios han recibido los permisos necesarios.

  • Usuario: sarah ( edit en my-project-prod )
    • my-project-prod
      • puede enumerar las vainas (1);
      • puede crear implementaciones (2).
    • my-project-dev
      • no puede enumerar las vainas (4);
      • no puede crear implementaciones (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • Usuario: jean ( view en my-project-prod y edit en my-project-dev )
    • my-project-prod
      • puede enumerar las vainas (1);
      • puede enumerar despliegue'ov (2);
      • no se pueden eliminar implementaciones (3).
    • my-project-dev:
      • puede enumerar vainas (4);
      • puede crear implementaciones (5);
      • puede enumerar despliegue'ov (6);
      • puede eliminar implementaciones (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

Gestión de usuarios y autorización


Por lo tanto, hemos establecido con éxito varios roles y autorizaciones de usuario. Surge la pregunta: ¿cómo manejar ahora todo esto? ¿Cómo sé si los permisos para un usuario específico están configurados correctamente? ¿Cómo sé quién tiene la autoridad para realizar una acción específica? ¿Cómo obtener una imagen general de los permisos de usuario?

Necesitamos respuestas a todas estas preguntas para garantizar la seguridad del clúster. El kubectl auth can-i permite averiguar si un usuario puede realizar una acción específica:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

El primer comando (1) permite al usuario descubrir si puede realizar alguna acción. El segundo (2): permite al administrador hacerse pasar por el usuario para averiguar si puede realizar una determinada acción. Esta "reencarnación" está permitida solo para usuarios con privilegios de administrador de clúster.

Esto es prácticamente todo lo que se puede hacer con el kit de herramientas incorporado. Es por eso que presentaré algunos proyectos de código abierto que amplían las capacidades que ofrece el equipo kubectl auth can-i. Antes de presentarlos, establezcamos las dependencias: Go and Krew .

Ir a la instalación


Go es un lenguaje de programación de código abierto que le permite crear software simple, confiable y eficiente. Fue desarrollado por Google bajo la inspiración de C y Pascal, basado en los conceptos originales de Robert Griesemer , Rob Pike y Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Instalación de Krew


Krew es una herramienta que simplifica el uso de los complementos de kubectl . Krew te ayuda a encontrar, instalar y administrar complementos. En términos de funciones, se asemeja a herramientas como apt, dnf o brew. Krew solo es compatible con kubectl versión 1.12 y superior.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

rakkess


Este proyecto le permite ver todos los permisos que se le han otorgado al usuario. Por ejemplo, ayuda a responder la pregunta de qué puede hacer jean . En primer lugar, vamos a instalarlo:

 kubectl krew install access-matrix

La documentación del proyecto se puede encontrar en el repositorio en GitHub . Aquí hay un ejemplo de su trabajo:

 kubectl access-matrix -n my-project-dev --as jean



kubect-quien-puede


Este proyecto nos permite descubrir qué usuarios pueden realizar una acción específica. Ayuda a responder la pregunta: "¿Quién puede hacer esto?" Instalación:

 go get -v github.com/aquasecurity/kubectl-who-can

La documentación está en el repositorio de GitHub . Ejemplo de trabajo:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

rbac-lookup


Este proyecto proporciona una descripción general de las reglas RBAC. Ayuda a responder las preguntas: “¿A qué rol pertenecen jean y sarah ?”, “¿A qué rol pertenecen todos los usuarios?”, “¿A qué rol pertenece todo el grupo?”. Para instalar, ejecute el comando:

 kubectl krew install rbac-lookup

La documentación está en el repositorio de GitHub . Aquí hay un ejemplo de trabajo:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

Gerente de RBAC


Como el nombre de este proyecto obviamente implica, él es el gerente de RBAC. Simplifica las muchas manipulaciones necesarias. Quizás lo más importante es la creación de RoleBindings. Vimos anteriormente que al crear diferentes roles para un usuario, es necesario crear diferentes RoleBindings. RBAC Manager ayuda al permitirle hacer un solo RoleBinding con todas las autorizaciones a la vez. Para instalar, debe descargar el archivo YAML del repositorio en GitHub:

 kubectl apply -f /path/to/rbac/manager/yaml/file

La documentación oficial está en el repositorio de GitHub . Ejemplo de trabajo:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

Conclusión


Creamos usuarios en el clúster de Kubernetes utilizando el certificado de cliente X.509 con OpenSSL y los habilitamos. Para facilitar la creación de usuarios, puede utilizar el script disponible en mi repositorio en GitHub (o los comandos experimentales de kubeadm - aprox. Transl.) . En cuanto a la administración de clústeres, puede usar los proyectos de código abierto presentados en el artículo:

  • kubectl auth can-i : averigua si el usuario puede realizar alguna acción;
  • rakkess : descubre todas las acciones que el usuario puede realizar;
  • kubectl-who-can : determina qué usuarios pueden realizar alguna acción;
  • rbac-lookup : obtenga una visión general de RBAC;
  • Administrador de RBAC : simplifique la configuración combinando enlaces de derechos, automatizando cambios a RBAC, usando etiquetas como selectores para asignar derechos.

La creación de usuarios puede convertirse en una tarea que requiere mucho tiempo, especialmente si necesita establecer una gran cantidad de usuarios a la vez (o crearlos con frecuencia). Para aliviar la situación, puede conectar LDAP corporativo al clúster de Kubernetes. Algunos proyectos de código abierto ( Kismatic [el objeto parece abandonado] y ObjectifLibre ) ofrecen webhooks de Kubernetes que permiten la autenticación directa a través de LDAP. Otra posible solución es configurar un servidor OpenID con LDAP corporativo como back-end.

PD del traductor


Lea también en nuestro blog:

Source: https://habr.com/ru/post/470503/

More articles:


All Articles