Introducción A medida que Kubernetes continúa madurando como la plataforma líder de orquestación de contenedores, la seguridad sigue siendo una preocupación primordial para las organizaciones que implementan aplicaciones en contenedores. Entre las herramientas fundamentales del arsenal de seguridad de Kubernetes, alguna vez desempeñaron un papel fundamental. PSP permitió a los administradores definir y aplicar meticulosamente restricciones de seguridad en los Pods, garantizando que solo los contenedores que cumplieran estándares de seguridad específicos pudieran operar dentro del clúster. Sin embargo, el panorama de la seguridad de Kubernetes está evolucionando rápidamente y es importante tener en cuenta que PSP ahora ha quedado obsoleto, comenzando con Kubernetes 1.25 (consulte el enlace a las notas de la versión urgente de Kubernetes 1.25). Este cambio se debe a varios factores, incluida la complejidad de gestionar y mantener las políticas de PSP, lo que a menudo genera desafíos operativos para los usuarios. En respuesta a la desaprobación, las organizaciones ahora buscan alternativas modernas a PSP, que no solo aborden los requisitos de seguridad sino que también simplifiquen el proceso de protección de las cargas de trabajo en . En esta guía completa, nos embarcamos en un viaje para navegar este cambio en las prácticas de seguridad de Kubernetes, centrándonos en la transición a Pod Security Admission (PSA). PSA es una de las alternativas más sólidas disponibles y este artículo la explora en profundidad. Sin embargo, vale la pena mencionar que otras dos alternativas, Kyverno y OPA Gatekeeper, se tratarán en artículos separados dentro de esta serie. A lo largo de este artículo, encontrará instrucciones detalladas para configurar e instalar PSA, guías de migración paso a paso para realizar una transición de PSP a PSA sin problemas y comandos precisos para transferir reglas de PSP existentes a PSA. Además, obtendrá los conocimientos necesarios para evaluar los espacios de nombres para determinar la preparación para la migración mediante comandos de prueba diseñados para PSA. Al final de esta guía, obtendrá una comprensión integral de las fortalezas y limitaciones de PSA, lo que lo equipará para tomar una decisión informada basada en los requisitos de seguridad específicos de su organización y el entorno de Kubernetes. Con esta guía, puede modernizar con confianza sus prácticas de seguridad de Kubernetes y garantizar que sus cargas de trabajo permanezcan protegidas mientras se despide de la era de las políticas de seguridad de Pod. las políticas de seguridad de pods (PSP) Kubernetes Admisión de seguridad de cápsulas (PSA) PSA garantiza que los contenedores cumplan con los estándares de seguridad nativos de Kubernetes, que están definidos por los estándares de seguridad de Pod. Estos estándares clasifican las políticas de seguridad en tres perfiles distintos, cada uno con un nivel diferente de restrictividad: PSA hace cumplir los estándares de seguridad de Kubernetes: : la política Privileged es intencionalmente abierta y no tiene ninguna restricción. Normalmente, esta política se dirige a cargas de trabajo a nivel de sistema y de infraestructura administradas por usuarios confiables. Se caracteriza por la ausencia de restricciones. Si bien los mecanismos de permiso por defecto como Gatekeeper pueden ser inherentemente privilegiados, para los mecanismos de denegación por defecto como la Política de seguridad de pod (PSP), la política de privilegios debe desactivar todas las restricciones. Privileged : la política Baseline está diseñada para una fácil adopción por parte de cargas de trabajo en contenedores comunes y, al mismo tiempo, evita escaladas de privilegios conocidas. Está dirigido a operadores de aplicaciones y desarrolladores de aplicaciones no críticas. Línea base : la política Restringido se centra en hacer cumplir las mejores prácticas rigurosas de refuerzo de Pod, aunque a costa de cierta compatibilidad. Se dirige principalmente a operadores y desarrolladores de aplicaciones críticas para la seguridad, así como a usuarios de menor confianza. Para obtener una lista completa de los controles que deben aplicarse o no permitirse en cada perfil, puede consultar la documentación oficial. Restringido a diferencia de otras soluciones, PSA no ofrece un método sencillo para migrar o modificar directamente las reglas de la política de seguridad del pod (PSP). El objetivo principal de PSA es validar los pods según los , incluidos los perfiles mencionados anteriormente. Sin transferencia directa de reglas de PSP: estándares de seguridad establecidos de Kubernetes : si bien PSA es eficaz en la validación, no puede modificar ni personalizar las especificaciones del pod como podría hacerlo PSP. El objetivo principal de PSA es hacer cumplir los estándares de seguridad predefinidos de Kubernetes y no incluye funciones para alterar o mutar las especificaciones del pod. Se centra principalmente en validar los pods según estos estándares establecidos. Sin mutaciones Configuración e instalación Dado que PSA es un componente nativo de Kubernetes, para que funcione, solo necesita asegurarse de que el controlador de admisión de seguridad del pod (PSA) esté habilitado en su clúster de Kubernetes. Puedes hacerlo ejecutando el siguiente comando: kubectl api-versions | grep admission Pasos de preparación para la migración Evaluar los permisos del espacio de nombres El control de la admisión de seguridad del pod está influenciado por las etiquetas del espacio de nombres. Esto implica que las personas con la capacidad de actualizar, parchear o crear espacios de nombres también tienen la autoridad para modificar la configuración de seguridad del Pod para esos espacios de nombres. Esta modificación podría potencialmente eludir políticas de seguridad más estrictas. Antes de continuar, es fundamental verificar que los permisos del espacio de nombres estén asignados exclusivamente a usuarios privilegiados y de confianza. Es recomendable abstenerse de otorgar estos permisos elevados a usuarios que no requieran dicho acceso. Si se necesitan restricciones adicionales para configurar etiquetas de seguridad de pod en objetos de espacio de nombres, considere utilizar un webhook de admisión para hacer cumplir esas restricciones. Optimice y normalice las políticas de seguridad de los pods Antes de migrar a Pod Security Admission (PSA), es beneficioso normalizar sus PodSecurityPolicies (PSP): : elimine las opciones que no están cubiertas por los estándares de seguridad del Pod. Estas opciones incluyen: Eliminar campos no admitidos .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass : inicie el proceso eliminando los campos que únicamente tienen un efecto mutante y no afectan la política de validación. Estos campos, como también se menciona en la referencia "Asignación de políticas de seguridad de pods a estándares de seguridad de pods", incluyen: Eliminar campos puramente mutantes .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities Nota IMPORTANTE: La eliminación de estos campos puede provocar que las cargas de trabajo carezcan de las configuraciones necesarias, lo que podría provocar problemas operativos. Es crucial garantizar que las cargas de trabajo puedan funcionar correctamente con las políticas simplificadas. Determine el nivel de seguridad del pod adecuado Al determinar el nivel de seguridad de Pod apropiado para su espacio de nombres, debe considerar varios métodos: Por requisitos de seguridad para el espacio de nombres Si está familiarizado con el nivel de acceso esperado y los requisitos de seguridad para el espacio de nombres, puede seleccionar un nivel de seguridad de pod apropiado según esos requisitos específicos. Este enfoque es similar a cómo abordaría la configuración de seguridad en un clúster nuevo. Por políticas de seguridad de pod existentes: Utilice la referencia para asignar cada una de sus políticas de seguridad de pods (PSP) existentes al nivel de estándar de seguridad de pods correspondiente. Si sus PSP no se basan originalmente en los estándares de seguridad de Pod, es posible que deba tomar una decisión. Elija un nivel de seguridad de Pod que sea al menos tan permisivo como el de sus PSP u opte por un nivel que sea al menos tan restrictivo. Para identificar qué PSP están en uso para pods dentro de un espacio de nombres específico, use el siguiente comando: "Asignación de políticas de seguridad de pods a estándares de seguridad de pods" kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u Por pods existentes: Realice un ensayo y aplique el comando de etiqueta de la siguiente sección para probar los niveles de seguridad de línea base y de pod restringido. Esto le ayuda a evaluar si estos niveles son lo suficientemente permisivos para sus cargas de trabajo existentes. Elija el nivel válido con menos privilegios que se alinee con sus cargas de trabajo existentes. Es importante tener en cuenta que las opciones mencionadas se basan en pods existentes, que pueden no tener en cuenta cargas de trabajo que no se están ejecutando actualmente. Esto incluye CronJobs, cargas de trabajo de escala a cero u otras cargas de trabajo que aún no se han implementado. Prueba del nivel de seguridad del pod Una vez que haya determinado el nivel de seguridad del Pod para su espacio de nombres (excepto el nivel Privilegiado), es importante validar la política elegida. Pod Security ofrece opciones de prueba para garantizar una implementación fluida y el cumplimiento de los estándares de seguridad. Pruebas de funcionamiento en seco: Utilice este método para evaluar el impacto de la política seleccionada sin su aplicación inmediata. Para realizar un ensayo, utilice el siguiente comando, que resaltará los pods existentes que no cumplan con el nivel de política especificado: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL Prueba del modo de auditoría: El modo de auditoría le permite registrar violaciones de políticas sin hacerlas cumplir. Los pods infractores se registran en los registros de auditoría para su posterior revisión. Habilite el modo de auditoría con el comando: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL Si surgen violaciones inesperadas de la política durante las pruebas, usted puede: Actualice las cargas de trabajo que no cumplen con las normas para alinearlas con la política. Ajuste el nivel de seguridad del pod para el espacio de nombres si es necesario para adaptarse a los requisitos de su carga de trabajo. Hacer cumplir el nivel de seguridad del pod Una vez que esté seguro de que el nivel de seguridad del pod seleccionado es apropiado para su espacio de nombres, puede proceder a aplicarlo. Este paso garantiza que los estándares de seguridad deseados se apliquen activamente a sus cargas de trabajo dentro del espacio de nombres. Para aplicar el nivel de seguridad del pod deseado en el espacio de nombres, utilice el siguiente comando: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL La ejecución de este comando activará y aplicará el nivel de seguridad del pod especificado, mejorando la postura de seguridad de su espacio de nombres. Sin pasar por PSP Para omitir de manera efectiva PodSecurityPolicy en el nivel del espacio de nombres, puede vincular una Política de seguridad de pod (PSP) con privilegios completos a todas las cuentas de servicio en el espacio de nombres. Este proceso garantiza que los pods dentro del espacio de nombres ya no estén sujetos a modificaciones o restricciones impuestas por PodSecurityPolicy. Puede hacerlo a nivel de clúster o a nivel de espacio de nombres individual. Configuración con ámbito de clúster (solo es necesaria una vez para todo el clúster): Cree una política de seguridad de pod (PSP) con privilegios completos aplicando un archivo de configuración YAML, como . Este PSP debe otorgar todos los privilegios necesarios a los pods y crear una función de clúster denominada privilegiado-psp para permitir el uso de políticas de seguridad de pods (PSP) y asociarlas con el PSP privilegiado: privilegiado-psp.yaml kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged Desactivación por espacio de nombres: Cree un enlace de rol en el espacio de nombres de destino para asociar el rol del clúster privilegiado-psp con el grupo . Este enlace otorga efectivamente a todas las cuentas de servicio dentro del espacio de nombres acceso al PSP con todos los privilegios, sin pasar por PodSecurityPolicy: system:serviceaccounts:$NAMESPACE kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE Con esta configuración, el PSP privilegiado no muta y el controlador de admisión PodSecurityPolicy siempre prioriza los PSP no mutantes. Como resultado, PodSecurityPolicy ya no modificará ni restringirá los pods en este espacio de nombres. Una ventaja de este enfoque es su reversibilidad. Si surge algún problema, puede revertir fácilmente el cambio eliminando el RoleBinding asociado con la desactivación de PodSecurityPolicy. Asegúrese de que las políticas de seguridad del pod preexistentes permanezcan vigentes durante este proceso. Deshacer la desactivación de PodSecurityPolicy: Para revertir la desactivación de PodSecurityPolicy para el espacio de nombres, simplemente elimine el RoleBinding creado anteriormente: kubectl delete -n $NAMESPACE rolebinding disable-psp Revisar los procesos de creación de espacios de nombres Con los espacios de nombres existentes actualizados para aplicar la admisión de seguridad del pod, es esencial revisar y actualizar sus procesos y políticas para crear nuevos espacios de nombres. Esto garantiza que los nuevos espacios de nombres se configuren con un perfil de seguridad de pod apropiado desde el principio. Considere los siguientes pasos para mejorar los procesos de creación de espacios de nombres: : actualice las políticas y procedimientos de su organización para crear nuevos espacios de nombres para incluir la selección y aplicación del nivel de seguridad de pod deseado. Asegúrese de que los estándares de seguridad se establezcan desde la etapa de creación. Ajuste las políticas de creación de espacios de nombres puede configurar estáticamente el controlador de admisión de Pod Security para definir niveles predeterminados de cumplimiento, auditoría y/o advertencia para espacios de nombres sin etiquetar. Este enfoque garantiza que los espacios de nombres que carecen de etiquetas explícitas de seguridad de pod sigan cumpliendo los estándares de seguridad especificados de forma predeterminada. Configuración estática: Al revisar sus procesos de creación de espacios de nombres, puede integrar perfectamente los estándares de Pod Security en y mantener un enfoque coherente y seguro en todos los espacios de nombres, antiguos y nuevos. su entorno Kubernetes Deshabilitar PodSecurityPolicy Una vez que esté seguro de que el controlador de admisión PodSecurityPolicy (PSP) ya no es necesario y de que Pod Security Admission (PSA) se haya implementado y validado correctamente, puede proceder a desactivar el controlador de admisión de PSP. Estos son los pasos para desactivar el controlador de admisión de PSP: Modifique la configuración de kube-apiserver: Abra el archivo de configuración de su kube-apiserver, que normalmente se encuentra en /etc/kubernetes/manifests/kube-apiserver.yaml. Agregue el indicador para desactivar el controlador de admisión de PSP. Asegúrese de que esté eliminado de la lista de complementos de admisión activos. --disable-admission-plugins kube-apiserver --disable-admission-plugins=PodSecurityPolicy Guarde el archivo de configuración. Reinicie kube-apiserver: Reinicie kube-apiserver para aplicar los cambios. Por lo general, puede lograr esto reiniciando el plano de control de Kubernetes o el propio módulo kube-apiserver. systemctl restart kubelet Verificación: Asegúrese de que el controlador de admisión de PSP esté deshabilitado verificando los registros de kube-apiserver o su estado. Después de suficiente "tiempo de inmersión" para estar seguro de que no necesitará volver a PSP, continúe con el siguiente paso. Recursos de limpieza de PSP: Con el controlador de admisión de PSP desactivado y el PSA implementado, puede eliminar de forma segura sus PodSecurityPolicies existentes, así como cualquier Role, ClusterRoles, RoleBindings y ClusterRoleBindings asociados. kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true Este paso de limpieza garantiza que no queden configuraciones residuales de PSP en su clúster. Al desactivar el controlador de admisión de PSP y eliminar los recursos relacionados con PSP, simplifica la arquitectura de seguridad de su clúster y completa la transición a Pod Security Admission. Resumen En esta guía completa, exploramos los pasos y consideraciones esenciales para realizar una transición sin problemas del Políticas de seguridad de pod (PSP) a Admisión de seguridad de pod (PSA). Esta migración garantiza que sus cargas de trabajo continúen ejecutándose de forma segura mientras se alinean con los estándares de seguridad en evolución de Kubernetes. marco de seguridad de su clúster de Kubernetes de Pros y contras de utilizar la admisión de seguridad de pod (PSA) Ventajas: : PSA es una parte integral de Kubernetes, lo que elimina la necesidad de instalaciones de herramientas de terceros. Aprovecha las funciones de seguridad integradas de la plataforma. Componente nativo de Kubernetes : PSA se alinea con los estándares de seguridad nativos de Kubernetes, lo que garantiza el cumplimiento de las mejores prácticas de la plataforma. Hace cumplir los estándares de Kubernetes Contras: : es posible que PSA no proporcione el mismo nivel de personalización que PSP, especialmente para políticas de seguridad complejas que requieren una mutación de las especificaciones del pod. Personalización limitada : las cargas de trabajo existentes deben actualizarse para incluir configuraciones de contexto de seguridad, lo que puede requerir la modificación de los archivos YAML. Se requiere modernización Esta guía le brinda el conocimiento y los pasos necesarios para migrar con confianza de PSP a PSA, garantizando una transición segura y eficiente y al mismo tiempo salvaguardando sus cargas de trabajo de Kubernetes. Estén atentos a los próximos artículos, donde exploraré rutas de migración alternativas a Kyverno y OPA Gatekeeper.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Este audio es producido en el idioma original de la historia!

Migración desde políticas de seguridad de pod: una guía completa (Parte 1: Transición a PSA)

Demasiado Largo; Para Leer

@viachaslaumatsukevich

Credibility

HISTORIAS RELACIONADAS