Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Pod Security
La especificación del módulo incluye una variedad de atributos diferentes que pueden reforzar o debilitar tu postura general en materia de seguridad. Como profesional de Kubernetes, tu principal preocupación debería ser evitar que un proceso que se ejecuta en un contenedor escape a los límites de aislamiento del tiempo de ejecución del contenedor y acceda al host subyacente.
Capacidades de Linux
Los procesos que se ejecutan dentro de un contenedor se ejecutan en el contexto del usuario root [de Linux] de forma predeterminada. Si bien las acciones de root dentro de un contenedor están limitadas en parte por el conjunto de capacidades de Linux que el motor de ejecución del contenedor asigna a los contenedores, estos privilegios predeterminados podrían permitir a un atacante aumentar sus privilegios u obtener acceso a información confidencial vinculada al host, incluidos los secretos y. ConfigMaps A continuación, se muestra una lista de las capacidades predeterminadas asignadas a los contenedores. Para obtener información adicional sobre cada capacidad, consulte http://man7. org/linux/man-pages/man7/capabilities.7.html
CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT
EC2 y las cápsulas Fargate tienen asignadas las capacidades antes mencionadas de forma predeterminada. Además, las capacidades de Linux solo se pueden eliminar de los pods de Fargate.
Los pods que se ejecutan con privilegios heredan todas las capacidades de Linux asociadas a la raíz en el host. Esto debe evitarse si es posible.
Autorización de nodos
Todos los nodos de trabajo de Kubernetes utilizan un modo de autorización denominado Autorización de nodos.
Operaciones de lectura:
-
servicios
-
puntos de conexión
-
nodos
-
vainas
-
secretos, mapas de configuración, notificaciones de volumen persistentes y volúmenes persistentes relacionados con los pods enlazados al nodo del kubelet
Operaciones de escritura:
-
nodos y estado de los nodos (habilite el complemento de
NodeRestrictionadmisión para limitar que un kubelet modifique su propio nodo) -
pods y estado del pod (habilite el complemento de
NodeRestrictionadmisión para limitar un kubelet y modificar los pods enlazados a sí mismo) -
eventos
Operaciones relacionadas con la autenticación:
-
Acceso de lectura y escritura a la API CertificateSigningRequest (CSR) para el arranque de TLS
-
la capacidad de crear y realizar comprobaciones delegadas TokenReview SubjectAccessReview authentication/authorization
EKS utiliza el controlador de admisión por restricciones
Soluciones de seguridad Pod
Política de seguridad de Pod (PSP)
En el pasado, los recursos de la Política de seguridad de los pods (PSP)
importante
PSPs están en desuso
Migración a una nueva solución de seguridad para módulos
Dado que PSPs se eliminaron a partir de la versión 1.25 de Kubernetes, los administradores y operadores de clústeres deben reemplazar esos controles de seguridad. Hay dos soluciones que pueden cubrir esta necesidad:
-
Policy-as-code Soluciones (PAC) del ecosistema de Kubernetes
Tanto la solución PAC como la PSS pueden coexistir con la PSP; se pueden utilizar en clústeres antes de eliminar la PSP. Esto facilita la adopción al migrar desde PSP. Consulte este documento
Kyverno, una de las soluciones de PAC que se describen a continuación, tiene una guía específica en una entrada de blog
Policy-as-code (PAC)
Policy-as-code Las soluciones (PAC) proporcionan barandillas para guiar a los usuarios del clúster y evitar comportamientos no deseados mediante controles prescritos y automatizados. El PAC utiliza los controladores de admisión dinámica de Kubernetes
Hay varias soluciones PAC de código abierto disponibles para Kubernetes. Estas soluciones no forman parte del proyecto Kubernetes; provienen del ecosistema de Kubernetes. Algunas soluciones de PAC se enumeran a continuación.
Para obtener más información sobre las soluciones de PAC y cómo ayudarlo a seleccionar la solución adecuada para sus necesidades, consulte los enlaces siguientes.
Estándares de seguridad para Pod (PSS) y Pod Security Admission (PSA)
En respuesta a la obsolescencia de la PSP y a la continua necesidad de controlar la seguridad de los módulos out-of-the-box, el Grupo de Interés Especial sobre Autenticación
Según la documentación de Kubernetes, el PSS «define tres políticas diferentes para cubrir ampliamente el espectro de la seguridad. Estas políticas son acumulativas y van desde las muy permisivas hasta las muy restrictivas. `»
Estas políticas se definen de la siguiente manera:
-
Privilegiado: política sin restricciones (insegura) que proporciona el nivel de permisos más amplio posible. Esta política permite escalamientos de privilegios conocidos. Es la ausencia de una política. Esto es bueno para aplicaciones como agentes de registro CNIs, controladores de almacenamiento y otras aplicaciones de todo el sistema que necesitan un acceso privilegiado.
-
Base de referencia: política mínimamente restrictiva que impide las escaladas de privilegios conocidas. Permite la configuración de pod predeterminada (especificada mínimamente). La política básica prohíbe el uso de HostNetwork, HostPID, HostPC, HostPath, HostPort y la imposibilidad de añadir capacidades de Linux, entre otras restricciones.
-
Restringido: política muy restringida, que sigue las mejores prácticas actuales de Pod Harding. Esta política se hereda de la base y añade restricciones adicionales, como la imposibilidad de ejecutarse como root o como grupo root. Las políticas restringidas pueden afectar a la capacidad de funcionamiento de una aplicación. Están destinadas principalmente a ejecutar aplicaciones críticas para la seguridad.
Estas políticas definen los perfiles para la ejecución
Para implementar los controles definidos por el PSS, el PSA funciona de tres modos:
-
hacer cumplir: las infracciones de la política provocarán el rechazo del módulo.
-
auditoría: las infracciones de las políticas provocarán la adición de una anotación de auditoría al evento registrado en el registro de auditoría, pero de lo contrario están permitidas.
-
advertencia: las infracciones de las políticas generarán una advertencia dirigida al usuario, pero de lo contrario están permitidas.
Estos modos y los niveles de perfil (restricción) se configuran en el nivel del espacio de nombres de Kubernetes, mediante etiquetas, como se muestra en el siguiente ejemplo.
apiVersion: v1 kind: Namespace metadata: name: policy-test labels: pod-security.kubernetes.io/enforce: restricted
Cuando se utilizan de forma independiente, estos modos operativos tienen respuestas diferentes que se traducen en experiencias de usuario diferentes. El modo de aplicación impedirá que se creen pods si los PodSpecs respectivos infringen el nivel de restricción configurado. Sin embargo, en este modo, no se impedirá que los objetos de Kubernetes que no sean pods y que creen pods, como los despliegues, se apliquen al clúster, incluso si el PodSpec incluido en ellos infringe el PSS aplicado. En este caso, se aplicará el despliegue, mientras que no se podrán aplicar los pods.
Se trata de una experiencia de usuario difícil, ya que no hay ningún indicio inmediato de que el objeto de despliegue aplicado correctamente oculte la creación fallida del pod. El PodSpecs infractor no creará pods. Al inspeccionar el recurso de despliegue con él, kubectl get deploy <DEPLOYMENT_NAME> -oyaml se mostrará el mensaje del .status.conditions elemento de los pods fallidos, tal y como se muestra a continuación.
... status: conditions: - lastTransitionTime: "2022-01-20T01:02:08Z" lastUpdateTime: "2022-01-20T01:02:08Z" message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")' reason: FailedCreate status: "True" type: ReplicaFailure ...
Tanto en el modo de auditoría como en el de advertencia, las restricciones de los pods no impiden que se creen e inicien los pods infractores. Sin embargo, en estos modos, las anotaciones de auditoría en los eventos del registro de auditoría del servidor API y las advertencias a los clientes del servidor API, como kubectl, se activan, respectivamente, cuando los pods, así como los objetos que los crean, contienen PodSpecs con infracciones. A continuación se muestra un kubectl mensaje de advertencia.
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") deployment.apps/test created
Los modos de auditoría y advertencia del PSA son útiles a la hora de introducir el PSS sin afectar negativamente a las operaciones del clúster.
Los modos operativos del PSA no se excluyen mutuamente y se pueden utilizar de forma acumulativa. Como se muestra a continuación, los múltiples modos se pueden configurar en un único espacio de nombres.
apiVersion: v1 kind: Namespace metadata: name: policy-test labels: pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/warn: restricted
En el ejemplo anterior, las advertencias y anotaciones de auditoría fáciles de usar se proporcionan al aplicar las implementaciones, mientras que la aplicación de las infracciones también se proporciona a nivel de grupo. De hecho, varias etiquetas de PSA pueden utilizar diferentes niveles de perfil, como se muestra a continuación.
apiVersion: v1 kind: Namespace metadata: name: policy-test labels: pod-security.kubernetes.io/enforce: baseline pod-security.kubernetes.io/warn: restricted
En el ejemplo anterior, el PSA está configurado para permitir la creación de todos los grupos que cumplan el nivel de perfil básico y, a continuación, avisar sobre los grupos (y los objetos que crean grupos) que infrinjan el nivel de perfil restringido. Este es un enfoque útil para determinar los posibles impactos al cambiar del perfil de referencia a uno restringido.
Cápsulas existentes
Si se modifica un espacio de nombres con los pods existentes para utilizar un perfil PSS más restrictivo, los modos de auditoría y advertencia generarán los mensajes adecuados; sin embargo, el modo de aplicación no eliminará los pods. Los mensajes de advertencia se muestran a continuación.
Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest" Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile namespace/policy-test configured
Exenciones
La PSA utiliza las exenciones para excluir la aplicación de infracciones contra grupos que, de otro modo, se habrían aplicado. Estas exenciones se enumeran a continuación.
-
Nombres de usuario: se ignoran las solicitudes de los usuarios con un nombre de usuario autenticado (o suplantado) exento.
-
RuntimeClassNames: se ignoran los pods y los recursos de carga de trabajo que especifican un nombre de clase de ejecución exento.
-
Espacios de nombres: se ignoran los pods y los recursos de carga de trabajo de un espacio de nombres exento.
Estas exenciones se aplican de forma estática en la configuración del controlador de admisión de la PSA como parte de la configuración del servidor API
En la implementación de Validating Webhook, las exenciones se pueden configurar dentro de un ConfigMap
apiVersion: v1 kind: ConfigMap metadata: name: pod-security-webhook namespace: pod-security-webhook data: podsecurityconfiguration.yaml: | apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest" audit: "restricted" audit-version: "latest" warn: "restricted" warn-version: "latest" exemptions: # Array of authenticated usernames to exempt. usernames: [] # Array of runtime class names to exempt. runtimeClasses: [] # Array of namespaces to exempt. namespaces: ["kube-system","policy-test1"]
Como se ve en el ConfigMap YAML anterior, el nivel de PSS predeterminado para todo el clúster se ha establecido como restringido para todos los modos de PSA, auditar, aplicar y advertir. Esto afecta a todos los espacios de nombres, excepto a los que están exentos:. namespaces: ["kube-system","policy-test1"] Además, en el ValidatingWebhookConfigurationrecurso, que se ve a continuación, el espacio de pod-security-webhooknombres también está exento del PSS configurado.
... webhooks: # Audit annotations will be prefixed with this name - name: "pod-security-webhook.kubernetes.io" # Fail-closed admission webhooks can present operational challenges. # You may want to consider using a failure policy of Ignore, but should # consider the security tradeoffs. failurePolicy: Fail namespaceSelector: # Exempt the webhook itself to avoid a circular dependency. matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: ["pod-security-webhook"] ...
importante
Las admisiones de Pod Security pasaron a ser estables en Kubernetes v1.25. Si querías usar la función Pod Security Admission antes de activarla de forma predeterminada, tenías que instalar el controlador de admisión dinámico (webhook mutante). Puedes encontrar las instrucciones para instalar y configurar el webhook aquí.
Elegir entre los estándares de seguridad policy-as-code y Pod
Los estándares de seguridad de Pod (PSS) se desarrollaron para sustituir a la política de seguridad de Pod (PSP), proporcionando una solución integrada en Kubernetes y que no requería soluciones del ecosistema de Kubernetes. Dicho esto, las soluciones policy-as-code (PAC) son considerablemente más flexibles.
La siguiente lista de ventajas y desventajas está diseñada para ayudarlo a tomar una decisión más informada sobre la solución de seguridad de su módulo.
Policy-as-code (en comparación con los estándares de seguridad de Pod)
Ventajas:
-
Más flexible y detallado (se reduce a los atributos de los recursos si es necesario)
-
No solo se centra en los módulos, sino que se puede utilizar con diferentes recursos y acciones
-
No solo se aplica a nivel de espacio de nombres
-
Más maduros que los estándares de seguridad de Pod
-
Las decisiones se pueden basar en cualquier elemento de la carga útil de solicitud del servidor API, así como en los recursos del clúster existentes y en los datos externos (según la solución)
-
Admite la mutación de las solicitudes del servidor de API antes de la validación (depende de la solución)
-
Puede generar políticas y recursos de Kubernetes complementarios (depende de la solución): a partir de las políticas de pod, Kyverno puede generar automáticamente
políticas para controladores de nivel superior, como las implementaciones. Kyverno también puede generar recursos adicionales de Kubernetes «`cuando se crea un nuevo recurso o cuando se actualiza la fuente`» mediante Generate Rules.) -
Se puede usar para desplazarse a la izquierda, hacia las canalizaciones del CICD, antes de realizar llamadas al servidor API de Kubernetes (depende de la solución)
-
Se puede usar para implementar comportamientos que no están necesariamente relacionados con la seguridad, como las mejores prácticas, los estándares organizacionales, etc.
-
Se puede usar en casos de uso ajenos a Kubernetes (depende de la solución)
-
Gracias a la flexibilidad, la experiencia del usuario se puede ajustar a las necesidades de los usuarios
Desventajas:
-
No está integrado en Kubernetes
-
Es más complejo de aprender, configurar y soportar
-
La creación de políticas puede requerir nuevas skills/languages/capabilities
Entrada a Pod Security (en comparación policy-as-code con)
Ventajas:
-
Integrado en Kubernetes
-
Más fácil de configurar
-
No hay nuevos idiomas que usar ni políticas que crear
-
Si el nivel de admisión predeterminado del clúster está configurado como privilegiado, las etiquetas de los espacios de nombres se pueden utilizar para incluir los espacios de nombres en los perfiles de seguridad del módulo.
Desventajas:
-
No es tan flexible o granular como policy-as-code
-
Solo 3 niveles de restricciones
-
Se centra principalmente en las cápsulas
Resumen
Si actualmente no dispones de una solución de seguridad para cápsulas, aparte de la PSP, y la postura de seguridad que necesitas para tu cápsula se ajusta al modelo definido en las normas de seguridad para cápsulas (PSS), lo más fácil sería adoptar la PSS en lugar de una solución. policy-as-code Sin embargo, si la postura de seguridad de su módulo no se ajusta al modelo de PSS, o si tiene pensado añadir controles adicionales, además de los definidos por el PSS, entonces una policy-as-code solución le parecería más adecuada.
Recomendaciones
Utilice varios modos de admisión segura (PSA) del pod para una mejor experiencia de usuario
Como se mencionó anteriormente, el modo de aplicación del PSA impide que se apliquen cápsulas con infracciones de PSS, pero no detiene a los controladores de nivel superior, como los despliegues. De hecho, la implementación se aplicará correctamente sin ningún indicio de que los pods no se hayan aplicado. Si bien puedes usar kubectl para inspeccionar el objeto de despliegue y descubrir el mensaje de error del pod en la PSA, la experiencia de usuario podría ser mejor. Para mejorar la experiencia del usuario, se deben utilizar varios modos de PSA (auditar, aplicar, advertir).
apiVersion: v1 kind: Namespace metadata: name: policy-test labels: pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/warn: restricted
En el ejemplo anterior, con el modo de aplicación definido, cuando se intenta aplicar al servidor API de Kubernetes un manifiesto de despliegue con infracciones de PSS en el PodSpec correspondiente, el despliegue se aplicará correctamente, pero los pods no. Además, dado que los modos de auditoría y advertencia también están habilitados, el cliente del servidor de API recibirá un mensaje de advertencia y el evento del registro de auditoría del servidor de API también se anotará con un mensaje.
Restrinja los contenedores que pueden ejecutarse como privilegiados
Como se ha mencionado, los contenedores que se ejecutan con privilegios heredan todas las capacidades de Linux asignadas a la raíz del host. Rara vez los contenedores necesitan este tipo de privilegios para funcionar correctamente. Existen varios métodos que se pueden utilizar para restringir los permisos y las capacidades de los contenedores.
importante
Fargate es un tipo de lanzamiento que le permite ejecutar contenedores «sin servidor» en los que los contenedores de un pod se ejecutan en una infraestructura que administra AWS. Con Fargate, no puedes ejecutar un contenedor privilegiado ni configurar tu pod para que use HostNetwork o HostPort.
No ejecute procesos en contenedores como root
Todos los contenedores se ejecutan como root de forma predeterminada. Esto podría resultar problemático si un atacante es capaz de aprovechar una vulnerabilidad de la aplicación y obtener acceso desde el shell al contenedor en ejecución. Puede mitigar este riesgo de varias maneras. En primer lugar, quitando la carcasa de la imagen del contenedor. En segundo lugar, añade la directiva USER a tu Dockerfile o ejecuta los contenedores del pod como usuario no root. El PodSpec de Kubernetes incluye un conjunto de campos, en, que te permiten especificar el grupo de usuarios and/or en spec.securityContext el que se ejecutará la aplicación. Estos campos son y respectivamente. runAsUser runAsGroup
Para hacer cumplir el uso del spec.securityContext PodSpec de Kubernetes y sus elementos asociados, se pueden añadir a los clústeres los estándares de seguridad de Pod policy-as-code o Pod. Estas soluciones le permiten escribir o usar políticas o perfiles que puedan validar las cargas útiles entrantes de solicitudes del servidor API de Kubernetes antes de que se almacenen en etcd. Además, policy-as-code las soluciones pueden modificar las solicitudes entrantes y, en algunos casos, generar nuevas solicitudes.
Nunca ejecute Docker en Docker ni monte el socket en el contenedor
Si bien esto te permite grabar build/run imágenes en contenedores Docker, básicamente estás cediendo el control total del nodo al proceso que se ejecuta en el contenedor. Si necesitas crear imágenes de contenedores en Kubernetes, usa Kaniko
nota
Los clústeres de Kubernetes que se utilizan para el procesamiento del CICD, como la creación de imágenes de contenedores, deben aislarse de los clústeres que ejecutan cargas de trabajo más generalizadas.
Restrinja el uso de HostPath o, si es necesario, restrinja los prefijos que se pueden usar y configure el volumen como de solo lectura
hostPathes un volumen que monta un directorio desde el host directamente al contenedor. Los pods rara vez necesitarán este tipo de acceso, pero si lo necesitan, debes ser consciente de los riesgos. De forma predeterminada, los pods que se ejecutan como root tendrán acceso de escritura al sistema de archivos expuesto por HostPath. Esto podría permitir a un atacante modificar la configuración del kubelet, crear enlaces simbólicos a directorios o archivos no expuestos directamente por HostPath, por ejemplo, /etc/shadow, instalar claves ssh, leer los secretos guardados en el servidor y otras acciones maliciosas. Para mitigar los riesgos de HostPath, configúrelo como, por ejemplo: spec.containers.volumeMounts readOnly
volumeMounts: - name: hostPath-volume readOnly: true mountPath: /host-path
También debe usar policy-as-code soluciones para restringir los directorios que pueden usar los hostPath volúmenes o evitar su hostPath uso por completo. Puede utilizar las políticas básicas o restringidas de los estándares de seguridad de Pod para evitar el uso dehostPath.
Para obtener más información sobre los peligros de la escalada de privilegios, lee el blog de Seth Art Bad Pods: Kubernetes Pod
Establezca solicitudes y límites para cada contenedor para evitar la contención de recursos y los ataques de DoS
En teoría, un pod sin solicitudes ni límites puede consumir todos los recursos disponibles en un host. A medida que se programan más pods en un nodo, es posible que el nodo sufra una presión en la CPU o la memoria, lo que puede provocar que el Kubelet cierre o expulse los pods del nodo. Si bien no se puede evitar que esto suceda por completo, establecer solicitudes y límites ayudará a minimizar la contención de recursos y a mitigar el riesgo que supone el uso de aplicaciones mal escritas que consumen una cantidad excesiva de recursos.
podSpecEsto te permite especificar las solicitudes y los límites de la CPU y la memoria. La CPU se considera un recurso comprimible porque puede estar sobresuscrita. La memoria es incompresible, es decir, no se puede compartir entre varios contenedores.
Cuando especificas las solicitudes de CPU o memoria, básicamente estás designando la cantidad de memoria que se garantiza que obtendrán los contenedores. Kubernetes agrega las solicitudes de todos los contenedores de un pod para determinar en qué nodo programar el pod. Si un contenedor supera la cantidad de memoria solicitada, puede ser cancelado si hay una presión de memoria en el nodo.
Los límites son la cantidad máxima de recursos de CPU y memoria que puede consumir un contenedor y corresponden directamente al memory.limit_in_bytes valor del cgroup creado para el contenedor. Un contenedor que supere el límite de memoria será eliminado mediante OOM. Si un contenedor supera su límite de CPU, se estrangulará.
nota
Al usar un contenedorresources.limits, se recomienda encarecidamente que el uso de los recursos del contenedor (también conocido como huella de recursos) se base en datos y sea preciso, en función de las pruebas de carga. A falta de una huella de recursos precisa y fiable, el contenedor resources.limits puede ser acolchado. Por ejemplo, resources.limits.memory podría rellenarse entre un 20 y un 30% más que los máximos observables, para tener en cuenta las posibles imprecisiones en los límites de los recursos de memoria.
Kubernetes usa tres clases de calidad de servicio (QoS) para priorizar las cargas de trabajo que se ejecutan en un nodo. Entre ellos se incluyen:
-
garantizado
-
reventable
-
mejor esfuerzo
Si los límites y las solicitudes no están establecidos, el pod se configura como de máximo esfuerzo (prioridad más baja). Los módulos que hacen el mejor esfuerzo son los primeros en morir cuando no hay suficiente memoria. Si los límites están establecidos en todos los contenedores del módulo, o si las solicitudes y los límites se establecen con los mismos valores y no iguales a 0, el módulo se configura como garantizado (máxima prioridad). Los módulos garantizados no se eliminarán a menos que superen los límites de memoria configurados. Si los límites y las solicitudes están configurados con valores diferentes y no iguales a 0, o si un contenedor del pod establece límites y los demás no, o tienen límites establecidos para diferentes recursos, los pods se configuran como burstable (prioridad media). Estos módulos tienen algunas garantías de recursos, pero se pueden eliminar una vez que superen la memoria solicitada.
importante
Las solicitudes no afectan al memory_limit_in_bytes valor del cgroup del contenedor; el límite del cgroup se establece en la cantidad de memoria disponible en el host. Sin embargo, si el valor de las solicitudes es demasiado bajo, el kubelet podría poner fin al pod si la memoria del nodo se ve presionada.
| Clase | Priority (Prioridad) | Condición | Condición de muerte |
|---|---|---|---|
|
Garantizada |
highest |
límite = solicitud! = 0 |
Supere únicamente los límites de memoria |
|
ampliable |
medium |
límite! = solicitud! = 0 |
Se puede matar si se supera la memoria solicitada |
|
El mejor esfuerzo |
lowest |
El límite y la solicitud no están establecidos |
El primero en morir cuando no hay suficiente memoria |
Para obtener información adicional sobre la QoS de los recursos, consulte la documentación de Kubernetes
Puedes forzar el uso de las solicitudes y los límites estableciendo una cuota de recursos
Policy-as-code Las soluciones se pueden usar para hacer cumplir las solicitudes y los límites, o incluso para crear las cuotas de recursos y los rangos de límites cuando se crean los espacios de nombres.
No permita la escalación privilegiada
La escalada privilegiada permite que un proceso cambie el contexto de seguridad en el que se ejecuta. Sudo es un buen ejemplo de ello, al igual que los binarios con el bit SUID o SGID. La escalada de privilegios es básicamente una forma de que los usuarios ejecuten un archivo con los permisos de otro usuario o grupo. Para evitar que un contenedor utilice la escalación con privilegios, implemente una política de policy-as-code mutación allowPrivilegeEscalation que se establezca en false o establezca securityContext.allowPrivilegeEscalation en. podSpec Policy-as-code Las políticas también se pueden usar para evitar que las solicitudes del servidor de API se realicen correctamente si se detecta una configuración incorrecta. Los estándares de seguridad de los pods también se pueden usar para evitar que los pods utilicen la escalada de privilegios.
Deshabilita los montajes ServiceAccount de los tokens
En el caso de los pods que no necesiten acceder a la API de Kubernetes, puedes deshabilitar el montaje automático de un ServiceAccount token según las especificaciones de un pod o para todos los pods que usen una determinada especificación. ServiceAccount
apiVersion: v1 kind: Pod metadata: name: pod-no-automount spec: automountServiceAccountToken: false
apiVersion: v1 kind: ServiceAccount metadata: name: sa-no-automount automountServiceAccountToken: false
Inhabilita la detección de servicios
En el caso de los pods que no necesitan buscar ni llamar a los servicios del clúster, puedes reducir la cantidad de información que se proporciona a un pod. Puede configurar la política de DNS del pod para que no utilice CoreDNS y no exponga los servicios del espacio de nombres del pod como variables de entorno. Consulta los documentos de Kubernetes sobre variables de entorno para obtener más información sobre
apiVersion: v1 kind: Pod metadata: name: pod-no-service-info spec: dnsPolicy: Default # "Default" is not the true default value enableServiceLinks: false
Configura tus imágenes con un sistema de archivos raíz de solo lectura
La configuración de las imágenes con un sistema de archivos raíz de solo lectura evita que un atacante sobrescriba un binario del sistema de archivos que utiliza la aplicación. Si la aplicación tiene que escribir en el sistema de archivos, considere la posibilidad de escribir en un directorio temporal o adjuntar y montar un volumen. Para hacer cumplir esto, configure los pods de la SecurityContext siguiente manera:
... securityContext: readOnlyRootFilesystem: true ...
Policy-as-code y los estándares de seguridad del pod se pueden usar para hacer cumplir este comportamiento.
Según Windows, los contenedores de KubernetessecurityContext.readOnlyRootFilesystem no se pueden configurar true para un contenedor que se ejecute en Windows, ya que se requiere acceso de escritura para que los procesos del registro y del sistema se ejecuten dentro del contenedor.
Herramientas y recursos
-
Taller de inmersión en seguridad de Amazon EKS - Pod Security
-
open-policy-agent/gatekeeper-library: La biblioteca de políticas de OPA Gatekeeper es una biblioteca
de OPA/Gatekeeper políticas que puede utilizar como sustituta. PSPs -
Una colección de políticas comunes de OPA y Kyverno para EKS.
-
Pod Security Policy Migrator
, una herramienta que se convierte PSPs en políticas de OPA/Gatekeeper o Kyverno KubeWarden -
NeuVector de SUSE
, una plataforma de seguridad de contenedores de código abierto y de confianza cero, proporciona políticas de procesos y sistemas de archivos, así como reglas de control de admisión.
