El código del controlador de admisión está en revisión en: https://github.com/kubernetes/kubernetes/pull/24600

Esta característica salta directamente a Beta ya que tuvo una exposición inicial en OpenShift.

Estará deshabilitado por defecto en kubernetes/kubernetes#24600. Después de eso, necesitamos cambios en el controlador de admisión para vincular los PSP a los usuarios.

Tomando nota de https://github.com/kubernetes/kubernetes/pull/20573 como una dependencia para el siguiente paso en PSP (acceso a nivel de sujeto)

¿Cuál es el estado de esto? ¿Está actualizada la descripción del primer comentario?

¿La descripción en el primer comentario está actualizada?

no (no tengo permisos para actualizar). Creo que se han cumplido todos los requisitos alfa. Los tipos iniciales, la API y las pruebas se han fusionado. El controlador de admisión no está habilitado de forma predeterminada.

En mi opinión, el trabajo restante para beta/1.4 es la integración de autenticación para los permisos, la actualización de los nuevos campos que queremos restringir (seccomp - en progreso, sysctl) y los documentos/tutoriales necesarios.

Y una prueba e2e.

El martes 12 de julio de 2016 a las 6:23 a. m., Paul Weil [email protected] escribió:

¿La descripción en el primer comentario está actualizada?

no (no tengo permisos para actualizar). Yo creo todo el alfa
se han cumplido los requisitos. Los tipos iniciales, api y pruebas han sido
fusionado El controlador de admisión no está habilitado de forma predeterminada.

En mi opinión, el trabajo restante para beta/1.4 es la integración de autenticación para permisos,
actualizando para nuevos campos que queremos restringir (seccomp - en progreso,
sysctl), y cualquier documento/tutorial requerido.

—
Usted está recibiendo esto porque usted fue el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-232045429 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

¿Qué hay de las interacciones con los proveedores de la nube? Sería bueno asignar fácilmente a cada pod diferentes roles de IAM para que puedan acceder solo al subconjunto de servicios en la nube que realmente necesitan. ¿Estaría dentro del alcance o se considera un detalle de SecurityContext?

@therc que debe hacerse a través de ServiceAccount.

@goltermann Noté que esto estaba marcado con alfa, pero creo que probablemente necesite la etiqueta beta según https://github.com/kubernetes/features/issues/5#issuecomment -217939650

@erictune , ¿la beta suena bien según el comentario de @pweil-?

@goltermann Creo que técnicamente esto habría sido beta en 1.3, no es nuevo en 1.4 aunque el desarrollo está en curso.

Sí, la beta es correcta. Me equivoqué cuando dije alfa hoy.

genial, lo arreglé

@pweil- ¿Están listos los documentos? Actualice los documentos a https://github.com/kubernetes/kubernetes.github.io , y luego agregue números PR y marque la casilla de documentos en la descripción del problema.

@janetkuo documentos PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

editar: https://github.com/kubernetes/kubernetes.github.io/pull/1206 es el 1.4 PR correcto

CC @kubernetes/feature-reviewers

@pweil: supongo que este PR es real: https://github.com/kubernetes/kubernetes.github.io/pull/1206?

correcto

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Evite que los problemas se cierren automáticamente con un comentario /lifecycle frozen .

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe comentarios a sig-testing, kubernetes/test-infra y/o @fejta .
/ciclo de vida obsoleto

se está trabajando en 1.10 para mover PSP a su grupo API sin extensiones
cc @php-codificador

@erictune doc actualizaciones, por favor? Consulte también [la hoja de cálculo de seguimiento de funciones 1.10[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). Lmk si tiene alguna pregunta. Necesitamos que se revisen y fusionen las relaciones públicas de los documentos antes del 9 de marzo. ¡Gracias!

@php-codificador ^

@Bradamant3 @liggitt ¿Qué actualizaciones de documentos se requieren?

Para los cambios relacionados con la transición del grupo API, envié: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 y https:/ /github.com/kubernetes/examples/pull/208

No soy el propietario adecuado de las actualizaciones de PSP Doc.

El viernes 2 de marzo de 2018 a las 11:26, Vyacheslav Semushin <
[email protected]> escribió:

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt ¿Qué actualizaciones de documentos se requieren?

Para los cambios relacionados con la transición del grupo API, he enviado:
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/ejemplos#206 https://github.com/kubernetes/ejemplos/pull/206 ,
y kubernetes/ejemplos#208
https://github.com/kubernetes/examples/pull/208

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

Eso es todo lo que necesitamos. He agregado el PR a la hoja de cálculo de seguimiento. ¡Gracias!

@php-codificador @liggitt @tallclair
¿Algún plan para esto en 1.11?

Si es así, ¿puede asegurarse de que la función esté actualizada con el correspondiente:

• Descripción
• Hito
• cesionario(s)
• Etiquetas:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@php-coder ¿Puedes responder al comentario de @justaugustus con el trabajo que estás haciendo aquí? ¿Hay algún cambio además del movimiento del grupo de políticas?

¿Hay algún cambio además del movimiento del grupo de políticas?

No, solo trabajé en esto.

Espero que @liggitt actualice la descripción cuando tenga tiempo (porque no tengo los permisos apropiados).

Hecho.

@tallclair solo para aclarar, estamos rastreando estable como objetivo para 1.11, ¿correcto?
He actualizado la etiqueta, pero solo quiero asegurarme.

No, esto seguirá siendo beta. No estoy seguro de que PodSecurityPolicy pase a ser estable (es decir, será reemplazado por otra cosa), pero es posible que otros no estén de acuerdo conmigo en esto.

Entendido. ¡Gracias por la actualización, @tallclair!

@justaugustus Eliminaré esto del hito 1.11, ya que no habrá un progreso significativo en la versión actual.

No hay actualizaciones planeadas para 1.12

@tallclair , podría obtener las perillas RunAsGroup PSP en 1.12

Ack. Sin embargo, esto todavía estará en versión beta. Por el momento no hay planes de que PSP vaya a GA. Hay algunos problemas importantes de usabilidad que deben abordarse antes de avanzar en esto. (consulte https://github.com/kubernetes/kubernetes/issues/60001 y https://github.com/kubernetes/kubernetes/issues/56174)

/desasignar

/asignar @tallclair

Hola
Esta mejora se ha rastreado anteriormente, por lo que nos gustaría verificar y ver si hay algún plan para que esto se gradúe en etapas en Kubernetes 1.13. Este lanzamiento está destinado a ser más "estable" y tendrá una línea de tiempo agresiva. Solo incluya esta mejora si tiene un alto nivel de confianza en que cumplirá con los siguientes plazos:

• Documentos (marcador de posición abierto PR): 8/11
• Código Slush: 11/9
• Comienzo del congelamiento de código: 15/11
• Documentos completos y revisados: 27/11

Tómese un momento para actualizar los hitos en su publicación original para un seguimiento futuro y haga ping a @kacole2 si necesita incluirse en la hoja de seguimiento de mejoras 1.13

¡Gracias!

No hay cambios planeados en 1.13.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe comentarios a sig-testing, kubernetes/test-infra y/o fejta .
/ciclo de vida obsoleto

/eliminar ciclo de vida obsoleto

@tallclair Hola: soy el líder de la mejora para 1.14 y estoy revisando este problema para ver qué trabajo (si corresponde) se está planificando para la versión 1.14. La congelación de mejoras es el 29 de enero y quiero recordar que todas las mejoras deben tener un KEP

Nada planeado para la 1.14.

¿Cuáles son las brechas para que esto sea GA? Puedo pensar en algunos, pero no veo ningún criterio en la descripción.

Antes de que esto pueda ir a GA, debemos solucionar estos problemas:

1. Modelo de autorización defectuoso : el uso de PSP se otorga a través de RBAC y se puede otorgar al usuario o al pod creado. Otorgarlo al usuario es el enfoque intuitivo, pero es problemático (ver explicación). Este enfoque también tiene algunos problemas de seguridad.
2. Difícil de implementar: debido a que los pods se rechazan de forma predeterminada, no podemos implementar PSP en todos los clústeres sin romperlos. Del mismo modo, los usuarios que deseen habilitar PSP deben garantizar una cobertura completa de todas las cargas de trabajo antes de poder activarlo, lo que dificulta la habilitación (de ahí el uso relativamente bajo). Debido a que la característica debe habilitarse explícitamente, no tenemos una cobertura de prueba adecuada (la matriz de características es demasiado compleja).
3. API inconsistente : un problema menos fundamental, pero la evolución de la API de PSP durante un largo período de versiones de k8 ha dado lugar a una serie de inconsistencias que dificultan su uso. En particular, la mutación se agrupa junto con la validación, lo que puede generar algunos resultados inesperados cuando un pod tiene acceso a varios PSP.

@liggitt y yo tenemos algunas ideas sobre cómo abordar esto, pero hay una pregunta abierta sobre si esto pertenece al núcleo de Kubernetes. Me gustaría tener una hoja de ruta en el próximo mes, ya sea un plan para ir a GA o un plan de obsolescencia.

¡Gracias por compartir la información!

Debido a que los pods se rechazan de manera predeterminada, no podemos implementar PSP en todos los clústeres sin romperlos.

Supongo que no es realmente eso. Hicimos esto creando una PodSecurityPolicy que es lo suficientemente abierta (o incluso abierta) en primer lugar, y luego la refinamos gradualmente.

@ zhouhaibing089 un usuario de Kubrenetes puede usar ese método que funciona porque controlan las políticas. Sin embargo, no podemos implementarlo como un valor predeterminado de Kubernetes, ya que PodSecurityPolicy solo abre el clúster, lo que significa que es muy difícil administrar el PSP permitido todo controlado por el sistema.

Hola @liggitt @tallclair , soy el líder de mejora de 1.15. ¿Esta característica va a graduar las etapas alfa/beta/estable en 1.15? Por favor, hágamelo saber para que pueda ser rastreado correctamente y agregado a la hoja de cálculo. La propuesta de la comunidad deberá migrarse a un KEP para su inclusión en 1.15.

Una vez que comience la codificación, enumere todos los PR k/k relevantes en este problema para que se puedan rastrear correctamente.

No hay cambios planeados para 1.15

@tallclair Realmente me encantaría ver esta tierra como GA en 1.16. ¿Es eso posible?

@lachie83 No, no estamos seguros de querer que PodSecurityPolicy vaya a GA. No está claro que este sea un caso de uso que deba resolver el núcleo de Kubernetes, y estamos buscando alternativas fuera del núcleo. Si desea analizarlo con más detalle, es un buen tema para SIG-Auth.

@tallclair ¿Cosas como el guardián de Open Policy Agent serían un mejor camino para bajar?

Sí exactamente. Ese podría ser el competidor principal, y estoy trabajando en estrecha colaboración con ese equipo para asegurarme de que cubra estos casos de uso.

Lo único que he estado esperando es una herramienta que potencialmente podría traducir PodSecurityPolicy --> política de rego de OPA. Eso haría que desaprobarlos desde su punto de vista sea mucho más fácil.

@tallclair agradece la pronta respuesta

@SEJeff estuvo de acuerdo. No dejaremos de usar PodSecurityPolicy hasta que haya un reemplazo claro con paridad de características y ruta de migración.

Hola, @tallclair , mencionaste una hoja de ruta para GA o un plan para la desaprobación. Parece que nos inclinamos por lo último.

¿Tenemos algo escrito para ayudar a las personas que buscan PSP como una solución a cerrar el círculo?

Aún no. Parte de la vacilación es que no queremos decir que lo desaprobaremos a favor de otra cosa hasta que haya un reemplazo claro. Aunque estoy entusiasmado con gatekeeper, todavía no tiene las funciones (o la estabilidad) que necesitamos para reemplazar a PSP. Otra posibilidad es que podamos mover PSP fuera del árbol y traerlo a GA como un webhook de admisión (las 2 opciones no son mutuamente excluyentes). Sin embargo, aún no hemos presentado formalmente una hoja de ruta.

Vaya

Hola , @tallclair, parece que tampoco sucede nada aquí para la versión 1.16, así que lo mantendré igual.

Hola @tallclair -- 1.17 Líder de mejora aquí -- parece que esto se mantendrá como está para 1.17. Si eso cambia, no dude en darme un toque y puedo agregarlo a la hoja de seguimiento 👍

¿Ha habido más debates sobre un camino claro para el futuro de PSP?

Sí exactamente. Ese podría ser el competidor principal, y estoy trabajando en estrecha colaboración con ese equipo para asegurarme de que cubra estos casos de uso.

@tallclair : hemos implementado la mayoría de las comprobaciones de PSP en Kyverno. ¿Puedes ayudar a echar un vistazo? Me encantaría discutir ideas y detalles.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

El proyecto Gatekeeper también ha estado analizando cómo sería un mundo posterior a PSP. Nuestro enfoque inicial ha sido dividir el recurso PSP en restricciones individuales . Nos preguntábamos cuáles eran los pensamientos de la comunidad sobre este enfoque. ¿Quizás sería un buen momento para volver a imaginar cómo se componen estas políticas? La migración tanto para los usuarios nuevos como para los usuarios existentes de PSP también será importante.

CC @maxsmythe @sozercan @tsandall

Me preocupa dividir las políticas en restricciones individuales, es decir, necesito crear muchos más objetos de restricción. Si creo que necesito clonarlos o modificarlos para diferentes cargas de trabajo, me preocupa que se vuelva muy complejo.

Creo que el mejor enfoque sería uno centrado en el usuario. Si podemos obtener comentarios reales sobre cómo se utilizan las PSP y luego ver cómo se vería una configuración similar con estos complementos alternativos, entonces eso puede ayudar a dar forma al diseño.

@tallclair, uno de los casos de uso que buscamos está relacionado con la tenencia múltiple basada en espacios de nombres. La intención es usar políticas para hacer cumplir las restricciones y garantizar que los espacios de nombres estén configurados correctamente.

Antes de que esto pueda ir a GA, debemos solucionar estos problemas:

1. Modelo de autorización defectuoso : el uso de PSP se otorga a través de RBAC y se puede otorgar al usuario o al pod creado. Otorgarlo al usuario es el enfoque intuitivo, pero es problemático (ver explicación). Este enfoque también tiene algunos problemas de seguridad.

@tallclair , me pregunto sobre lo anterior: ¿puede dar más detalles sobre cómo este enfoque es problemático y/o tiene problemas de seguridad?

Alguien más informado puede confirmar este tweet:

https://twitter.com/TechJournalist/status/1197658440040165377

Y si eso es cierto, ¿qué deberían hacer las personas que usan PSP para limitar las capacidades de Linux en el futuro?

Hola a todos,
Esta es una discusión muy interesante y actualmente estamos buscando soluciones para asegurar la creación de pods en clústeres de Kubernetes.

Hemos analizado OPA Gatekeeper y PodSecurityPolicies, así como el esfuerzo por volver a implementar PSP en las restricciones de OPA.
El problema fundamental que encontramos con esta comparación es que estamos tratando con dos modelos opuestos.

• OPA Gatekeeper sigue el modelo abierto por defecto, en el que todo está permitido y el administrador prohíbe ciertas cosas con restricciones.
• PSP sigue el modelo cerrado por defecto, en el que todo está prohibido y el administrador permite ciertas cosas con políticas.

Desde una perspectiva de seguridad, diría que el modelo PSP es mejor, aunque más difícil de incorporar a los clústeres existentes, ya que todas las cargas de trabajo deben ajustarse a él.

¿Cómo planea cerrar esta brecha fundamental en la arquitectura, entre PSP y Constraint Framework?

/cc @ritazh Me encantaría saber tu opinión sobre esto, ya que has trabajado en la migración de la funcionalidad de PSP a OPA.

Los diferentes enfoques definitivamente hacen que la migración sea más complicada. Estamos explorando diferentes formas de hacer que la transición sea más fluida.

En un mundo perfecto, estoy de acuerdo en que negar todo por defecto es el enfoque más seguro. Sin embargo, es una de las cosas que hace que PSP sea tan difícil de usar e implementar. En la práctica, creo que es más factible reducir gradualmente los permisos y, como dice el viejo adagio, "la mejor seguridad es la seguridad que usas".

En una nota al margen, también estamos discutiendo cómo excluir/excluir/obtener excepciones a las restricciones (por ejemplo, para proteger el espacio de nombres del sistema kube). Dependiendo de cómo funcione esto, podría implementar un enfoque de denegación por defecto bloqueando todo y luego otorgando excepciones. Aunque no estoy seguro de si ese es un caso de uso para el que queremos diseñar...

@tallclair , ¿espera algún progreso en esto en 1.18? Soy una sombra de mejoras para el lanzamiento y me gustaría saber si deberíamos hacer un seguimiento de esto.

No hay cambios planeados para 1.18

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe comentarios a sig-testing, kubernetes/test-infra y/o fejta .
/ciclo de vida obsoleto

/eliminar ciclo de vida obsoleto

@tallclair Hola Tim. ¿Algún plan para esto en 1.19?

No hay planes para la v1.19, aunque espero ver algún movimiento en el marco de tiempo de la v1.20.

Me topé con las políticas de seguridad de Kubernetes Pod con Open Policy Agent . @tallclair , ¿puede compartir qué nos está bloqueando y dónde se necesita ayuda, feliz de contribuir también?

¿Puedes compartir lo que nos está bloqueando?

Básicamente, solo necesitamos tomar una decisión sobre el camino a seguir. Actualmente, creo que hay acuerdo en que PSP no debería convertirse en GA en su forma actual, pero aún no nos hemos decidido por un reemplazo. Opciones que hemos discutido:

1. Sin reemplazo: se recomienda elegir entre una opción de terceros con un webhook de admisión. El documento de estándares de seguridad de Pod recientemente publicado está tratando de simplificar esto al promover una funcionalidad equivalente.
2. Controles integrados alternativos
   
   
   
   1. @deads2k ha propuesto upstreaming openshifts SecurityContextConstraints
   
   
   2. He propuesto una función mínimamente configurable que solo aplica las políticas estándar vinculadas anteriormente (y recomiendo una solución de terceros cuando se necesita más capacidad de configuración)
   
   
3. Corregir la política de seguridad del módulo: aunque algunos de los problemas son lo suficientemente importantes para el diseño, esto debería ser compatible con versiones anteriores, momento en el que podría ser una nueva alternativa en (2)

¿Estoy leyendo https://github.com/kubernetes/kubernetes/pull/90603 correctamente que debido a que los estándares de seguridad del módulo están publicados, no hay un reemplazo planificado para los PSP en el servidor API y cualquier reemplazo deberá implementarse como un sistema externo?

Consulte https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

El cronograma de obsolescencia para la versión beta actual en 1.22 es independiente de si se proporcionará o no una implementación en el árbol de los perfiles de seguridad de pod estándar. Eso aún no se ha determinado.

Gracias, @liggitt estaba confirmando que no se había configurado nada. Pensé que originalmente nada quedaría en desuso hasta que hubiera un reemplazo disponible. No estaba claro si se había tomado una decisión de una forma u otra.

El cronograma de desuso no es específico de PSP y se agregó como parte de https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

si estoy leyendo esto correctamente, lo que impulsa la obsolescencia es que ninguna API debe estar en la misma versión beta durante más de 9 meses, por lo que PSP debe ser promovido o obsoleto y dado que no habrá nuevas versiones beta o GA de psp ¿Necesita ponerse en camino para la obsolescencia aunque no se haya decidido un reemplazo?

si estoy leyendo esto correctamente, lo que impulsa la obsolescencia es que ninguna API debería estar en la misma versión beta durante más de 9 meses

exactamente. todas las versiones beta futuras de todas las API integradas vendrán con un objetivo de desuso y eliminación predeterminado cuando se presenten por primera vez

Hola @tallclair

Mejoras Conducir aquí. ¿Algún plan para esto en 1.20?

Gracias,
kirsten

No hay planes para v1.20.

Esta situación es extremadamente frustrante para aquellos de nosotros que necesitamos ejecutar clústeres de alta seguridad. Nuestras opciones son:

1. Siéntese y espere a que las PSP queden obsoletas.
2. Subcontrate la aplicación de la seguridad del tiempo de ejecución de la carga de trabajo a un proveedor (Styra), ya que OPA no documenta cómo ejecutar un reemplazo de PSP totalmente restrictivo con Rego.

Entonces, mi empresa ha implementado PSP completamente bloqueados. No son fáciles de implementar y depurarlos es una tarea ardua, pero son muy funcionales y realmente funcionan. Incluso publicamos una publicación de blog que detalla cómo se pueden usar de esta manera y cómo manejar las excepciones cuando ocurren.

En mi opinión, la versión beta de PSP debe fusionarse tal como está en el núcleo principal de Kubernetes. Mis razones son:

1. Si bien las PSP tienen fallas, funcionan y han funcionado durante 10 versiones.
2. Kubernetes como proyecto debe preocuparse por la seguridad del tiempo de ejecución de la carga de trabajo. Los escapes de contenedores son demasiado fáciles. Los PSP son una de las pocas herramientas que hacen que esto sea más difícil para los atacantes.
3. Perfecto es el enemigo de Listo. Fusione los PSP tal como están e impulse la implementación "mejor" a policy/v2.
4. Finalmente, y lo más importante, permite a los desarrolladores de OSS ejecutar clústeres de mayor seguridad, no solo empresas que pueden pagar proveedores como Styra.

@ zapman449 , ¿puede aclarar qué quiere decir con un "reemplazo de PSP totalmente restrictivo"?

Es de esperar que la biblioteca Gatekeeper PSP facilite la aplicación de reglas similares a las utilizadas por PSP. Definitivamente estoy interesado en cualquier brecha funcional que estés viendo.

@ zapman449 , ¿tendrías un enlace a esa entrada de blog?

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe No me he puesto al día con lo que está haciendo Gatekeeper PSP, lo revisaré.

Sin embargo, lo que quiero decir es:

1. Control total sobre las capacidades del proceso como NET_BIND_SERVICE, SYS_ADMIN, etc.
2. Restringir UID/GID/FSGroups a valores distintos de cero
3. Listado explícito de rutas de host que se pueden montar
4. Listado explícito de tipos de montajes de volumen permitidos
5. Bloquear privilegios, bloquear escalada de privilegios
6. Bloquear el acceso a las primitivas de comunicación entre procesos a nivel de host
7. Bloquear el acceso a la red de host
8. restringir qué puertos de host están permitidos
9. Aplicar readOnlyRootFilesystem
10. Punto de conexión para SELinux

Estos se proporcionan hoy en día con los PSP.

Si estamos pidiendo una lista de deseos, me encantaría:

1. Valores predeterminados inteligentes para SysCalls desde contenedores. Hay un pequeño porcentaje de la lista total de llamadas al sistema de Linux que necesitan la mayoría de los contenedores. Permítanme restringir la mayoría de los contenedores a esa lista, luego permítanme permitir explícitamente ciertas llamadas para ciertos pods propiedad de ciertas cuentas de servicio, o dar carta blanca a cuentas de servicio específicas.
2. Déjame soñar un poco más y se me ocurrirá algo. ;-)

@zapman449 : si no lo ha visto, discutimos el futuro de las PSP en la última reunión de autenticación de firmas (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u ). Continuaremos la discusión en la reunión del 9 de diciembre si puede asistir, pero tampoco tomaremos ninguna decisión final sin enviar una propuesta a la lista de correo.

Nuestra intención aquí es absolutamente no dejar a nadie en la estacada. Sabemos que los PSP abordan una importante necesidad de seguridad para Kubernetes, y el propósito de estas discusiones es descubrir cuál es la mejor manera de satisfacer esas necesidades en el futuro.