Admisión y clústeres gestionados (EKS y AKS)

La admisión de seguridad de pods se configura con etiquetas en cada namespace del tipo pod-security.kubernetes.io/<modo>=<nivel>. Hay tres modos: enforce rechaza el pod que incumple el nivel, warn deja pasar pero avisa a quien lo aplica y audit deja pasar y lo anota en el registro de auditoría. Un namespace con solo warn o audit informa pero no protege.

Las reglas de admisión propias del equipo funcionan igual: un modo que solo audita no bloquea nada.

En un namespace sin etiquetas de seguridad de pods no se exige nada: cualquier pod, privilegiado o no, entra. Lo habitual es que sea un namespace creado «para un trabajo puntual» y olvidado. Revisa namespaces.txt.

Una regla de admisión propia puede estar redactada correctamente y no proteger, si su modo es solo de auditoría. La señal está en la tabla del equipo de plataforma, que indica el modo de cada una. Una regla que se ve y no se hace cumplir es, además, un riesgo de confianza: el equipo cree que la etiqueta móvil está prohibida.

En AKS las cuentas locales están activadas por defecto. Aunque se active RBAC o la integración con Microsoft Entra, el acceso de administrador por credencial local sigue siendo una vía sin auditoría de identidad. Existe una propiedad del clúster que apaga las cuentas locales; al apagarlas, la entrada pasa por Entra y queda registrada a nombre de una persona. Si el clúster ya se usó con esas credenciales, además hay que rotar los certificados para revocar las que ya existen.

Abre aks-show.json y localiza esa propiedad y su estado.

Los registros del plano de control de EKS están apagados por defecto y se activan tipo por tipo: api, audit, authenticator, controllerManager y scheduler. El de auditoría es el que dice quién hizo qué sobre la API; el del autenticador, cómo se tradujeron las credenciales de AWS en identidades de Kubernetes. Sin ellos, una investigación posterior no tiene nada que leer.

Cuenta en eks-describe.json los tipos de registro que están desactivados.