Permisos de cuentas de servicio

En Kubernetes los permisos se definen con roles (un Role vale dentro de un namespace; un ClusterRole, en todo el clúster o sobre recursos sin namespace) y se asignan con enlaces (RoleBinding y ClusterRoleBinding) a un sujeto: un usuario, un grupo o una cuenta de servicio. Un RoleBinding puede apuntar a un ClusterRole, pero entonces ese rol solo vale dentro del namespace del enlace. Los permisos solo se suman: no existen reglas de denegación.

Abre la consola. Ejecuta SELECT * FROM enlaces.

Cada pod corre con una cuenta de servicio, y si el token está montado dentro del pod, quien consiga ejecutar algo allí puede usarlo contra la API con los permisos de esa cuenta. La cuenta llamada default existe en cada namespace y, con RBAC activo, no recibe permisos por sí misma: lo que tenga se lo dio alguien con un enlace.

Ejecuta SELECT * FROM enlaces WHERE rol = 'admin-cluster'.

En la auditoría, la cuenta de servicio de pedidos recibió dos rechazos al pedir secretos de otro namespace. Los permisos explican ese rechazo: en ese namespace, el rol que toca secretos está enlazado a otra cuenta, no a la de pedidos.

Ejecuta SELECT * FROM enlaces WHERE rol = 'lector-secretos'.

Un pod web con el token montado y permisos de administrador sobre todo el clúster es una exposición: no hay que probar que alguien la usó para reportarla, porque el riesgo está en lo que permite. Pero el SOC informa y recomienda: quitar o reducir un enlace en producción es una decisión de quien administra el clúster, con su control de cambios, porque puede romper la aplicación. Ejecuta SELECT * FROM cuentas WHERE pods > 0 AND token_montado = 'si' para ver cuántas cuentas están en esa situación.