Identidades y cuentas de servicio

Cuando un pod usa su token, la API registra el usuario con una forma fija: system:serviceaccount: seguido del namespace, dos puntos y el nombre de la cuenta. Las personas aparecen con el nombre que da su proveedor de identidad. Esa diferencia sirve para separar quién actúa sin tener que consultar ninguna otra lista.

Abre auditoria_por_identidad y mira la columna usuario.

Una cuenta de servicio es peligrosa cuando suma dos cosas: el token está montado en el pod, o sea accesible a cualquier proceso que corra ahí, y tiene un enlace de rol que le da permisos. Una cuenta con token pero sin permisos no hace daño; una con permisos pero sin token montado tampoco se usa desde dentro del pod.

Abre cuentas_de_servicio.

Un enlace de rol vale para un namespace. Un enlace de rol de clúster vale para todo el clúster. Dar a una cuenta de servicio el rol de administrador del clúster es lo más cómodo y lo más caro: el token de ese pod abre cualquier cosa. La columna alcance distingue ambos casos.

El rastro en la auditoría muestra qué hizo cada identidad. Una cuenta que lee secretos de su propio namespace hace su trabajo. Una que los lista en otros namespaces, con éxito, está usando un permiso que probablemente nadie recuerda haber dado. En auditoria_por_identidad hay una cuenta que listó secretos de tres namespaces con código 200.

Una cuenta de servicio hace casi siempre lo mismo: el mismo verbo, sobre los mismos recursos, desde los mismos pods. Esa regularidad es la línea base. En la tabla de eventos, la cuenta catalogo intenta listar secretos de dos namespaces ajenos y recibe 403 las dos veces.