@derekwaynecarr @sttts @erictune no vio ningún problema para esto, pero ya está en alfa. Creando esto como un recordatorio para llevarlo a beta y estable.

@sttts ¿ podría proporcionar los enlaces adecuados a documentos y relaciones públicas? Creo que estás más cerca de este código.

@ pweil- @sttts : según nuestra discusión, esta es una función que nos gustaría patrocinar en Kubernetes 1.6 en @ kubernetes / sig-node

@ pweil- @derekwaynecarr , por favor, confirme que esta función debe configurarse con el hito 1.6.

@idvoretskyi tenemos como objetivo moverlo a beta para 1.6.

@sttts gracias.

Parece que esto sigue siendo alfa:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

Y no pude encontrar ninguna documentación en kubernetes.io/docs.

@ pweil- ¿alguna actualización para 1.8? ¿Esta función todavía está en camino para el lanzamiento?

@idvoretskyi esto no era una prioridad para 1.8. @ php-coder, ¿puede agregar una tarjeta a esto para nuestra planificación de PM? Tenemos que dejar de dejar que esto se desvanezca y moverlo a beta y GA.

@ pweil- si esta función no está planeada para 1.8 - por favor, actualice el hito con el "próximo hito" o "1.9"

Me gustaría que esto llegara a la versión beta. Las prioridades (o requisitos) para eso incluyen:

1. Las anotaciones (Pod y PodSecurityPolicy) deben moverse a los campos del contenedor SecurityContext (consulte https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- versión-api-existente)
2. Establezca el formato seccomp de especificaciones de OCI y defina un perfil predeterminado de Kubernetes (¿podemos reutilizar el de Docker?) Https://github.com/kubernetes/kubernetes/issues/39128
   una. Descubra cómo se entrega el perfil de Kubernetes al tiempo de ejecución del contenedor a través de CRI (/ cc @yujuhong @ Random-Liu)
   B. docker/default aún debería permitirse si el tiempo de ejecución es Docker (para compatibilidad con versiones anteriores)
3. El perfil predeterminado de Kubernetes debería ser el nuevo predeterminado. Para compatibilidad con versiones anteriores, DEBE ser un comportamiento opcional (es decir, controlado por bandera). https://github.com/kubernetes/kubernetes/issues/39845

¿Alguien está interesado en impulsar este trabajo para el hito 1.9 (o 1.10)? @jessfraz @ kubernetes / sig-auth-feature-orders y @ kubernetes / sig-node-feature-requirements Te estoy mirando: guiño:

También relevante: https://github.com/kubernetes/community/pull/660 (¿necesitamos resolver las decisiones en ese RP antes de continuar?)

/ cc @destijl

Si alguien tiene tiempo y quiere hacerlo, es más que bienvenido y yo
ayudará a responder cualquier pregunta

El 22 de septiembre de 2017 a las 20:54, "Tim Allclair (St. Clair)" [email protected]
escribió:

/ cc @destijl https://github.com/destijl

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-331593048 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABYNbDldlrwbOP75Y2AKM-bUFLnwrq0eks5slFbcgaJpZM4KgBy_
.

ok, actualizaré la propuesta y comenzaré con esto mañana si nadie más lo hará;)

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 sus comentarios a sig-testing, kubernetes / test-infra y / o @fejta .
/ ciclo de vida obsoleto

Hola @jessfraz, no estoy seguro de si llegaste a algo en esto; no tengo ancho de banda para codificarlo, pero estoy feliz de ayudar a probar ...

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

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

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido
/ remove-lifecycle stale

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerrar

/reabrir
/ ciclo de vida congelado
/ eliminar-ciclo de vida podrido

@ php-coder: no puede volver a abrir un problema / PR a menos que sea su autor o esté asignado a él.

/reabrir
/ ciclo de vida congelado

El lunes, 26 de marzo de 2018 a las 7:07 a.m., k8s-ci-robot [email protected]
escribió:

@ php-coder https://github.com/php-coder : no puede volver a abrir un problema / PR
a menos que sea su autor o esté asignado a él.

En respuesta a esto
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/reabrir
/ ciclo de vida congelado
/ eliminar-ciclo de vida podrido

Las instrucciones para interactuar conmigo usando comentarios de relaciones públicas están disponibles aquí.
https://git.k8s.io/community/contributors/devel/pull-requests.md . Si
tiene preguntas o sugerencias relacionadas con mi comportamiento, por favor presente una
problema contra el kubernetes / test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
repositorio.

-
Recibes esto porque estás en un equipo que se mencionó.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton : no puede volver a abrir un problema / PR a menos que sea su autor o esté asignado a él.

/reabrir

@idvoretskyi : no puede volver a abrir un problema / RP a menos que sea su autor o esté asignado a él.

Ihor 1, bot 0

@ pweil- @ php-coder @jessfraz
¿Algún plan para esto en 1.11?

Si es así, ¿puede asegurarse de que la función esté actualizada con lo siguiente?

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

cc @idvoretskyi

@ wangzhen127 está trabajando en ello, pero no puede ser asignado porque aún no es miembro.

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

¡Gracias por la actualización, Tim!
/ remove-lifecycle congelado

@ pweil- @tallclair : estamos haciendo un barrido más de la hoja de cálculo de seguimiento de funciones 1.11 .
¿Le importaría completar algún campo en blanco o incompleto para la línea de pedido de esta función?

@ pweil- @tallclair : esta función se ha eliminado del hito 1.11, ya que no ha habido actualizaciones con el progreso o los documentos.

cc: @jberkus

@ pweil- @tallclair @ kubernetes / sig-auth-feature-orders @ kubernetes / sig-node-feature-orders -

Esta función se eliminó del hito anterior, por lo que nos gustaría verificar y ver si hay algún plan para esto en Kubernetes 1.12.

Si es así, asegúrese de que este problema esté actualizado con TODA la siguiente información:

• Descripción de la función de una línea (se puede utilizar como nota de la versión):
• Contacto principal (cesionario):
• SIG responsables:
• Enlace de propuesta de diseño (repositorio comunitario):
• Enlace a e2e y / o pruebas unitarias:
• Revisores: (para LGTM) recomiendan tener más de 2 revisores (al menos uno del archivo de PROPIETARIOS de área de código) que estén de acuerdo para revisar. Los revisores de varias empresas prefieren:
• Aprobador (probablemente de SIG / área a la que pertenece la característica):
• Objetivo de función (qué objetivo es igual a qué hito):
  
  
  
  • Objetivo de liberación alfa (xy)
  
  
  • Objetivo de lanzamiento beta (xy)
  
  
  • Objetivo de liberación estable (xy)
  
  

Tenga en cuenta que la congelación de funciones es el 31 de julio, después de lo cual cualquier problema de funciones incompletas requerirá que se acepte una solicitud de excepción en el hito.

Además, tenga en cuenta los siguientes plazos relevantes:

• Fecha límite de documentos (RRPP de marcador de posición abierto): 21 de agosto
• Congelación de casos de prueba: 8/28

Asegúrese de que todos los RP de las funciones también incluyan notas de la versión relevantes.

¡Feliz envío!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

No hay cambios planeados para 1.12

¡Gracias por la actualización, @tallclair!

¿Alguien está interesado en impulsar este trabajo para el hito 1.9 (o 1.10)? @jessfraz @ kubernetes / sig-auth-feature-orders y @ kubernetes / sig-node-feature-orders Te estoy mirando guiño

@tallclair Puedo intentar recoger esto ahora si todavía es deseable

@stlaz : Reiterando las menciones para activar una notificación:
@ kubernetes / sig-auth-feature-orders, @ kubernetes / sig-node-feature-orders

@stlaz , esta característica todavía es deseada. He pasado algún tiempo agregando perfiles seccomp a complementos como los primeros pasos de # 39845 . Pero no tengo tiempo suficiente para impulsar la función. Sería bueno que te gustara trabajar en esto. ¡Cualquier ayuda es bienvenida! :)

@ wangzhen127 Gracias, estaba tratando de revisar las cosas que se hicieron y los problemas abiertos relacionados con esta función. Parecería que el comentario https://github.com/kubernetes/features/issues/135#issuecomment -331592961 todavía se mantiene y resume exactamente el trabajo que debe hacerse ahora.

También noté que estabas intentando agregar un FeatureGate para esto, pero cerré el PR, ¿por qué?

PD: Perdón por la respuesta tardía, estuve fuera por un tiempo.

Parecería que el comentario # 135 (comentario) todavía se mantiene y resume exactamente el trabajo que debe hacerse ahora.

Eso es correcto. Una cosa más que me gustaría agregar es tener un modo de "queja". Por lo tanto, los usuarios tienen la opción de recibir advertencias (en registros) sobre el uso de llamadas al sistema prohibidas en lugar de matar. Las acciones de registro de seccomp están disponibles con el kernel de Linux 4.14+ ( seccomp doc ). Es posible que se sigan utilizando versiones anteriores del kernel. Entonces tenemos que manejar eso. Esto también deberá agregarse a la especificación OCI.

También noté que estabas intentando agregar un FeatureGate para esto, pero cerré el PR, ¿por qué?

El propósito de esa puerta de función era cambiar el perfil predeterminado de seccomp de no confinado a "tiempo de ejecución / predeterminado". Tengo muchas preocupaciones sobre la compatibilidad con versiones anteriores, por lo que parece poco probable que eso suceda. Actualmente carecemos de un plan para cambiar los valores predeterminados de seguridad en general porque se están rompiendo. El mejor enfoque que creo actualmente es impulsar seccomp a estable y aún tiene que ser una función de suscripción en lugar de exclusión voluntaria.

Las acciones de registro de seccomp están disponibles con el kernel de Linux 4.14+ ( seccomp doc ).

Supongo que, dado que definiremos un formato seccomp predeterminado específico de Kubernetes como parte del segundo paso, también podríamos tener uno que registraría en su lugar. ¿Tiene suficiente valor? ¿Podría usarse para que las personas pasen de "ilimitado" a "kube / predeterminado" cuando este último falla demasiado? ¿Les importaría que cambiara para volver a cambiar?
Hay distribuciones de LTS que utilizan núcleos de Linux 4.13 (Debian - 8,9; RHEL - 6, 7; Ubuntu LTS - 14.04, 16.04), por lo que la compatibilidad del kernel es definitivamente algo a tener en cuenta.

Tengo muchas preocupaciones sobre la compatibilidad con versiones anteriores, por lo que parece poco probable que eso suceda.

Los tiempos de ejecución del contenedor también tuvieron que pasar por este cambio en el pasado, cuando habilitaban seccomp por primera vez. En este momento, al menos la ventana acoplable se envía con un comportamiento predeterminado que es menos permisivo que "ilimitado", lo que posiblemente podría haber roto a alguien. No creo que estemos haciendo nada mal si simplemente seguimos el comportamiento de los componentes subyacentes (que también brindan la opción de desactivar este comportamiento).

¿Tiene suficiente valor?

Esto se puede discutir. Mi pensamiento original era cambiar el valor predeterminado de ilimitado a registro. Entonces no tenemos problemas de compatibilidad con versiones anteriores. Y si de alguna manera podemos recopilar datos y mostrar que en el X% de los casos, no vemos nada registrado, lo que significa que el perfil predeterminado no rompería las cosas. Entonces podemos proponer cambiar el registro para matar. La parte de recopilación de datos es complicada y puede suponer mucho trabajo. Incluso si no tomamos ese camino, creo que tener un perfil de registro beneficiaría a las personas cuando quieran probar seccomp pero aún no se sienten seguras.

Los tiempos de ejecución del contenedor también tuvieron que pasar por este cambio en el pasado, cuando habilitaban seccomp por primera vez. En este momento, al menos la ventana acoplable se envía con un comportamiento predeterminado que es menos permisivo que "ilimitado", lo que posiblemente podría haber roto a alguien. No creo que estemos haciendo nada mal si simplemente seguimos el comportamiento de los componentes subyacentes (que también brindan la opción de desactivar este comportamiento).

Cuando Docker cambió el valor predeterminado, kubernetes restableció explícitamente dicho valor a ilimitado. Me comuniqué con gente de sig-architecture sin conexión antes y están muy preocupados por el problema de compatibilidad con versiones anteriores.

Y si de alguna manera podemos recopilar datos y mostrar que en el X% de los casos, no vemos nada registrado, lo que significa que el perfil predeterminado no rompería las cosas.

Me gusta esta idea. La parte difícil es, por supuesto, obtener los datos, no tengo idea de cómo lograrlo. Además, primero tendríamos que proponer este cambio a la especificación OCI y luego probablemente implementarlo durante al menos un tiempo de ejecución del contenedor, ¿verdad? ¿Estaría bien que sucediera en la parte Beta del ciclo de vida?

Cuando Docker cambió el valor predeterminado, kubernetes restableció explícitamente dicho valor a ilimitado. Me comuniqué con gente de sig-architecture sin conexión antes y están muy preocupados por el problema de compatibilidad con versiones anteriores.

Veo. Quizás de hecho podríamos ir con el perfil "ilimitado" como el predeterminado (posiblemente reemplazándolo con algo como kube/logging más adelante). Parece que esto podría ser controlado por los PSP mediante una regla de denegación, donde partimos de la suposición de que todo está permitido de forma predeterminada y solo vamos a recortar los privilegios más adelante. Sin embargo, tener un control de bandera sobre esto puede ser útil para los casos en los que los PSP están apagados, por lo que uno debería entrar también, pero tener estos dos mecanismos usados ​​a la vez probablemente sería un poco complicado.

Supongo que es una dirección un poco diferente a la que se consideró originalmente: va en contra del trabajo realizado en https://github.com/kubernetes/kubernetes/issues/39845 , pero si estamos de acuerdo con lo anterior, deberíamos pensar en los perfiles de seccomp eventualmente enviaremos. Hasta ahora veo runtime/default , kube/default , kube/logging , junto con la opción de establecer el perfil en unconfined . El resto es, por supuesto, la capacidad de tener perfiles localhost/.* , que ya se proporciona en la implementación actual.

¿Estaría bien que sucediera en la parte Beta del ciclo de vida?

Suena bien para mí. Aunque creo que ayuda comenzar la propuesta de especificaciones de OCI temprano.

Ir con "ilimitado" como predeterminado por ahora me suena bien. Para kubernetes / kubernetes # 39845, agregué anotaciones a los complementos. Y no creo que podamos ir más lejos.

Hasta ahora veo runtime / default, kube / default, kube / logging, junto con la opción de configurar el perfil como ilimitado. El resto es, por supuesto, la capacidad de tener perfiles localhost /.*, que ya es proporcionada por la implementación actual.

Funciona para mi. Para kube/default , podemos comenzar con docker/default .

Las acciones de registro de seccomp están disponibles con el kernel de Linux 4.14+ (seccomp doc).

Tengo entendido que esto registra la acción con el PID, no necesariamente información relacionada con el contenedor. Entonces, ya sea auditd o algún otro demonio en el host necesitará hacer una búsqueda / mapeo para que el registro sea realmente útil ...

Y si de alguna manera podemos recopilar datos y mostrar que en el X% de los casos, no vemos nada registrado, lo que significa que el perfil predeterminado no rompería las cosas. Entonces podemos proponer cambiar el registro para matar. La parte de recopilación de datos es complicada y puede suponer mucho trabajo.

¿No lo hizo @jessfraz al iniciar el perfil predeterminado de la

@tallclair , tienes razón, me perdí un poco en los comentarios de todos los problemas. Como referencia, aquí está el comentario que indica que se verificaron los archivos Docker: https://github.com/kubernetes/community/pull/660#issuecomment -303860107. Supongo que, después de todo, podríamos estar seguros teniendo un valor predeterminado "asesino".

Hola
Se ha realizado un seguimiento de esta mejora antes, por lo que nos gustaría verificar y ver si hay algún plan para que esto gradúe las etapas en Kubernetes 1.13. Esta versión está destinada a ser más "estable" y tendrá una línea de tiempo agresiva. Solo incluya esta mejora si existe un alto nivel de confianza en que cumplirá con los siguientes plazos:

• Documentos (PR de marcador de posición abierto): 8/11
• Código Slush: 11/9
• Comienza la congelación 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 hoja de seguimiento de mejoras 1.13

¡Gracias!

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 sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Los problemas de mejora abiertos en kubernetes/enhancements nunca deben marcarse como congelados.
Los propietarios de las mejoras pueden asegurarse de que las mejoras se mantengan actualizadas constantemente actualizando sus estados a lo largo de los ciclos de lanzamiento.

/ remove-lifecycle congelado

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

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

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

/ eliminar-ciclo de vida podrido

Hola @stlaz @ pweil-, soy el líder de mejora de 1.15. ¿Esta función va a graduar las etapas alfa / beta / estable en 1.15? Por favor, avíseme para poder realizar un seguimiento adecuado y agregarlo a la hoja de cálculo. Esto también requerirá que se incluya un KEP en 1.15

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

no hay cambios planeados para 1.15

Hola @tallclair @ pweil- @stlaz , soy el líder / sombra de mejora 1.16. ¿Esta función va a graduar las etapas alfa / beta / estable en 1.16? Por favor, avíseme para que se pueda agregar a la hoja de cálculo de seguimiento 1.16 . Si no se está graduando, lo eliminaré del hito y cambiaré la etiqueta de seguimiento.

Una vez que comience la codificación o si ya lo ha hecho, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente.

Como recordatorio, cada mejora requiere un KEP en un estado implementable con los Criterios de graduación que explican los requisitos de cada etapa alfa / beta / estable.

Las fechas de hitos son Enhancement Freeze el 30 de julio y Code Freeze el 29 de agosto.

Gracias.

Tengo los inicios de un plan para llevarlo a GA, pero podría ser difícil llegar a él en 1.16. Sin embargo, intentaré sacar una propuesta congelando las mejoras.

Hola @tallclair @ pweil-, 1.17 Enhancement Shadow aquí! 🙂

Quería comunicarme para ver * si esta mejora se graduará en alfa / beta / estable en 1.17.
Por favor, avíseme para que esta mejora se pueda agregar a la hoja de seguimiento 1.17 .

¡Gracias!

🔔 Recordatorio amistoso

• El calendario de lanzamiento actual es
  
  
  
  • Lunes 23 de septiembre: comienza el ciclo de lanzamiento
  
  
  • Martes 15 de octubre, EOD PST - Congelación de mejoras
  
  
  • Jueves, 14 de noviembre, EOD PST - Code Freeze
  
  
  • Martes 19 de noviembre: los documentos deben completarse y revisarse
  
  
  • Lunes 9 de diciembre: lanzamiento de Kubernetes 1.17.0
  
  

• Una propuesta de mejora de Kubernetes (KEP) debe cumplir con los siguientes criterios antes de la congelación de mejora para ser aceptada en la versión.

  • PR se fusiona en
  • En un estado implementable
  • Incluya el plan de prueba y los criterios de graduación.

• Todos los RP k / k relevantes deben incluirse en este número.

Sí, planeo graduar esto para que sea estable en v1.17 - GUARDE aquí: https://github.com/kubernetes/enhancements/pull/1148

Hola @tallclair ,

Consulte el mensaje anterior para obtener recordatorios amistosos y tenga en cuenta que KEP se encuentra en un estado provisional . KEP debe estar en un estado implementable para ser agregado a la versión 1.17.

/ hito v1.17
/ escenario estable

Hola @tallclair ¿Podrías publicar enlaces a las pruebas en testgrid y realizar un seguimiento de las pruebas agregadas para esta mejora?

¡Gracias!

Servirá. Ya hay un montón de pruebas de seccomp, pero no puedo encontrarlas en ninguna pestaña del tablero (¿hay alguna forma de buscar en todas las cuadrículas de prueba para una prueba específica?)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair no hay una buena manera de buscar en todo testgrid = /

Mi mejor suposición (al menos para los 4 a los que hizo referencia) es que en realidad no se incluyen. 😬

Parece que deberían ser parte del ci-kubernetes-node-kubelet-features tiene esto por su test_args :

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

Las pruebas de ginkgo en sí están etiquetadas con [Feature:Seccomp] y el indicador de enfoque no coincidiría.

Creo que deberíamos eliminar la etiqueta de función una vez que esto se mueva a GA. Creo que seccomp es estándar en Linux, por lo que la etiqueta [LinuxOnly] debería ser suficiente.

Para el problema general de que las pruebas no se ejecutan, presenté https://github.com/kubernetes/test-infra/issues/14647

Hola @tallclair , Estamos a solo 5 días de la congelación de mejoras (martes 15 de octubre, EOD PST) . Otro recordatorio amistoso de que para poder graduar esto en la versión 1.17, KEP debe fusionarse y debe estar en estado de implementación. Parece que el KEP todavía está abierto y se encuentra en un estado provisional.

Hola @tallclair , desafortunadamente, la fecha límite para la congelación de la mejora 1.17 ha pasado y parece que el KEP aún está abierto. Eliminaré esta mejora del hito de 1,17.

Tenga en cuenta que puede presentar una excepción de mejora si necesita obtener esto para 1.17

/ hito claro

Sí, no hice el corte. Esperando meterlo en
/ hito v1.18

¡Eso suena bien! Lo marcaré como diferido a v1.18 en la hoja de seguimiento de mejoras .

Oye 👋, ¿hay algo que podamos hacer para que esto avance? Estaré encantado de contribuir aquí, así como para el problema de AppArmor.

Hola @tallclair

1.18 ¡Registro del equipo de mejoras! ¿Está planeando graduarse a estable en 1.18? Parece que el KEP todavía está abierto.

El calendario de lanzamiento es el siguiente:

Enhance Freeze: 28 de enero
Congelación de código: 5 de marzo
Docs Ready: 16 de marzo
Versión 1.18: 24 de marzo

Como recordatorio, el KEP debe fusionarse, con el estado establecido en implementable .

¡Gracias!

@saschagrunert ¡ gracias por la oferta! Necesito tomar otro pase en el KEP para dar seguimiento a la revisión de API que tuve con @liggitt. Una vez que se apruebe el KEP, agradecería su ayuda con la implementación.

Creo que la mayor pregunta abierta en el KEP en este momento es cómo manejar el tipo de perfil de localhost. Dado que queremos desaprobar la función (idealmente a favor de algo como https://github.com/kubernetes/enhancements/pull/1269, / cc @pjbgf ), me gustaría evitar ponerle un campo en la API. .

Hola @tallclair , ¿alguna actualización sobre si esto llegará a 1.18 o no? Actualmente está marcado en el hito, pero no ha confirmado si debemos rastrearlo o no.

¡Gracias!

v1.18 parece poco probable para esto. Creo que podemos llegar a
/ hito v1.19

Genial, gracias por la actualización @tallclair :)

Hola @tallclair - 1.19 Mejoras stable esta versión?

No hay planes para graduarse en v1.19. Tengo un KEP abierto, pero no trabajaré en él este trimestre. @pjbgf puede recogerlo en v1.20

@tallclair - Gracias por las actualizaciones. : leve_sonriente_cara:

/ hito v1.20

Hubo un ligero cambio de planes en este, como se acordó en la reunión sig-node de ayer. Esto ahora está planeado para:

/ hito v1.19

@pjbgf : debes ser miembro del equipo de GitHub de kubernetes / milestone-maintenanceers para establecer el hito. Si cree que debería poder emitir el comando / milestone, comuníquese con usted y pídales que lo propongan como delegado adicional para esta responsabilidad.

@palnabarun ¿Le importaría establecer este problema en el hito v1.19, por favor?

/ asignar pjbgf

/ hito v1.19

Gracias @pjbgf @tallclair por la actualización. Actualicé la hoja de seguimiento de acuerdo con sus planes.

¿Puede decirme a qué etapa de graduación se dirige y un enlace al KEP?

¡Gracias! Aprecio todos los esfuerzos. : leve_sonriente_cara:

El calendario de lanzamiento actual es:

• Lunes 13 de abril: Semana 1: comienza el ciclo de lanzamiento
• Martes 19 de mayo: Semana 6 - Congelación de mejoras
• Jueves 25 de junio: Semana 11 - Congelación de código
• Jueves 9 de julio: Semana 14: los documentos deben completarse y revisarse
• Martes 4 de agosto: semana 17: lanzamiento de Kubernetes v1.19.0

Orientación a GA

GUARDAR: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
El KEP todavía tiene secciones sin resolver, con relaciones públicas de seguimiento: https://github.com/kubernetes/enhancements/pull/1747

Hola @tallclair , gracias por la actualización. : +1:

He actualizado la hoja de seguimiento en consecuencia.

PD: He actualizado la descripción del problema con enlaces a KEP y la última actualización de KEP PR.

gracias @palnabarun por la actualización. : +1:

Hola @tallclair 👋 1.19 docs shadow here! ¿Este trabajo de mejora planificado para la versión 1.19 requiere nuevos documentos o modificaciones?

Recordatorio amistoso de que si se requieren nuevos / modificaciones en los documentos, se necesita un marcador de posición PR contra k / sitio web (sucursal dev-1.19 ) antes del viernes 12 de junio.

@annajung eso es para los jefes. Sí, habrá algunas modificaciones en los documentos de seccomp.

Añadiendo @hasheddan, que está recogiendo esto (https://github.com/kubernetes/kubernetes/issues/58211).

¡Genial, gracias por la actualización! Modificaré la hoja de seguimiento en consecuencia.
Háganos saber una vez que se haya realizado un PR de marcador de posición contra k / sitio web. ¡Gracias!

@pjbgf - ¿Puede vincular todos los RP de implementación aquí - k / k o de otro modo? : leve_sonriente_cara:

El calendario de lanzamiento actual es:

• ~ Lunes 13 de abril: Semana 1 - Comienza el ciclo de lanzamiento ~
• ~ Martes 19 de mayo: Semana 6 - Congelación de mejoras ~
• Jueves 25 de junio: Semana 11 - Congelación de código
• Jueves 9 de julio: Semana 14: los documentos deben completarse y revisarse
• Martes 4 de agosto: semana 17: lanzamiento de Kubernetes v1.19.0

@palnabarun aquí están los actuales:
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

También creé una edición general que los incluía a todos.

Hola @pjbgf @hasheddan Solo un recordatorio amistoso de que un marcador de posición de relaciones públicas contra k / sitio web

@annajung ¡ gracias por el recordatorio! Pronto estará abierto: +1:

Hola @pjbgf : Gracias por crear el problema del paraguas. : +1:

Estamos rastreando lo mismo. : leve_sonriente_cara:

Hola @pjbgf : solo quería saber el progreso de la mejora.

El cronograma de lanzamiento se ha revisado recientemente, y se pueden encontrar más detalles aquí .

Por favor hazme saber si tienes preguntas. : leve_sonriente_cara:

El calendario de publicación revisado es:

• Jueves 9 de julio: Semana 13 - Congelación de código
• Jueves 16 de julio: Semana 14: los documentos deben completarse y revisarse
• Martes, 25 de agosto: Semana 20 - Lanzamiento de Kubernetes v1.19.0

Gracias por la actualización @palnabarun. Casi todo el código está listo, pero ahora estamos esperando una revisión de seguimiento. En general, todavía nos vemos bien. : +1:

Hola @pjbgf @hasheddan , un recordatorio amistoso de la próxima fecha límite.
Recuerde completar su documento PR de marcador de posición y prepárelo para su revisión antes del lunes 6 de julio.

Hola @pjbgf @hasheddan : wave :, Veo que todavía hay 3 elementos de acción pendientes en https://github.com/kubernetes/kubernetes/issues/91286 para los cambios relacionados con la implementación y 1 elemento de acción pendiente para la documentación. ¿Crees que superarán la congelación del código el jueves 9 de julio?

Gracias. : leve_sonriente_cara:

Code Freeze comienza el jueves 9 de julio EOD PST

@palnabarun docs PR está casi listo, simplemente agregando una guía específica para seccomp. Ya tengo un LGTM de @saschagrunert sobre los cambios actuales. Gracias por mantenernos en el buen camino aquí :)

Hola @hasheddan , gracias por la actualización anterior. Solo un recordatorio rápido para que su doc ​​PR esté listo para su revisión (Eliminar WIP / rebased / all ready to go) por EOD. ¡Gracias!

¡@annajung servirá! ¡Gracias!

@hasheddan - Gracias por la actualización. :sonrisa:

@pjbgf - Vi que en https://github.com/kubernetes/kubernetes/issues/91286 dos elementos de acción principales aún no se han fusionado y tampoco están en el grupo de fusión. ¿Crees que entrarán antes del Code Freeze?

Gracias. : leve_sonriente_cara:

@palnabarun estamos tratando de hacerlo antes de que el código se congele, después de todo, ya ha sido todo lgtm. Estamos teniendo algunos problemas con algunos cajeros automáticos de pruebas inestables. 😅

Gracias por el aviso.

Para mayor claridad, los 2 prs que estamos esperando fusionar son:
https://github.com/kubernetes/kubernetes/pull/91408 y https://github.com/kubernetes/kubernetes/pull/92856

Este último (https://github.com/kubernetes/kubernetes/pull/92856) parece fallar en una verificación de verificación. Según https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, esto requerirá un rebase / repush / rereview antes de que pueda fusionarse.

@kikisdeliveryservice gracias por la aclaración. Estamos esperando que las pruebas inofensivas en https://github.com/kubernetes/kubernetes/pull/91408 dejen de fallar, una vez que se fusionen podemos rebasar el segundo PR que depende de él.

Hola @pjbgf : wave :, Estamos en Code Freeze ahora.

Dado que, https://github.com/kubernetes/kubernetes/pull/91408 está en el grupo de fusión y https://github.com/kubernetes/kubernetes/pull/92856 requiere una rebase sobre https://github.com/ kubernetes / kubernetes / pull / 91408 de acuerdo con https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, creemos que la mejor acción aquí sería presentar una solicitud de excepción para obtener tiempo adicional para completar el segundo PR después de que el grupo de fusión se aclare.

Eliminando la mejora del hito por el momento.

¡Gracias!

Mejor,
Equipo de mejoras de la versión de Kubernetes v1.19

/ hito claro

Dado que, kubernetes / kubernetes # 91408 está en el grupo de fusión y kubernetes / kubernetes # 92856 requiere un rebase sobre kubernetes / kubernetes # 91408 de acuerdo con kubernetes / kubernetes # 92856 (comentario), creemos que la mejor acción aquí sería presentar una excepción Solicite obtener tiempo adicional para completar el segundo RP después de que se elimine el grupo de fusión.

Un cambio de base en un RP aprobado en la cola de fusión no requiere una solicitud de excepción. El PR tenía el código completo y se aprobó un día antes de la fecha límite.

Hola @liggitt : wave :, gracias por tus aportes. : +1:

Vamos a incluir la mejora de nuevo en el ciclo. Todas nuestras aprensiones estaban relacionadas con el rebase. Dado que eso está ordenado, esto es bueno para comenzar. : leve_sonriente_cara:

/ hito v1.19

@pjbgf @saschagrunert @hasheddan - gracias por todas sus contribuciones. : 100:

Gracias @palnabarun por el seguimiento detallado de la mejora. ¡Lo apreciamos! 🙏

@saschagrunert la

@tallclair @pjbgf ¿Crees que podemos cerrar este problema ahora ya que seccomp es GA?

@saschagrunert Por lo general, esperamos a que se produzca el lanzamiento, luego marcamos el KEP correspondiente como implemented y luego cerramos el problema de mejora.

No dude en seguir adelante y realizar un cambio para marcar https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md como implemented . : leve_sonriente_cara:

@saschagrunert Por lo general, esperamos a que se produzca el lanzamiento, luego marcamos el KEP correspondiente como implemented y luego cerramos el problema de mejora.

No dude en seguir adelante y realizar un cambio para marcar https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md como implemented .

Gracias por la aclaración, abrí un PR en https://github.com/kubernetes/enhancements/pull/1932

El KEP se ha actualizado para implementado (¡PR finalmente se fusionó!)

No dude en cerrar este problema @saschagrunert

¡¡Gracias a todos por todo su trabajo !!

/ hito claro

/cerrar
Eso está hecho.

@saschagrunert No puedo recordar si discutimos esto antes, pero ¿hay algún plan para eventualmente limpiar las anotaciones (es decir, eliminar el soporte)? La motivación principal para hacerlo es para que las herramientas de terceros (por ejemplo, guardián, krail) no necesiten saber para verificar tanto la anotación como el campo

@saschagrunert No puedo recordar si discutimos esto antes, pero ¿hay algún plan para eventualmente limpiar las anotaciones (es decir, eliminar el soporte)? La motivación principal para hacerlo es para que las herramientas de terceros (por ejemplo, guardián, krail) no necesiten saber para verificar tanto la anotación como el campo

Sí, esto está planeado para v1.23. Esto se incorpora con el mecanismo de advertencia (aún no hecho), que se puede hacer después de que existan las funciones de utilidad necesarias (ref https://github.com/kubernetes/kubernetes/issues/94626).

Desde el KEP:

Para crear conciencia sobre el uso de anotaciones (en caso de automatización antigua), se utilizará un mecanismo de advertencia para resaltar que el soporte se eliminará en la v1.23. Los mecanismos que se consideran son anotaciones de auditoría, anotaciones sobre el objeto, eventos o una advertencia como se describe en KEP # 1693.

...

Dado que admitimos hasta 2 versiones menores de sesgo de versiones entre el maestro y el nodo, las anotaciones deben seguir siendo compatibles y rellenadas durante al menos 2 versiones que pasaron la implementación inicial. Sin embargo, podemos decidir extender el soporte más lejos para reducir las roturas. Si esta característica se implementa en v1.19, propongo v1.23 como un objetivo para eliminar el comportamiento anterior.

¿Prefiere reabrir este problema hasta que esos bits también se implementen?

Sí, mantengamos esto abierto hasta que la función esté completamente envuelta. ¿Se ha presentado un problema de k / k para el trabajo que describió?

Sí, mantengamos esto abierto hasta que la función esté completamente envuelta. ¿Se ha presentado un problema de k / k para el trabajo que describió?

Ahora tenemos uno, ahí: https://github.com/kubernetes/kubernetes/issues/95171 :)