¿Cómo podemos limitar una cuenta de servicio para que solo pueda crear, enumerar, eliminar, etc. objetos que tengan una etiqueta específica dentro de un espacio de nombres determinado?
Hemos diseñado una jerarquía de servicios (que se asignan a los espacios de nombres de Kubernetes) y componentes (que están representados por una personaetiqueta en varios objetos) y la integramos con Vault de tal manera que los secretos a los que tiene acceso son específicos de un servicio. par de componentes. Esto ayuda a segregar las cosas. Por ejemplo, imagine un equipo que gestiona varias implementaciones y solo algunas de ellas manejan datos PII. Podemos usar esa etiqueta para otorgar acceso selectivamente a esos secretos.
# only approximatively k8s objects
---
kind: Deployment
metadata:
name: backend
namespace: banana
labels:
persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
name: frontend
labels:
persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar
Sin embargo, eso significa que no queremos simplemente crear una cuenta de servicio que pueda administrartodopods en ese espacio de nombres: si se filtra el secreto de esa cuenta de servicio, un atacante podría usarlo para iniciar un pod con una imagen maliciosa y acceso a PII.
Entonces me gustaría tener algo como: (tenga en cuenta que mi conocimiento sobre cuentas de servicio, roles y vinculaciones de roles es extremadamente limitado)
# even more approximatively so k8s objects
kind: Role
metadata:
name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
selector:
labels:
persona: frontend
# even if compromised, this service account cannot access banana§backend secrets
Parece k8podríaadmitir algo vagamente como esto, por ejemplo, proporcionando una lista de nombres de recursos específicos (#), pero que esto no es algo que k8s admita a partir de ahora? ¿O me estoy perdiendo algo?
¿Nuestra única alternativa es configurar una cuenta de servicio para todo el clúster con amplio acceso a todo y luego activar un servicio web que realice su propia rutina personalizada de autenticación y autorización antes de usar el token? Si es así, ¿cómo podemos limitar al máximo el alcance de esta "cuenta divina"?
Respuesta1
Kubernetes no tiene forma de restringir ellistaverbo por objeto. Si puede enumerar una colección, puede leer todos los objetos de esa colección.
Quizás algún día eso cambie, pero ahora así es como funciona Kubernetes en términos de colecciones y acceso de lectura. Eso incluye acceso de lectura a Secretos...
Sin embargo, si desea restringirescribea objetos, puedes hacer eso. Puede limitar la capacidad de escribir en objetos con nombre específicos usando:
- un webhook de admisión de validación externo
- una política de admisión de validación (beta)
- un webhook de autorización
o utilizar reglas RBAC cuidadosamente elaboradas.
Algo que podría ayudarle a gestionar el acceso es lacontrolador de espacios de nombres jerárquicos, permitiendo a un equipo gestionar unacolocarde espacios de nombres y cada uno tiene sus propias restricciones. Si su clúster admite ValidatingAdmissionPolicies, puede utilizarlas para delegar aún más el acceso y restringir el acceso de escritura (aunque es un tema bastante complicado).
Si desea tener una ServiceAccount que pueda hacer cosas, pero delegar el control de esas cosas, puede crear una ServiceAccount en cada espacio de nombres de destino con un RoleBinding y luego permitir que la ServiceAccount general se haga pasar por las ServiceAccounts específicas. Nuevamente, esto es algo bastante complejo de abordar, pero es posible.