Introducción
Las herramientas de orquestación como Kubernetes introdujeron niveles sin precedentes de resiliencia y versatilidad para la implementación y administración de software. También pusieron de relieve las deficiencias del panorama de seguridad actual.
La arquitectura dispersa de Kubernetes nos proporciona varias capas adicionales. Podemos usarlos para mejorar y desarrollar configuraciones de seguridad existentes. Si configura estas capas correctamente, pueden aislar cualquier amenaza de seguridad antes de que estalle desde su punto de origen.
Este artículo se centra en las medidas que puede tomar para mejorar la seguridad general de su clúster de Kubernetes.
1. Habilitar el control de acceso basado en roles (RBAC)
La complejidad de un sistema que se ejecuta en varios dispositivos, con muchos microservicios interconectados administrados por cientos de personas y servicios públicos es una pesadilla logística.
Ejercer un estricto control sobre los permisos otorgados a los usuarios. Kubernetes es un defensor del control de acceso basado en roles (RBAC) método. El método de control de acceso basado en roles significa que ningún usuario tiene más permisos de los que necesita para cumplir sus tareas con eficacia. Kubernetes tiene que ver con la automatización, y RBAC utiliza un grupo de API para impulsar las decisiones de autorización a través de la API de Kubernetes.
A partir de la versión 1.8 de Kubernetes, el modo RBAC es estable y está respaldado por la API rbac.authorization.k8s.io/v1. Habilite RBAC iniciando el servidor API con el siguiente comando:
--authorization-mode=RBACKubernetes tiene un conjunto de funciones predefinidas tanto para usuarios humanos como para componentes, como aplicaciones, controladores y nodos. Estos roles predefinidos son numerosos y ofrecen un nivel predeterminado razonable de roles separados para las tareas más comunes.
2. Mantén tus secretos en secreto
En Kubernetes, un secreto es un objeto pequeño que contiene datos confidenciales, como una contraseña o un token.
Aunque un pod no puede acceder a los secretos de otro pod, es crucial mantener el secreto separado de una imagen o pod. De lo contrario, cualquier persona con acceso a la imagen también tendría acceso al secreto. Las aplicaciones complejas que manejan múltiples procesos y tienen acceso público son especialmente vulnerables en este sentido.
Asignar Procesos a Diferentes Contenedores
Cada contenedor en un pod debe solicitar el volumen secreto en su volumen. Reduzca el riesgo de que se expongan los secretos dividiendo los procesos en contenedores separados. Use un contenedor front-end que interactúe con los usuarios pero no pueda ver la clave privada.
Complemente ese contenedor con un contenedor de firmantes que pueda ver la clave privada y responder a solicitudes de firmas simples desde el front-end. Este enfoque particionado obliga a un atacante a realizar un conjunto de acciones complejas en un intento de violar sus medidas de seguridad.
3. Restrinja el tráfico de pod a pod con una política de red de Kubernetes
Es una práctica recomendada de seguridad de Kubernetes para imponer el protocolo de seguridad TLS en cada nivel de la canalización de implementación de la aplicación. Sin embargo, también es imperativo proteger los elementos individuales que componen el clúster y los elementos que controlan el acceso al clúster.
Los pods aceptan tráfico de cualquier fuente de forma predeterminada. Cuando define políticas de red , establece reglas específicas sobre cómo se comunican los pods dentro de un clúster y con recursos externos.
Las políticas de red no entran en conflicto, sino que se suman. Definir una política de red en un espacio de nombres significa que el pod rechazará cualquier conexión no permitida por esa política, aislando efectivamente el pod. El pod está limitado a lo que está aprobado por la combinación de varias políticas de red.
4. Mejorar la seguridad de los pods
Asegurar el Kernel con AppArmor o SELinux
Los contenedores comparten el mismo kernel, por lo que es necesario utilizar herramientas adicionales para mejorar el aislamiento de los contenedores. Módulos de seguridad, como AppArmor y sistemas que aplican políticas de control de acceso como SELinux , confinar los programas de usuario y los servicios del sistema. También se utilizan para denegar el acceso a archivos y limitar los recursos de la red.
App Armor limita el conjunto de recursos disponibles para un contenedor dentro del sistema. Cada perfil puede ejecutarse en ejecutar modo, que bloquea el acceso a los recursos no permitidos o quejarse modo que solo informa de infracciones. Un informe oportuno de posibles problemas mejora significativamente las capacidades de registro y auditoría de sus sistemas.
SELinux gestiona la asignación de recursos independientemente del ACM general de Linux (Mecanismo de control de acceso). No reconoce un superusuario (raíz) y no depende de los binarios setuid/setgid.
La seguridad de un sistema sin SELinux se basa en la configuración adecuada de las aplicaciones privilegiadas y el kernel mismo. Una mala configuración en estas áreas puede comprometer todo el sistema. La seguridad de un sistema basado en un kernel SELinux depende de la corrección del kernel y de su configuración de política de seguridad.
Los ataques siguen representando una amenaza significativa. Sin embargo, con SELinux, los programas de usuario individuales y los demonios del sistema no necesariamente tienen que poner en peligro la seguridad de todo el sistema.
Corrupciones y tolerancias
Kubernetes brinda la opción de crear reglas predefinidas cuando el sistema asigna nuevos pods a los nodos.
Como herramienta de orquestación, Kubernetes tiende a iniciar pods en la ubicación más eficiente del clúster, es decir, la ubicación con la menor carga de trabajo. Es posible modificar la ubicación de los pods definiendo Manchas y Toleraciones.
Las contaminaciones permiten que los nodos "rechacen" un pod o un conjunto de pods según las reglas predefinidas. Por otro lado, las tolerancias se aplican a nivel de pod y permiten que los pods se programen en nodos con Tants coincidentes (las claves y los efectos son los mismos).
Las contaminaciones y las tolerancias se deben usar en conjunto para asegurarse de que los pods no se programen en nodos inapropiados.
Espacios de nombres
Kubernetes no tiene un mecanismo que proporcione seguridad en los espacios de nombres. Limite el uso de espacios de nombres, como función de seguridad, dentro de dominios de confianza y para fines internos. No utilice espacios de nombres cuando desee denegar a un usuario del clúster de Kubernetes el acceso a cualquiera de los recursos de los otros espacios de nombres.
El watch y list Las solicitudes permiten a los clientes inspeccionar los valores de todos los secretos que se encuentran en ese espacio de nombres. Solo los componentes de nivel de sistema más privilegiados deben tener permiso para implementar estas solicitudes.
5. Actualizaciones continuas de Kubernetes
Se ha vuelto imposible rastrear todos los posibles vectores de ataque. Este hecho es desafortunado ya que no hay nada más vital que estar al tanto de las posibles amenazas. La mejor defensa es asegurarse de que está ejecutando la última versión disponible de Kubernetes.
Existen varias técnicas, como actualizaciones continuas y migraciones de grupos de nodos, que le permiten completar una actualización con interrupciones y tiempos de inactividad mínimos.
6. Definir políticas de auditoría
El registro de auditoría registra la línea de tiempo de los eventos que ocurren en un clúster de Kubernetes. Al realizar un seguimiento de las acciones realizadas por los usuarios y la API de Kubernetes, los administradores pueden analizar la cadena de eventos que llevaron a un posible problema.
Kubernetes le permite ajustar las políticas de auditoría al definir la frecuencia con la que se registran los eventos, si se deben emitir alertas y el procedimiento para finalizar los pods afectados.
Utilice el registro de auditoría con regularidad para asegurarse de que su sistema esté actualizado y que las amenazas se mantengan bajo control. Una implementación basada en contenedores agrega otra dimensión al proceso de auditoría. Una comparación entre la imagen original y la imagen que se ejecuta en el contenedor se puede usar de manera efectiva para ver si alguna discrepancia puede generar problemas de seguridad. Asegúrese de que sus versiones de software siempre contengan los últimos parches de seguridad.