Asegurar el cl煤ster de Kubernetes es una cosa, pero mantener la seguridad sigue siendo un desaf铆o. Sin embargo, se han agregado nuevas herramientas a Kubernetes: ahora es mucho m谩s f谩cil hacer ambas cosas.
Kubernetes (desde la versi贸n 1.6) introdujo el concepto de control de acceso basado en roles (RBAC), que permite a los administradores definir pol铆ticas de restricci贸n para los usuarios del cl煤ster. Es decir, crea un usuario con acceso limitado: limite el acceso del usuario a recursos como secretos o ciertos espacios de nombres.
En esta publicaci贸n, no entenderemos c贸mo implementar RBAC. Hay suficientes fuentes decentes en las que se discute este tema desde y hacia:
Es mejor centrarse en c贸mo asegurarse de que se cumplan los requisitos de su empresa, y ver si los objetos RBAC en ejecuci贸n deben verificarse para ver si cumplen sus funciones.
Nuestro gui贸n
Algunas organizaciones aceptan varios grupos para trabajar con el nuevo cl煤ster de Kubernetes. Existe un requisito: no puede interferir en el despliegue de un grupo vecino, de modo que no haya problemas intergrupales o tiempos de inactividad imprevistos.
Y as铆, el propietario del cl煤ster implement贸 RBAC en el cl煤ster, lo que limita el acceso a un espacio de nombres espec铆fico. La primera comprobaci贸n mostr贸: los grupos no pueden ver los pods de los dem谩s en el espacio de nombres.
Ha pasado una semana. El propietario del cl煤ster not贸 que un usuario de un espacio de nombres aislado est谩 leyendo secretos de otro espacio de nombres. 驴C贸mo es eso? 脡l us贸 RBAC!
Lo apliqu茅, pero, como al trabajar con c贸digo, el sistema debe ser probado para cumplir con el resultado deseado. Es bueno que la kubectl Kubectl CLI Kubernetes proporcione un conjunto de herramientas para verificar la configuraci贸n de RBAC. kubectl auth can-i
Puedo? ("驴Puedo?")
can-i usando la API solo verifica si se puede realizar una determinada acci贸n. Utiliza los siguientes par谩metros: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] . Ahora el usuario actual puede verificar si una acci贸n espec铆fica est谩 disponible para 茅l. Vamos:
kubectl auth can-i create pods
Esto deber铆a devolver una respuesta "s铆" o "no" con el c贸digo de salida apropiado.
Sin embargo, cuando tratamos de verificar los derechos de otro usuario, nos encontramos con un problema: el usuario bajo el cual estamos autorizados en el cl煤ster se especifica en el archivo de configuraci贸n ./kube/config , y es inconveniente tener configuraciones separadas para probar usuarios individuales. Afortunadamente, Kubernetes viene al rescate nuevamente: puede simular usuarios usando las etiquetas --as= y --as-group= .
Actualice el comando, use la simulaci贸n de otro usuario:
kubectl auth can-i create pods --as=me
Deber铆amos ver que con el c贸digo de salida 1 , se devuelve la respuesta "no".
Y esto es genial, porque ahora tenemos un conjunto de comandos que nos permiten verificar si un usuario o grupo de usuarios tiene acceso a cualquiera de los recursos de Kubernetes, desde la visualizaci贸n de pods hasta la eliminaci贸n de secretos.
Automatizaci贸n
Sin embargo, es demasiado pronto para detenerlo: ahora podemos implementar una secuencia de prueba que describir谩 la lista de requisitos y la ejecutar谩 como parte de la canalizaci贸n del CD. A la causa!
Hay mucho para elegir, hay suficientes idiomas para implementar: comenzando con Ava y Mocha en JavaScript y terminando con Rspec. En este caso, implemento el marco de prueba puramente Bash Bats .
A continuaci贸n se muestra un ejemplo de ejecuci贸n de una prueba. Comprueba el funcionamiento de las reglas RBAC que permiten a un usuario de un grupo cambiar el n煤mero de hogares en ejecuci贸n en el espacio de nombres. Se ejecuta si se ha establecido el atributo "ejecutable". O bien, utilizando el bats filename .
#!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done }
Los --as-group --as y --as-group requieren el uso de las siguientes reglas RBAC:
rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create
Aqu铆 hay un m茅todo simple para implementar controles en sus reglas RBAC en Kubernetes. Al hacerlo parte de la tuber铆a de Kubernetes, fortaleceremos significativamente la pol铆tica de RBAC. El m茅todo ha sido probado en la pr谩ctica: 隆detectar cambios que violan las pol铆ticas de acceso es mucho m谩s r谩pido!
隆Gracias por tomarte el tiempo de leer esta publicaci贸n!