View a markdown version of this page

Contextos de seguridad de los pods - Amazon EKS

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.

Contextos de seguridad de los pods

Las políticas de seguridad de los pods (PSP) y los estándares de seguridad de los pods (PSS) son dos formas principales de reforzar la seguridad en Kubernetes. Ten en cuenta que la PodSecurityPolicy versión 1.21 de Kubernetes dejó de estar disponible y se eliminará en la versión 1.25. Además, el Pod Security Standard (PSS) es el enfoque recomendado por Kubernetes para reforzar la seguridad en el futuro.

La política de seguridad de un pod (PSP) es una solución nativa de Kubernetes para implementar políticas de seguridad. PSP es un recurso a nivel de clúster que controla los aspectos de seguridad de la especificación de los Pod. Con la política de seguridad de los pods, puedes definir un conjunto de condiciones que deben cumplir los pods para que el clúster los acepte. La función PSP ha estado disponible desde los primeros días de Kubernetes y está diseñada para impedir que se creen pods mal configurados en un clúster determinado.

Para obtener más información sobre las políticas de seguridad de los pods, consulta la documentación de Kubernetes. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ De acuerdo con la política de obsolescencia de Kubernetes, las versiones anteriores dejarán de recibir soporte nueve meses después de que la función deje de estar disponible.

Por otro lado, los estándares de seguridad de los pods (PSS), que son el enfoque de seguridad recomendado y que normalmente se implementan mediante contextos de seguridad, se definen como parte de las especificaciones de los pods y contenedores en el manifiesto de los pods. El PSS es el estándar oficial que el equipo del proyecto de Kubernetes ha definido para abordar las mejores prácticas relacionadas con la seguridad de los pods. Define políticas como las de referencia (mínimamente restrictivas, predeterminadas), privilegiadas (sin restricciones) y restringidas (más restrictivas).

Recomendamos comenzar con el perfil de referencia. El perfil de referencia de PSS proporciona un equilibrio sólido entre la seguridad y las posibles fricciones, ya que requiere una lista mínima de excepciones y sirve como un buen punto de partida para la seguridad de las cargas de trabajo. Si actualmente utiliza PSP, le recomendamos que cambie a PSS. Puedes encontrar más información sobre las políticas de PSS en la documentación de Kubernetes. https://kubernetes.io/docs/concepts/security/pod-security-standards/ Estas políticas se pueden aplicar con varias herramientas, incluidas las de OPA y Kyverno. https://www.openpolicyagent.org/ https://kyverno.io/ Por ejemplo, Kyverno proporciona la colección completa de políticas de PSS aquí. https://kyverno.io/policies/

La configuración del contexto de seguridad permite conceder privilegios a los procesos seleccionados, usar los perfiles de los programas para restringir las capacidades de los programas individuales, permitir el escalamiento de privilegios y filtrar las llamadas al sistema, entre otras cosas.

Los pods de Windows de Kubernetes tienen algunas limitaciones y diferencias con respecto a las Linux-based cargas de trabajo estándar en lo que respecta a los contextos de seguridad.

Windows usa un objeto de trabajo por contenedor con un filtro de espacio de nombres del sistema para contener todos los procesos de un contenedor y proporcionar un aislamiento lógico del host. No hay forma de ejecutar un contenedor de Windows sin aplicar el filtro de espacio de nombres. Esto significa que los privilegios del sistema no se pueden hacer valer en el contexto del host y, por lo tanto, los contenedores con privilegios no están disponibles en Windows.

Las siguientes windowsOptions son las únicas opciones del contexto de seguridad de Windows documentadas, mientras que el resto son opciones generales del contexto de seguridad

Para obtener una lista de los atributos del contexto de seguridad compatibles con Windows y Linux, consulte la documentación oficial aquí.

La configuración específica del pod se aplica a todos los contenedores. Si no se especifica, se PodSecurityContext usarán las opciones del. Si se establece en SecurityContext y PodSecurityContext, el valor especificado en SecurityContext tiene prioridad.

Por ejemplo, la AsUserName configuración de ejecución para pods y contenedores, que es una opción de Windows, equivale aproximadamente a la AsUser configuración de Linux-specific ejecución y, en el siguiente manifiesto, el contexto de seguridad específico del pod se aplica a todos los contenedores

apiVersion: v1 kind: Pod metadata: name: run-as-username-pod-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo nodeSelector: kubernetes.io/os: windows

Mientras que en el siguiente ejemplo, el contexto de seguridad a nivel de contenedor anula el contexto de seguridad a nivel de pod.

apiVersion: v1 kind: Pod metadata: name: run-as-username-container-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo .. securityContext: windowsOptions: runAsUserName: "ContainerAdministrator" nodeSelector: kubernetes.io/os: windows

Ejemplos de valores aceptables para el AsUserName campo de ejecución: ContainerAdministrator ContainerUser, NT AUTHORITY\ NETWORK SERVICE, NT AUTHORITY\ LOCAL SERVICE

Por lo general, es una buena idea ejecutar los contenedores con ContainerUser los pods de Windows. Los usuarios no se comparten entre el contenedor y el ContainerAdministrator host, pero tienen privilegios adicionales cuando están dentro del contenedor. Tenga en cuenta que hay limitaciones de nombre de usuario que debe tener en cuenta.

Un buen ejemplo de cuándo usarlo ContainerAdministrator es configurar PATH. Puedes usar la directiva USER para hacerlo, de la siguiente manera:

USER ContainerAdministrator RUN setx /M PATH "%PATH%;C:/your/path" USER ContainerUser

Ten en cuenta también que los secretos se escriben en texto sin cifrar en el volumen del nodo (en comparación con tmpfs/in -memory en Linux). Esto significa que tienes que hacer dos cosas

  • Utilice las ACL de archivos para proteger la ubicación de los archivos secretos

  • Utilice el cifrado a nivel de volumen utilizando BitLocker