Configuración del servidor de API

El servidor de API recibe una petición y hace dos preguntas distintas, en orden: ¿quién eres? (autenticación) y ¿puedes hacer esto? (autorización). Con la autenticación anónima activada, una petición sin credenciales no se rechaza en la primera pregunta: se atiende como el usuario system:anonymous, del grupo system:unauthenticated, y es la segunda pregunta la que decide qué puede hacer.

Por eso el benchmark pide desactivarla aunque la autorización esté bien configurada: reduce a una sola capa lo que debería ser defensa en profundidad, y cualquier permiso concedido por error a ese grupo queda abierto a quien llegue a la red del servidor de API.

En un clúster donde el servidor de API corre como pod estático, su configuración es la lista command de un archivo de especificación en el nodo del plano de control. Leerla es el equivalente de leer un archivo de configuración: cada línea --parametro=valor es una decisión. Lo que el benchmark pide está escrito como parámetro y valor esperado; el hallazgo se confirma comparando ambos.

Abre el archivo de especificación del servidor de API y busca el parámetro que permite las peticiones anónimas.

Un hallazgo no siempre es un valor equivocado: a menudo es un parámetro ausente o una lista incompleta. Los plugins de admisión son un ejemplo: el parámetro que los habilita es una lista, y si un plugin recomendado no está en ella, el servidor funciona igual y simplemente no aplica esa comprobación. Nada avisa; solo el informe lo muestra.

Compara la lista de plugins de admisión del manifiesto con la remediación del informe de kube-bench.

El informe del plano de control mezcla secciones. La 1.1 trata los archivos de configuración de los componentes (permisos y propietarios) y la 1.2 trata los parámetros del servidor de API. Un FAIL de archivo se corrige con un cambio en el sistema de archivos; uno de parámetro, cambiando la especificación del pod. Separarlos permite repartir el trabajo y no mezclar dos tipos de cambio.

Cuenta solo los FAIL de la sección 1.2 en el extracto del informe.

En un pod estático, el kubelet vigila el archivo de especificación y recrea el pod cuando cambia. Eso hace el cambio fácil y también riesgoso: un parámetro mal escrito puede impedir que el servidor de API arranque, y con él se pierde el acceso al clúster entero. Por eso el cambio se ensaya, se revisa antes de aplicarse y se comprueba después con una nueva corrida del informe.