Guía de autoevaluación CIS 1.23

El archivo de especificación del pod del servidor API controla varios parámetros que establecen el comportamiento del servidor API. Debe restringir los permisos de su archivo para mantener la integridad del mismo. El archivo debería ser escribible solo por los administradores del sistema.

El archivo de especificación del pod del servidor API controla varios parámetros que establecen el comportamiento del servidor API. Debe establecer la propiedad de su archivo para mantener la integridad del mismo. El archivo debería ser propiedad de root:root.

El archivo de especificación del pod del administrador de control controla varios parámetros que establecen el comportamiento del Administrador de Control en el nodo maestro. Debe restringir los permisos del archivo para mantener la integridad del archivo. El archivo debería ser escribible solo por los administradores del sistema.

El archivo de especificación del pod del administrador de control controla varios parámetros que establecen el comportamiento de varios componentes del nodo maestro. Debe establecer la propiedad del archivo para mantener la integridad del archivo. El archivo debería ser propiedad de root:root.

El archivo de especificación del pod del programador controla varios parámetros que establecen el comportamiento del servicio Scheduler en el nodo maestro. Debe restringir los permisos del archivo para mantener la integridad del archivo. El archivo debería ser escribible solo por los administradores del sistema.

El archivo de especificación del pod del programador controla varios parámetros que establecen el comportamiento del servicio kube-scheduler en el nodo maestro. Debe establecer la propiedad del archivo para mantener la integridad del archivo. El archivo debería ser propiedad de root:root.

El archivo de especificación del pod de etcd /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml controla varios parámetros que establecen el comportamiento del servicio etcd en el nodo maestro. etcd es un almacén de clave-valor altamente disponible que Kubernetes utiliza para el almacenamiento persistente de todos sus objetos de la API REST. Debe restringir los permisos del archivo para mantener la integridad del archivo. El archivo debería ser escribible solo por los administradores del sistema.

El archivo de especificación del pod de etcd /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml controla varios parámetros que establecen el comportamiento del servicio etcd en el nodo maestro. etcd es un almacén de clave-valor altamente disponible que Kubernetes utiliza para el almacenamiento persistente de todos sus objetos de la API REST. Debe establecer la propiedad de su archivo para mantener la integridad del mismo. El archivo debería ser propiedad de root:root.

La interfaz de red de contenedor proporciona varias opciones de red para la red superpuesta. Debería consultar su documentación y restringir los permisos de archivo respectivos para mantener la integridad de esos archivos. Esos archivos deberían ser escribibles solo por los administradores del sistema.

La interfaz de red de contenedor proporciona varias opciones de red para la red superpuesta. Debería consultar su documentación y restringir los permisos de archivo respectivos para mantener la integridad de esos archivos. Esos archivos deberían ser propiedad de root:root.

etcd es un almacén de clave-valor altamente disponible utilizado por las implementaciones de Kubernetes para el almacenamiento persistente de todos sus objetos de la API REST. Este directorio de datos debería estar protegido contra cualquier lectura o escritura no autorizada. No debería ser legible ni escribible por ningún miembro del grupo o por el público.

etcd es un almacén de clave-valor altamente disponible utilizado por las implementaciones de Kubernetes para el almacenamiento persistente de todos sus objetos de la API REST. Este directorio de datos debería estar protegido contra cualquier lectura o escritura no autorizada. Debería ser propiedad de etcd:etcd.

El admin.conf es el archivo kubeconfig del administrador que define varios ajustes para la administración del clúster. Deberías restringir los permisos de su archivo para mantener la integridad del archivo. El archivo debería poder ser modificado solo por los administradores del sistema.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/admin.kubeconfig.

El archivo admin.conf contiene las credenciales de administrador para el clúster. Deberías establecer la propiedad de su archivo para mantener la integridad del archivo. El archivo debería ser propiedad de root:root.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/admin.kubeconfig.

El archivo scheduler.conf es el archivo kubeconfig para el Scheduler. Deberías restringir los permisos de su archivo para mantener la integridad del archivo. El archivo debería poder ser modificado solo por los administradores del sistema.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig.

El archivo scheduler.conf es el archivo kubeconfig para el Scheduler. Deberías establecer la propiedad de su archivo para mantener la integridad del archivo. El archivo debería ser propiedad de root:root.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig.

El archivo controller.kubeconfig es el archivo kubeconfig para el Scheduler. Deberías restringir los permisos de su archivo para mantener la integridad del archivo. El archivo debería poder ser modificado solo por los administradores del sistema.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/controller.kubeconfig.

El archivo controller.kubeconfig es el archivo kubeconfig para el Scheduler. Deberías establecer la propiedad de su archivo para mantener la integridad del archivo. El archivo debería ser propiedad de root:root.

En RKE2, este archivo se encuentra en /var/lib/rancher/rke2/server/cred/controller.kubeconfig.

Kubernetes utiliza una serie de certificados como parte de su operación. Debería establecer la propiedad del directorio que contiene la información PKI y todos los archivos en ese directorio para mantener su integridad. El directorio y los archivos deberían ser propiedad de root:root.

Kubernetes utiliza una serie de archivos de certificado como parte de la operación de sus componentes. Los permisos de estos archivos deberían estar configurados a 644 o más restrictivos para proteger su integridad.

Kubernetes utiliza varios archivos de clave como parte del funcionamiento de sus componentes. Los permisos de estos archivos deben estar configurados a 600 para proteger su integridad y confidencialidad.

Cuando está habilitado, las solicitudes que no son rechazadas por otros métodos de autenticación configurados se tratan como solicitudes anónimas. Estas solicitudes son atendidas por el servidor API. Debe confiar en la autenticación para autorizar el acceso y deshabilitar las solicitudes anónimas.

Si utiliza autorización RBAC, generalmente se considera razonable permitir el acceso anónimo al servidor API para comprobaciones de salud y fines de descubrimiento, y por lo tanto, esta recomendación es Manual. Sin embargo, debe considerar si el descubrimiento anónimo es un riesgo aceptable para sus propósitos.

La autenticación basada en tokens utiliza tokens estáticos para autenticar solicitudes al apiserver. Los tokens se almacenan en texto claro en un archivo en el apiserver, y no pueden ser revocados o rotados sin reiniciar el apiserver. Por lo tanto, no utilice autenticación basada en tokens estáticos.

Este controlador de admisión rechaza todo uso nuevo del campo Service externalIPs. Esta función es muy poderosa (permite la interceptación del tráfico de red) y no está bien controlada por directivas. Cuando está habilitada, los usuarios del clúster no pueden crear nuevos Servicios que utilicen externalIPs y no pueden añadir nuevos valores a externalIPs en objetos de Servicio existentes. Los usos existentes de externalIPs no se ven afectados, y los usuarios pueden eliminar valores de externalIPs en objetos de Servicio existentes.

La mayoría de los usuarios no necesitan esta función en absoluto, y los administradores del clúster deberían considerar deshabilitarla. Los clústeres que necesitan usar esta función deberían considerar utilizar alguna directiva personalizada para gestionar su uso.

Las conexiones del apiserver a los kubelets podrían potencialmente llevar datos sensibles como secretos y claves. Por lo tanto, es importante utilizar cifrado en tránsito para cualquier comunicación entre el apiserver y los kubelets.

El apiserver, por defecto, no se autentica ante los puntos finales HTTPS del kubelet. Las solicitudes del apiserver se tratan de forma anónima. Debería configurar la autenticación del kubelet basada en certificados para asegurar que el apiserver se autentique ante los kubelets al enviar solicitudes.

Las conexiones del apiserver al kubelet se utilizan para obtener registros de los pods, adjuntarse (a través de kubectl) a los pods en ejecución y utilizar la funcionalidad de reenvío de puertos del kubelet. Estas conexiones terminan en el punto final HTTPS del kubelet. Por defecto, el apiserver no verifica el certificado de servicio del kubelet, lo que hace que la conexión esté sujeta a ataques de intermediarios y sea insegura para ejecutarse en redes no confiables y/o públicas.

El servidor API se puede configurar para permitir todas las solicitudes. Este modo no debe utilizarse en ningún clúster de producción.

El modo de autorización de nodo solo permite a los kubelets leer objetos Secret, ConfigMap, PersistentVolume y PersistentVolumeClaim asociados con sus nodos.

El control de acceso basado en funciones (RBAC) permite un control detallado sobre las operaciones que diferentes entidades pueden realizar en diferentes objetos en el clúster. Se recomienda utilizar el modo de autorización RBAC.

Usar EventRateLimit el control de admisión impone un límite en el número de eventos que el servidor API aceptará en un determinado quantum. Una carga de trabajo que se comporta mal podría abrumar y causar un DoS al servidor API, haciéndolo inaccesible. Esto se aplica especialmente a un clúster multi-inquilino, donde podría haber un pequeño porcentaje de inquilinos problemáticos que podrían tener un impacto significativo en el rendimiento general del clúster. Por lo tanto, se recomienda limitar la tasa de eventos que el servidor API aceptará.

Configurar el complemento de control de admisión AlwaysAdmit permite todas las solicitudes y no filtra ninguna solicitud.

El controlador de admisión AlwaysAdmit quedó obsoleto en Kubernetes v1.13. Su comportamiento era equivalente a desactivar todos los controladores de admisión.

Configurar la directiva de control de admisión a AlwaysPullImages obliga a cada nuevo pod a extraer las imágenes requeridas cada vez. En un clúster multi-inquilino, los usuarios pueden estar seguros de que sus imágenes privadas solo pueden ser utilizadas por aquellos que tienen las credenciales para extraerlas. Sin esta política de control de admisión, una vez que una imagen ha sido extraída a un nodo, cualquier pod de cualquier usuario puede usarla simplemente conociendo el nombre de la imagen, sin ninguna verificación de autorización contra la propiedad de la imagen. Cuando este complemento está habilitado, las imágenes siempre se extraen antes de iniciar los contenedores, lo que significa que se requieren credenciales válidas.

SecurityContextDeny se puede utilizar para proporcionar una capa de seguridad para los clústeres que no tienen habilitadas las PodSecurityPolicies.

Cuando creas un pod, si no especificas una cuenta de servicio, se le asigna automáticamente la cuenta de servicio default en el mismo espacio de nombres. Deberías crear tu propia cuenta de servicio y dejar que el servidor API gestione sus tokens de seguridad.

Configurar la directiva de control de admisión a NamespaceLifecycle asegura que no se puedan crear objetos en espacios de nombres inexistentes, y que los espacios de nombres en proceso de terminación no se utilicen para crear nuevos objetos. Esto se recomienda para hacer cumplir la integridad del proceso de terminación del espacio de nombres y también para la disponibilidad de los nuevos objetos.

Utilizar el complemento NodeRestriction asegura que el kubelet esté restringido a los objetos Node y Pod que podría modificar según lo definido. Dichos kubelets solo podrán modificar su propio objeto API de Nodo y solo modificar objetos API de Pod que estén vinculados a su nodo.

El puerto seguro se utiliza para servir https con autenticación y autorización. Si lo desactivas, no se sirve tráfico https y todo el tráfico se sirve sin cifrar.

El perfilado permite la identificación de cuellos de botella específicos en el rendimiento. Genera una cantidad significativa de datos del programa que podrían ser explotados para descubrir detalles del sistema y del programa. Si no estás experimentando cuellos de botella y no necesitas el perfilador para fines de resolución de problemas, se recomienda desactivarlo para reducir la superficie de ataque potencial.

La auditoría del servidor API de Kubernetes proporciona un conjunto cronológico de registros relevantes para la seguridad que documentan la secuencia de actividades que han afectado al sistema por parte de usuarios individuales, administradores u otros componentes del sistema. Aunque actualmente, Kubernetes solo proporciona capacidades de auditoría básicas, debería estar habilitado. Puedes habilitarlo configurando una ruta de registro de auditoría adecuada.

Retener registros durante al menos 30 días asegura que puedas retroceder en el tiempo e investigar o correlacionar cualquier evento. Establece tu período de retención de registros de auditoría en 30 días o según los requisitos de tu negocio.

Kubernetes rota automáticamente los archivos de registro. Retener archivos de registro antiguos asegura que tendrás suficientes datos de registro disponibles para llevar a cabo cualquier investigación o correlación. Por ejemplo, si has establecido un tamaño de archivo de 100 MB y el número de archivos de registro antiguos a conservar como 10, tendrías aproximadamente 1 GB de datos de registro que podrías utilizar para tu análisis.

Kubernetes rota automáticamente los archivos de registro. Retener archivos de registro antiguos asegura que tendrás suficientes datos de registro disponibles para llevar a cabo cualquier investigación o correlación. Si has establecido un tamaño de archivo de 100 MB y el número de archivos de registro antiguos a conservar como 10, tendrías aproximadamente 1 GB de datos de registro que podrías utilizar para tu análisis.

Establecer un tiempo de espera global para las solicitudes permite extender el límite de tiempo de espera de las solicitudes del servidor API a una duración adecuada para la velocidad de conexión del usuario. Por defecto, está configurado en 60 segundos, lo que puede ser problemático en conexiones más lentas, haciendo que los recursos del clúster sean inaccesibles una vez que el volumen de datos para las solicitudes excede lo que se puede transmitir en 60 segundos. Sin embargo, establecer este límite de tiempo demasiado alto puede agotar los recursos del servidor API, haciéndolo propenso a ataques de Denegación de Servicio. Por lo tanto, se recomienda establecer este límite según sea apropiado y cambiar el límite predeterminado de 60 segundos solo si es necesario.

Si --service-account-lookup no está habilitado, el apiserver solo verifica que el testigo de autenticación sea válido y no valida que el token de cuenta de servicio mencionado en la solicitud esté realmente presente en etcd. Esto permite usar un token de cuenta de servicio incluso después de que la cuenta de servicio correspondiente haya sido eliminada. Este es un ejemplo de un problema de seguridad de tiempo de verificación a tiempo de uso.

Por defecto, si no se especifica ningún --service-account-key-file al apiserver, utiliza la clave privada del certificado TLS de servicio para verificar los tokens de cuenta de servicio. Para asegurar que las claves para los tokens de cuenta de servicio puedan ser rotadas según sea necesario, se debe usar un par de claves pública/privada separado para firmar los tokens de cuenta de servicio. Por lo tanto, la clave pública debe ser especificada al apiserver con --service-account-key-file.

etcd es un almacén de valores clave altamente disponible utilizado por los despliegues de Kubernetes para el almacenamiento persistente de todos sus objetos de API REST. Estos objetos son sensibles por naturaleza y deben ser protegidos mediante autenticación de cliente. Esto requiere que el servidor API se identifique ante el servidor etcd utilizando un certificado y una clave de cliente.

La comunicación del servidor API contiene parámetros sensibles que deben permanecer cifrados durante la transmisión. Configura el servidor API para que solo sirva tráfico HTTPS.

La comunicación del servidor API contiene parámetros sensibles que deben permanecer cifrados durante la transmisión. Configura el servidor API para que solo sirva tráfico HTTPS. Si el argumento --client-ca-file está configurado, cualquier solicitud que presente un certificado de cliente firmado por una de las autoridades en el client-ca-file se autentica con una identidad correspondiente al CommonName del certificado de cliente.

etcd es un almacén de valores clave altamente disponible utilizado por los despliegues de Kubernetes para el almacenamiento persistente de todos sus objetos de la API REST. Estos objetos son sensibles por naturaleza y deben ser protegidos mediante autenticación de cliente. Esto requiere que el servidor API se identifique ante el servidor etcd utilizando un archivo de autoridad de certificado SSL.

etcd es un almacén de clave-valor altamente disponible utilizado por las implementaciones de Kubernetes para el almacenamiento persistente de todos sus objetos de API REST. Estos objetos son sensibles por naturaleza y deben estar cifrados en reposo para evitar cualquier divulgación.

Donde se utiliza el cifrado etcd, es importante asegurarse de que se utilice el conjunto apropiado de proveedores de cifrado. Actualmente, el aescbc, kms y secretbox son opciones que probablemente sean adecuadas.

Los cifrados TLS han tenido una serie de vulnerabilidades y debilidades conocidas, que pueden reducir la protección que proporcionan. Por defecto, Kubernetes soporta una serie de suites de cifrado TLS, incluyendo algunas que tienen preocupaciones de seguridad, debilitando la protección proporcionada.

La recolección de basura es importante para asegurar la disponibilidad suficiente de recursos y evitar un rendimiento y disponibilidad degradados. En el peor de los casos, el sistema podría fallar o simplemente ser inutilizable durante un largo período de tiempo. La configuración actual para la recolección de basura es de 12.500 pods terminados, lo que podría ser demasiado alto para que tu sistema lo mantenga. Basado en los recursos de tu sistema y pruebas, elige un valor de umbral apropiado para activar la recolección de basura.

El perfil permite la identificación de cuellos de botella específicos en el rendimiento. Genera una cantidad significativa de datos del programa que podrían ser explotados para descubrir detalles del sistema y del programa. Si no estás experimentando cuellos de botella y no necesitas el perfil para solucionar problemas, se recomienda desactivarlo para reducir la superficie de ataque potencial.

El administrador de controladores crea una cuenta de servicio por controlador en el espacio de nombres kube-system, genera una credencial para ella y construye un cliente API dedicado con esa credencial de cuenta de servicio para que lo utilice cada bucle de controlador. Configurar el --use-service-account-credentials a true ejecuta cada bucle de control dentro del administrador de controladores utilizando una credencial de cuenta de servicio separada. Cuando se utiliza en combinación con RBAC, esto asegura que los bucles de control se ejecuten con los permisos mínimos necesarios para realizar sus tareas previstas.

Para asegurar que las claves para los tokens de cuentas de servicio puedan ser rotadas según sea necesario, se debe utilizar un par de claves pública/privada separado para firmar los tokens de cuentas de servicio. La clave privada debe ser especificada al administrador del controlador con --service-account-private-key-file según corresponda.

Los procesos que se ejecutan dentro de los pods que necesitan contactar con el servidor API deben verificar el certificado del servidor API. No hacerlo podría ser objeto de ataques de intermediario.

Proporcionar el certificado raíz para el certificado de servicio del servidor API al administrador del controlador con el argumento --root-ca-file permite al administrador del controlador inyectar el paquete de confianza en los pods para que puedan verificar las conexiones TLS al servidor API.

RotateKubeletServerCertificate hace que el kubelet solicite un certificado de servicio después de inicializar sus credenciales de cliente y rote el certificado a medida que sus credenciales existentes expiran. Esta rotación periódica automatizada asegura que no haya tiempo de inactividad debido a certificados expirados y, por lo tanto, aborda la disponibilidad en el triángulo de seguridad CIA.

El servicio de la API del Controlador Manager, que se ejecuta por defecto en el puerto 10252/TCP, se utiliza para información de salud y métricas y está disponible sin autenticación ni cifrado. Por lo tanto, solo debe estar vinculado a una interfaz de host local, para minimizar la superficie de ataque del clúster.

El perfilado permite la identificación de cuellos de botella específicos en el rendimiento. Genera una cantidad significativa de datos del programa que podrían ser explotados para descubrir detalles del sistema y del programa. Si no estás experimentando cuellos de botella y no necesitas el perfilador para fines de resolución de problemas, se recomienda desactivarlo para reducir la superficie de ataque potencial.

El servicio de la API del Scheduler, que se ejecuta por defecto en el puerto 10251/TCP, se utiliza para información de salud y métricas y está disponible sin autenticación ni cifrado. Por lo tanto, solo debe estar vinculado a una interfaz de host local, para minimizar la superficie de ataque del clúster.

Con cualquier mecanismo de autenticación, la capacidad de revocar credenciales si se ven comprometidas o ya no son necesarias es un control clave. La autenticación con certificado de cliente de Kubernetes no permite esto debido a la falta de soporte para la revocación de certificados.

El registro es un control de detección importante para todos los sistemas, para detectar accesos no autorizados potenciales.

Los registros de auditoría de seguridad deben cubrir el acceso y la modificación de recursos clave en el clúster, para permitir que formen una parte efectiva de un entorno de seguridad.

El archivo de servicio kubelet controla varios parámetros que establecen el comportamiento del servicio kubelet en el nodo trabajador. Debes restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser escribible solo por los administradores del sistema.

El archivo de servicio kubelet controla varios parámetros que establecen el comportamiento del servicio kubelet en el nodo trabajador. Debes establecer su propiedad de archivo para mantener la integridad del archivo. El archivo debe ser propiedad de root:root.

El archivo kubeconfig kube-proxy controla varios parámetros del servicio kube-proxy en el nodo trabajador. Debes restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser escribible solo por los administradores del sistema.

Es posible ejecutar kube-proxy con los parámetros kubeconfig configurados como un ConfigMap de Kubernetes en lugar de un archivo. En este caso, no hay archivo kubeconfig del proxy.

El archivo kubeconfig para kube-proxy controla varios parámetros para el servicio kube-proxy en el nodo trabajador. Debes establecer su propiedad de archivo para mantener la integridad del archivo. El archivo debe ser propiedad de root:root.

El archivo kubelet.conf es el archivo kubeconfig para el nodo y controla varios parámetros que establecen el comportamiento y la identidad del nodo trabajador. Debes restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser escribible solo por los administradores del sistema.

El archivo kubelet.conf es el archivo kubeconfig para el nodo y controla varios parámetros que establecen el comportamiento y la identidad del nodo trabajador. Debes establecer su propiedad de archivo para mantener la integridad del archivo. El archivo debe ser propiedad de root:root.

El archivo de autoridades de certificación controla las autoridades utilizadas para validar las solicitudes de API. Debes restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser escribible solo por los administradores del sistema.

El archivo de autoridades de certificación controla las autoridades utilizadas para validar las solicitudes de API. Debes establecer su propiedad de archivo para mantener la integridad del archivo. El archivo debe ser propiedad de root:root.

El kubelet lee varios parámetros, incluyendo configuraciones de seguridad, de un archivo de configuración especificado por el argumento --config. Si este archivo está especificado, deberías restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser escribible solo por los administradores del sistema.

El kubelet lee varios parámetros, incluyendo configuraciones de seguridad, de un archivo de configuración especificado por el argumento --config. Si este archivo está especificado, deberías restringir sus permisos de archivo para mantener la integridad del archivo. El archivo debe ser propiedad de root:root.

Cuando está habilitado, las solicitudes que no son rechazadas por otros métodos de autenticación configurados se tratan como solicitudes anónimas. Estas solicitudes son atendidas por el servidor Kubelet. Debes confiar en la autenticación para autorizar el acceso y deshabilitar las solicitudes anónimas.

Los kubelets, por defecto, permiten todas las solicitudes autenticadas (incluso las anónimas) sin necesidad de comprobaciones de autorización explícitas por parte del apiserver. Debes restringir este comportamiento y solo permitir solicitudes explícitamente autorizadas.

Las conexiones del apiserver al kubelet se utilizan para obtener registros de los pods, adjuntarse (a través de kubectl) a los pods en ejecución y utilizar la funcionalidad de reenvío de puertos del kubelet. Estas conexiones terminan en el punto final HTTPS del kubelet. Por defecto, el apiserver no verifica el certificado de servicio del kubelet, lo que hace que la conexión esté sujeta a ataques de intermediarios y sea insegura para ejecutarse en redes no confiables y/o públicas. Habilitar la autenticación de certificados del Kubelet asegura que el apiserver pueda autenticar el Kubelet antes de enviar cualquier solicitud.

El proceso Kubelet proporciona una API de solo lectura además de la API principal de Kubelet. Se proporciona acceso no autenticado a esta API de solo lectura, que podría recuperar información potencialmente sensible sobre el clúster.

Configurar los tiempos de espera inactivos asegura que estés protegido contra ataques de Denegación de Servicio, conexiones inactivas y la falta de puertos efímeros.

Los parámetros del núcleo de Linux suelen ser ajustados y endurecidos por los administradores del sistema antes de poner los sistemas en producción. Estos parámetros protegen el núcleo de Linux y el sistema. Los valores predeterminados de tu núcleo de Linux kubelet que dependen de tales parámetros deben estar configurados adecuadamente para coincidir con el estado del sistema seguro deseado. Ignorar esto podría llevar potencialmente a ejecutar pods con un comportamiento del núcleo de Linux no deseado.

Los kubelets pueden gestionar automáticamente los cambios requeridos en el paquete de tablas IP según cómo elijas tus opciones de red para los pods. Se recomienda dejar que los kubelets gestionen los cambios en iptables. Esto asegura que la configuración del paquete de tablas IP permanezca sincronizada con la configuración de red de los pods. Configurar manualmente el paquete de tablas IP con cambios dinámicos en la configuración de red de los pods podría obstaculizar la comunicación entre pods/contenedores y el mundo exterior. Es posible que tengas reglas del paquete de tablas IP demasiado restrictivas o demasiado abiertas.

Sobrescribir nombres de host podría romper potencialmente la configuración de TLS entre el kubelet y el apiserver. Además, con nombres de host sobrescritos, se vuelve cada vez más difícil asociar registros con un nodo particular y procesarlos para análisis de seguridad. Por lo tanto, deberías configurar tus nodos kubelet con FQDNs resolubles y evitar sobrescribir los nombres de host con IPs.

Es importante capturar todos los eventos y no restringir la creación de eventos. Los eventos son una fuente importante de información y análisis de seguridad que aseguran que tu entorno esté monitorizado de manera consistente utilizando los datos de eventos.

La comunicación del Kubelet contiene parámetros sensibles que deben permanecer cifrados en tránsito. Configura los Kubelets para servir solo tráfico HTTPS.

La configuración --rotate-certificates provoca que el kubelet rote sus certificados de cliente creando nuevas CSR a medida que sus credenciales existentes expiran. Esta rotación periódica automatizada asegura que no haya tiempo de inactividad debido a certificados expirados y, por lo tanto, aborda la disponibilidad en el triángulo de seguridad CIA.

RotateKubeletServerCertificate provoca que el kubelet solicite un certificado de servicio después de inicializar sus credenciales de cliente y rote el certificado a medida que sus credenciales existentes expiran. Esta rotación periódica automatizada asegura que no haya tiempos de inactividad debido a certificados expirados y, por lo tanto, aborda la disponibilidad en el triángulo de seguridad CIA.

Los cifrados TLS han tenido una serie de vulnerabilidades y debilidades conocidas, que pueden reducir la protección que proporcionan. Por defecto, Kubernetes admite una serie de suites de cifrado TLS, incluyendo algunas que presentan problemas de seguridad, debilitando la protección proporcionada.

Kubernetes proporciona un conjunto de roles predeterminados donde se utiliza RBAC. Algunos de estos roles, como cluster-admin, proporcionan privilegios amplios que solo deben aplicarse donde sea absolutamente necesario. Roles como cluster-admin permiten acceso de superusuario para realizar cualquier acción sobre cualquier recurso. Cuando se utiliza en un ClusterRoleBinding, otorga control total sobre cada recurso en el clúster y en todos los espacios de nombres. Cuando se utiliza en un RoleBinding, otorga el control total sobre cada recurso en el espacio de nombres del rolebinding, incluido el propio espacio de nombres.

El acceso inapropiado a secretos almacenados dentro del clúster de Kubernetes puede permitir que un atacante obtenga acceso adicional al clúster de Kubernetes o a recursos externos cuyas credenciales están almacenadas como secretos.

El principio de menor privilegio recomienda que a los usuarios se les proporcione solo el acceso requerido para su rol y nada más. El uso de derechos de comodín probablemente otorgue derechos excesivos a la API de Kubernetes.

La capacidad de crear pods en un clúster abre posibilidades para la escalada de privilegios y debe ser restringida, cuando sea posible.

Kubernetes proporciona una cuenta de servicio predeterminada que es utilizada por las cargas de trabajo del clúster donde no se asigna ninguna cuenta de servicio específica al pod.

Donde se requiera acceso a la API de Kubernetes desde un pod, se debe crear una cuenta de servicio específica para ese pod y otorgar derechos a esa cuenta de servicio.

La cuenta de servicio predeterminada debe configurarse de tal manera que no proporcione un token de cuenta de servicio y no tenga ninguna asignación de derechos explícita.

Montar tokens de cuenta de servicio dentro de los pods puede proporcionar una vía para ataques de escalada de privilegios donde un atacante puede comprometer un solo pod en el clúster.

Evitar montar estos tokens elimina esta vía de ataque.

El grupo system:masters tiene acceso sin restricciones a la API de Kubernetes codificado en el código fuente del servidor API. Un usuario autenticado que sea miembro de este grupo no puede ver reducida su acceso, incluso si se eliminan todos los enlaces y enlaces de roles de clúster que lo mencionan.

Cuando se combina con la autenticación de certificado de cliente, el uso de este grupo puede permitir que existan credenciales de nivel de administrador de clúster irrevocables para un clúster.

El privilegio de suplantación permite a un sujeto suplantar a otros usuarios ganando sus derechos en el clúster. El privilegio de enlace permite al sujeto agregar un enlace a un rol de clúster o rol que aumenta sus permisos efectivos en el clúster. El privilegio de escalada permite a un sujeto modificar los roles de clúster a los que está vinculado, aumentando sus derechos a ese nivel.

Sin un mecanismo de control de directivas activo, no es posible limitar el uso de contenedores con acceso a los nodos subyacentes del clúster, a través de mecanismos como contenedores privilegiados, o el uso de montajes de volúmenes hostPath.

Un contenedor que se ejecuta en el espacio de nombres PID del host puede inspeccionar procesos que se ejecutan fuera del contenedor. Si el contenedor también tiene acceso a capacidades de ptrace, esto puede ser utilizado para escalar privilegios fuera del contenedor.

Debería haber al menos una PodSecurityPolicy (PSP) definida que no permita a los contenedores compartir el espacio de nombres PID del host.

Si necesita ejecutar contenedores que requieran hostPID, esto debería definirse en una PSP separada y debería comprobar cuidadosamente los controles de RBAC para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para acceder a esa PSP.

Un contenedor que se ejecuta en el espacio de nombres PID del host puede inspeccionar procesos que se ejecutan fuera del contenedor. Si el contenedor también tiene acceso a capacidades de ptrace, esto puede ser utilizado para escalar privilegios fuera del contenedor.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores compartir el espacio de nombres PID del host.

Si necesita ejecutar contenedores que requieran hostPID, esto debería definirse en una directiva separada y debería comprobar cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Un contenedor que se ejecuta en el espacio de nombres IPC del host puede utilizar IPC para interactuar con procesos fuera del contenedor.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores compartir el espacio de nombres IPC del host.

Si necesita ejecutar contenedores que requieran hostIPC, esto debería definirse en una directiva separada y debería comprobar cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Un contenedor que se ejecuta en el espacio de nombres de red del host podría acceder al dispositivo de bucle local y podría acceder al tráfico de red hacia y desde otros pods.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores compartir el espacio de nombres de red del host.

Si necesita ejecutar contenedores que requieran acceso a los espacios de nombres de red del host, esto debería definirse en una directiva separada y debería comprobar cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Un contenedor que se ejecuta con la bandera allowPrivilegeEscalation configurada en verdadero puede tener procesos que pueden obtener más privilegios que su padre.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores permitir la escalada de privilegios. Existe la opción (y está configurada por defecto en verdadero) de permitir que se ejecuten binarios setuid.

Si necesita ejecutar contenedores que utilicen binarios setuid o requieran escalada de privilegios, esto debería definirse en una directiva separada y debería comprobarse cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para usar esa directiva.

Los contenedores pueden ejecutarse como cualquier usuario de Linux. Los contenedores que se ejecutan como el usuario raíz, aunque estén restringidos por las características de seguridad del entorno de ejecución de contenedor, aún tienen una mayor probabilidad de fuga de contenedores.

Idealmente, todos los contenedores deberían ejecutarse como un usuario definido que no sea UID 0.

Debería haber al menos una directiva de control de admisión definida que no permita contenedores raíz.

Si necesita ejecutar contenedores raíz, esto debería definirse en una directiva separada y debería comprobarse cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para usar esa directiva.

Los contenedores se ejecutan con un conjunto de capacidades predeterminado asignado por el entorno de ejecución de contenedor. Por defecto, esto puede incluir capacidades potencialmente peligrosas. Con Docker como el entorno de ejecución de contenedor, la capacidad NET_RAW está habilitada, lo que puede ser mal utilizado por contenedores maliciosos.

Idealmente, todos los contenedores deberían eliminar esta capacidad.

Debería haber al menos una directiva de control de admisión definida que no permita contenedores con la capacidad NET_RAW.

Si necesita ejecutar contenedores con esta capacidad, esto debería definirse en una directiva separada y debería comprobarse cuidadosamente para asegurarse de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para usar esa directiva.

Los contenedores se ejecutan con un conjunto de capacidades predeterminado asignado por el entorno de ejecución de contenedor. Las capacidades fuera de este conjunto pueden añadirse a los contenedores, lo que podría exponerles a riesgos de ataques de escape de contenedores.

Debería definirse al menos una directiva que impida que los contenedores con capacidades más allá del conjunto predeterminado se inicien.

Si necesitas ejecutar contenedores con capacidades adicionales, esto debería definirse en una directiva separada y deberías comprobar cuidadosamente para asegurarte de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Los contenedores se ejecutan con un conjunto de capacidades predeterminado asignado por el entorno de ejecución de contenedor. Las capacidades son partes de los derechos generalmente otorgados en un sistema Linux al raíz.

En muchos casos, las aplicaciones que se ejecutan en contenedores no requieren ninguna capacidad para operar, por lo que desde la perspectiva del principio de menor privilegio, el uso de capacidades debería minimizarse.

Los contenedores se ejecutan con un conjunto de capacidades predeterminado asignado por el entorno de ejecución de contenedor. Las capacidades son partes de los derechos generalmente otorgados en un sistema Linux al raíz.

En muchos casos, las aplicaciones que se ejecutan en contenedores no requieren ninguna capacidad para operar, por lo que desde la perspectiva del principio de menor privilegio, el uso de capacidades debería minimizarse.

Un contenedor que monta un volumen hostPath como parte de su especificación tendrá acceso al sistema de archivos del nodo del clúster subyacente. El uso de volúmenes hostPath puede permitir a los contenedores acceder a áreas privilegiadas del sistema de archivos del nodo.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores montar volúmenes hostPath.

Si necesitas ejecutar contenedores que requieren volúmenes hostPath, esto debería definirse en una directiva separada y deberías comprobar cuidadosamente para asegurarte de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Los puertos de host conectan contenedores directamente a la red del host. Esto puede eludir controles como la política de red.

Debería haber al menos una directiva de control de admisión definida que no permita a los contenedores que requieren el uso de HostPorts.

Si necesitas ejecutar contenedores que requieren HostPorts, esto debería definirse en una directiva separada y deberías comprobar cuidadosamente para asegurarte de que solo se otorgue permiso a cuentas de servicio y usuarios limitados para utilizar esa directiva.

Las políticas de red de Kubernetes son aplicadas por el complemento CNI en uso. Por lo tanto, es importante asegurarse de que el complemento CNI soporte tanto políticas de red de entrada como de salida.

Ejecutar diferentes aplicaciones en el mismo clúster de Kubernetes crea un riesgo de que una aplicación comprometida ataque a una aplicación vecina. La segmentación de red es importante para asegurar que los contenedores solo puedan comunicarse con aquellos con los que se supone que deben hacerlo. Una política de red es una especificación de cómo se permite que selecciones de pods se comuniquen entre sí y con otros puntos finales de red.

Las Políticas de Red están limitadas al espacio de nombres. Cuando se introduce una política de red en un espacio de nombres dado, todo el tráfico no permitido por la política es denegado. Sin embargo, si no hay políticas de red en un espacio de nombres, todo el tráfico será permitido dentro y fuera de los pods en ese espacio de nombres.

Es bastante común que el código de la aplicación registre su entorno (particularmente en caso de error). Esto incluirá cualquier valor secreto pasado como variables de entorno, por lo que los secretos pueden ser fácilmente expuestos a cualquier usuario o entidad que tenga acceso a los registros.

Kubernetes admite secretos como objetos de primera clase, pero se debe tener cuidado para garantizar que el acceso a los secretos esté cuidadosamente limitado. Utilizar un proveedor de secretos externo puede facilitar la gestión del acceso a los secretos, especialmente cuando los secretos se utilizan tanto en entornos de Kubernetes como en entornos no Kubernetes.

Kubernetes admite la integración de reglas de procedencia para aceptar o rechazar las imágenes en tus despliegues. Podrías configurar tales reglas para garantizar que solo se desplieguen imágenes aprobadas en el clúster.

Limitar el alcance de los permisos de usuario puede reducir el impacto de errores o actividades maliciosas. Un espacio de nombres de Kubernetes te permite particionar los recursos creados en grupos lógicamente nombrados. Los recursos creados en un espacio de nombres pueden estar ocultos de otros espacios de nombres. Por defecto, cada recurso creado por un usuario en el clúster de Kubernetes se ejecuta en un espacio de nombres por defecto, llamado default. Puedes crear espacios de nombres adicionales y adjuntar recursos y usuarios a ellos. Puedes utilizar los complementos de autorización de Kubernetes para crear políticas que segreguen el acceso a los recursos de los espacios de nombres entre diferentes usuarios.

Seccomp (modo de computación segura) se utiliza para restringir el conjunto de llamadas al sistema que las aplicaciones pueden realizar, permitiendo a los administradores del clúster un mayor control sobre la seguridad de las cargas de trabajo que se ejecutan en el clúster. Kubernetes desactiva los perfiles seccomp por defecto por razones históricas. Debes habilitarlo para asegurar que las cargas de trabajo tengan acciones restringidas disponibles dentro del contenedor.

Un contexto de seguridad define los ajustes de seguridad del sistema operativo (uid, gid, capacidades, rol de SELinux, etc.) aplicados a un contenedor. Al diseñar vuestros contenedores y pods, aseguraos de que configuráis el contexto de seguridad para vuestros pods, contenedores y volúmenes. Un contexto de seguridad es una propiedad definida en el archivo yaml de despliegue. Controla los parámetros de seguridad que se asignarán al pod/contenedor/volumen. Hay dos niveles de contexto de seguridad: contexto de seguridad a nivel de pod y contexto de seguridad a nivel de contenedor.

Los recursos en un clúster de Kubernetes deben estar segregados por espacio de nombres, para permitir que se apliquen controles de seguridad a ese nivel y facilitar la gestión de recursos.