Es una práctica recomendada bien conocida que los profesionales de TI deben usar cuentas de usuario sin privilegios en cualquier sistema que usen regularmente y solo elevar sus privilegios cuando sea necesario. Realizar tareas cotidianas con privilegios de «Superusuario» o «Administrador» puede conducir a errores simples que pueden causar daños graves y correr el riesgo de ejecutar malware sin darse cuenta.
Los administradores de sistemas Linux están acostumbrados a sudo comando para escalar un solo comando a los privilegios de raíz cuando se inicia sesión como un usuario sin privilegios.Cuando estos administradores del sistema se convierten en administradores de clústeres de Kubernetes u operadores de plataforma, no están acostumbrados a usar credenciales OAuth o kubeconfig El archivo les otorga acceso sin restricciones al clúster para realizar tareas cotidianas, como crear pods.
[ Download now: Advanced Linux commands cheat sheet. ]
Kubernetes no ofrece nada como Linux sudo utilidad. En su lugar, proporciona dos características que permiten a un usuario suplantar a otro usuario para realizar solicitudes de la API de Kubernetes: suplantar el título y suplantar el verbo.
Tabla de Contenidos
Escenarios de ejemplo para usuarios desarrolladores y administradores
Mi clúster de prueba reconoce dos usuarios: administrativo (administrador del clúster) y desarrollador (tiene acceso a espacios de nombres previamente creados y autorizados por el administrador del clúster).
Este tipo de configuración, que incluye múltiples usuarios con diferentes niveles de acceso, es fácil de crear con OpenShift pero no tan fácil con Kubernetes estándar, lo que lleva a muchos usuarios de Kubernetes al mal hábito de trabajar con privilegios de administrador de clúster completos todo el tiempo.Afortunadamente, el sitio web Kube By Example proporciona una ejercicio guiado y guion de muestra Puede usar minikube para crear una configuración de este tipo. No debería ser difícil adaptarse a otras versiones de Kubernetes.
si inicio sesión como desarrollador, no tengo acceso a los recursos de API de nivel de clúster, como la lista de nodos.puedes usarlo kubectl config Ordenar. El nombre de usuario es el componente de ruta final del contexto actual:
$ kubectl config current-context
dev/api-ocp4-example-com:6443/developer
$ kubectl get node
Error from server (Forbidden): nodes is forbidden: User "developer" cannot list resource "nodes" in API group "" at the cluster scope
si inicio sesión como administrativotengo acceso sin restricciones a todos los recursos de la API en el clúster:
$ kubectl config current-context
dev/api-ocp4-example-com:6443/admin
$ kubectl get node
NAME STATUS ROLES AGE VERSION
master01 Ready master,worker 32d v1.24.0+b62823b
Mi clúster también contiene desarrollar espacio de nombres, y desarrollador El usuario tiene una función de «edición», que debería ser suficiente para crear pods, implementaciones, secretos y otros recursos de aplicaciones comunes.
[ Learn Kubernetes basics; download the cheat sheet. ]
El siguiente ejemplo crea un pod que muestra la hora actual y elimina el pod inmediatamente. El propósito es verificar que el usuario desarrollador pueda realizar tareas de desarrollo en mi clúster de prueba:
$ kubectl config current-context
dev1/api-ocp4-example-com:6443/developer
$ kubectl run now -it --rm --restart Never --image registry.access.redhat.com/ubi9/ubi -- /bin/bash -c date
Wed Dec 7 22:37:46 UTC 2022
pod "now" deleted
Para mantener este artículo independiente del sabor de Kubernetes, no detallé cómo se autentica cada usuario.Puedes usar diferentes kubeconfig archivar y configurar Configuración de Kube Variables por usuario, o puede usar extensiones de proveedores, p. oc login Comandos de OpenShift.
Ejecute el comando como un usuario normal, conectado como administrador
Todas las solicitudes de API de Kubernetes aceptan una serie de encabezados de suplantación que permiten llamadas a solicitudes autenticadas como un usuario pero autorizadas como un usuario diferente.Esto kubectl comandos (y por supuesto el OpenShift oc comando) incluya estos encabezados si especifica --as o --as-group opción.
El uso de estos encabezados de suplantación requiere permisos especiales que los usuarios normales no tienen de forma predeterminada, por lo que primero mostraré cómo un administrador de clústeres puede suplantar a un usuario normal:
$ kubectl config current-context
dev/api-ocp4-example-com:6443/admin
$ kubectl run now -it --rm --restart Never --image registry.access.redhat.com/ubi9/ubi --as developer -- /bin/bash -c date
Wed Dec 7 22:42:48 UTC 2022
pod "now" deleted
$ kubectl get node --as developer
Error from server (Forbidden): nodes is forbidden: User "developer" cannot list resource "nodes" in API group "" at the cluster scope
Tenga en cuenta que en la salida anterior administrativo Los usuarios pueden crear pods como desarrollador usuario pero no puede enumerar los nodos del clúster. Solo puede crear pods en el espacio de nombres desarrollador El usuario tiene acceso a:
$ kubectl run now -it --rm --restart Never --image registry.access.redhat.com/ubi9/ubi -n default --as developer -- /bin/bash -c date
Error from server (Forbidden): pods is forbidden: User "developer" cannot create resource "pods" in API group "" in the namespace "default"
Si bien suplantar a un usuario normal puede ser útil para verificar que haya configurado los espacios de nombres vinculados a roles correctos para los usuarios de su clúster, esto es contrario a lo que promete el título de este artículo. Manténganse al tanto.
[ Find everything you need to know about Kubernetes. ]
Ejecute el comando como administrador, inicie sesión como un usuario normal
Como era de esperar, un usuario normal no puede hacerse pasar por un administrador o cualquier otro usuario:
$ kubectl config current-context
dev1/api-ocp4-example-com:6443/developer
$ kubectl get node --as admin
Error from server (Forbidden): users "admin" is forbidden: User "developer" cannot impersonate resource "users" in API group "" at the cluster scope
Necesita un rol personalizado para permitir que un usuario se haga pasar por otro usuario.el seguimiento sudo-role.yaml El archivo define un rol de clúster que permite que cualquier persona se haga pasar por administrativo usuario, con privilegios de administrador de clúster en mi clúster de prueba y un enlace de rol de clúster que otorga ese rol a desarrollador usuario:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: sudo-admin
rules:
- apiGroups: [""]
resources: ["users"]
verbs: ["impersonate"]
resourceNames: ["admin"]
esto está relacionado sudo-role-binding.yaml documento:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: sudo-admin-to-developer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: sudo-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: developer
Puede pensar que los enlaces de roles de clúster son extraños, y tiene una buena razón para sentirse así: no hay un tipo de recurso de API de «usuario» en Kubernetes. Los controladores de control de acceso basado en roles (RBAC) de Kubernetes usan tipos de recursos en roles como tipos de sujetos para hacer coincidir. Puede hacer coincidir no solo usuarios y grupos, sino también cuentas de servicio, ID de usuario y otros tipos de entidades que su proveedor de autenticación pueda admitir.
Como administrador del clúster, cree roles de clúster y enlaces de roles de clúster:
$ kubectl config current-context
dev/api-ocp4-example-com:6443/admin
$ oc create -f sudo-role.yaml
clusterrole.rbac.authorization.k8s.io/sudo-admin created
$ oc create -f sudo-role-binding.yaml
clusterrolebinding.rbac.authorization.k8s.io/sudo-admin-to-developer created
y cambiar a desarrollador el usuario comprueba que ahora puede simular administrativo usuario:
$ kubectl config current-context
dev1/api-ocp4-example-com:6443/developer
$ kubectl get node --as admin
NAME STATUS ROLES AGE VERSION
master01 Ready master,worker 32d v1.24.0+b62823b
envolver
Si su clúster tiene un usuario administrador de clúster predefinido, como Administrador de sistema Usuarios de OpenShift, puede usar el nombre en lugar de administrativoNo pierde la auditabilidad ya que todas las solicitudes de la API de Kubernetes aún se autentican como desarrollador usuario, independientemente de qué usuario esté siendo suplantado.
¿Qué sucede si desea otorgar más permisos que un «desarrollador normal» pero aún menos que un administrador de clúster completo? Simplemente use Kubernetes RBAC normal para crear una función que proporcione solo los permisos que desea y asigne esa función a un usuario o grupo. Luego cree otra función para suplantar a un usuario o grupo con esa función específica.
[ Want to test your sysadmin skills? Take a skills assessment today. ]
