@derekwaynecarr @sttts @erictune não viu um problema para isso, mas já está em alfa. Criando isso como um lembrete para colocá-lo na versão beta e estável.

@sttts você poderia fornecer os links apropriados para documentos e PRs? Acho que você está mais próximo desse código.

@ pweil- @sttts - de acordo com nossa discussão, este é um recurso que gostaríamos de patrocinar no Kubernetes 1.6 em @ kubernetes / sig-node

@ pweil- @derekwaynecarr , confirme se este recurso deve ser definido com o marco 1.6.

@idvoretskyi , pretendemos movê-lo para a versão beta do 1.6.

@sttts obrigado.

Parece que ainda é 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

E não consegui encontrar nenhuma documentação em kubernetes.io/docs.

@ pweil- alguma atualização para 1.8? Este recurso ainda está em andamento para o lançamento?

@idvoretskyi isso não era uma prioridade para 1.8. @ php-coder você pode adicionar um cartão a este para nosso planejamento de PM? Precisamos parar de deixar isso cair pelas rachaduras e movê-lo para beta e GA.

@ pweil- se este recurso não estiver planejado para 1.8 - atualize o marco com o "próximo marco" ou "1.9"

Eu gostaria de ver isso chegar ao beta. As prioridades (ou requisitos) para isso incluem:

1. As anotações (Pod & PodSecurityPolicy) devem ser movidas para campos no contêiner SecurityContext (consulte https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- in-existing-api-version)
2. Defina o formato seccomp de especificação OCI e defina um perfil padrão do Kubernetes (podemos reutilizar o Docker?) Https://github.com/kubernetes/kubernetes/issues/39128
   uma. Descubra como o perfil do Kubernetes é entregue ao tempo de execução do contêiner por meio de CRI (/ cc @yujuhong @ Random-Liu)
   b. docker/default ainda deve ser permitido se o tempo de execução for docker (para compatibilidade com versões anteriores)
3. O perfil padrão do Kubernetes deve ser o novo padrão. Para compatibilidade com versões anteriores, este deve ser um comportamento opcional (ou seja, controlado por bandeira). https://github.com/kubernetes/kubernetes/issues/39845

Alguém está interessado em conduzir este trabalho para o marco 1.9 (ou 1.10)? @jessfraz @ kubernetes / sig-auth-feature-requests e @ kubernetes / sig-node-feature-requests Estou olhando para você: wink:

Também relevante: https://github.com/kubernetes/community/pull/660 (precisamos acertar as decisões nesse PR antes de prosseguir?)

/ cc @destijl

Se alguém tiver tempo e quiser fazê-lo, é mais do que bem-vindo e eu
ajudará a responder a quaisquer perguntas

Em 22 de setembro de 2017 20:54, "Tim Allclair (St. Clair)" [email protected]
escreveu:

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

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-331593048 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABYNbDldlrwbOP75Y2AKM-bUFLnwrq0eks5slFbcgaJpZM4KgBy_
.

ok vou atualizar a proposta e começar amanhã se ninguém mais o fizer;)

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Evite que os problemas sejam fechados automaticamente com um comentário /lifecycle frozen .

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou @fejta .
/ lifecycle stale

Ei @jessfraz, não tenho certeza se você chegou a algum lugar sobre isso - não tenho largura de banda para codificá-lo, mas fico feliz em ajudar no teste ...

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

Se este problema puder ser encerrado agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle podre
/ remove-lifecycle stale

Problemas podres são encerrados após 30 dias de inatividade.
Reabra o problema com /reopen .
Marque o problema como novo com /remove-lifecycle rotten .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/fechar

/reabrir
/ ciclo de vida congelado
/ remove-lifecycle podre

@ php-coder: você não pode reabrir um fascículo / PR, a menos que você o tenha criado ou tenha sido designado para ele.

/reabrir
/ ciclo de vida congelado

Na segunda-feira, 26 de março de 2018 às 7h07, k8s-ci-robot [email protected]
escreveu:

@ php-coder https://github.com/php-coder : você não pode reabrir um problema / PR
a menos que você o tenha criado ou tenha sido designado para ele.

Em resposta a isso
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/reabrir
/ ciclo de vida congelado
/ remove-lifecycle podre

As instruções para interagir comigo usando comentários de RP estão disponíveis aqui
https://git.k8s.io/community/contributors/devel/pull-requests.md . Se
você tem perguntas ou sugestões relacionadas ao meu comportamento, envie um
problema contra o kubernetes / test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
repositório.

-
Você está recebendo isso porque faz parte de uma equipe que foi mencionada.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton : você não pode reabrir uma edição / RP, a menos que tenha sido o autor ou tenha sido designado para ela.

/reabrir

@idvoretskyi : você não pode reabrir um exemplar / RP a menos que seja o autor ou designado para ele.

Ihor 1, bot 0

@ pweil- @ php-coder @jessfraz
Algum plano para isso em 1.11?

Em caso afirmativo, certifique-se de que o recurso está atualizado com o apropriado:

• Descrição
• Marco
• Cessionário (s)
• Rótulos:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@ wangzhen127 está trabalhando nisso, mas não pode ser atribuído porque ainda não é um membro.

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

Obrigado pela atualização, Tim!
/ remove-ciclo de vida congelado

@ pweil- @tallclair - Estamos fazendo mais uma varredura na planilha de rastreamento de 1.11 Recursos .
Você se importaria de preencher algum campo incompleto / em branco para o item de linha deste recurso?

@ pweil- @tallclair - este recurso foi removido da etapa 1.11, pois não houve atualizações sobre o progresso ou documentos.

cc: @jberkus

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

Este recurso foi removido do marco anterior, então gostaríamos de verificar e ver se há algum plano para isso no Kubernetes 1.12.

Em caso afirmativo, certifique-se de que este problema está atualizado com TODAS as seguintes informações:

• Descrição do recurso de uma linha (pode ser usada como uma nota de versão):
• Contato principal (cessionário):
• SIGs responsáveis:
• Link da proposta de design (repositório da comunidade):
• Link para e2e e / ou testes de unidade:
• Revisor (es) - (para LGTM) recomendam que mais de 2 revisores (pelo menos um do arquivo OWNERS da área de código) concordem em revisar. Revisores de várias empresas preferidos:
• Aprovador (provavelmente do SIG / área à qual o recurso pertence):
• Meta de recurso (qual meta é igual a qual marco):
  
  
  
  • Alvo de liberação alfa (xy)
  
  
  • Meta de lançamento beta (xy)
  
  
  • Alvo de liberação estável (xy)
  
  

Observe que o congelamento de recursos ocorre em 31 de julho, após o qual qualquer problema de recurso incompleto exigirá que uma solicitação de exceção seja aceita no marco.

Além disso, esteja ciente dos seguintes prazos relevantes:

• Prazo do Docs (abrir espaço reservado para PRs): 21/08
• Congelamento do caso de teste: 28/08

Certifique-se de que todos os PRs para recursos tenham notas de versão relevantes incluídas também.

Frete feliz!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

Nenhuma mudança planejada para 1.12

Obrigado pela atualização, @tallclair!

Alguém está interessado em conduzir este trabalho para o marco 1.9 (ou 1.10)? @jessfraz @ kubernetes / sig-auth-feature-requests e @ kubernetes / sig-node-feature-requests Estou olhando para você wink

@tallclair , posso tentar pegar agora, se ainda for desejável

@stlaz : Reiterando as menções para acionar uma notificação:
@ kubernetes / sig-auth-feature-requests, @ kubernetes / sig-node-feature-requests

@stlaz , esse recurso ainda é desejado. Passei algum tempo adicionando perfis seccomp aos complementos como as primeiras etapas do # 39845 . Mas não tenho tempo suficiente para empurrar o recurso. Seria bom se você gostaria de trabalhar nisso. Qualquer ajuda é bem vinda! :)

@ wangzhen127 Obrigado, estava tentando repassar as coisas que foram feitas e os problemas abertos relacionados a esse recurso. Parece que o comentário https://github.com/kubernetes/features/issues/135#issuecomment -331592961 ainda contém e resume exatamente o trabalho que precisa ser feito agora.

Também percebi que você estava tentando adicionar um FeatureGate para isso, mas fechou o PR, por que isso?

PS: Desculpem a resposta tardia, estive um pouco longe.

Parece que o comentário nº 135 (comentário) ainda contém e resume exatamente o trabalho que precisa ser feito agora.

Isso está certo. Mais uma coisa que eu gostaria de acrescentar é um modo de "reclamação". Assim, os usuários têm a opção de obter avisos (em logs) sobre o uso de syscalls proibidos em vez de kill. Ações seccomp de registro estão disponíveis com Linux kernel 4.14+ ( seccomp doc ). É possível que versões mais antigas do kernel ainda estejam sendo usadas. Portanto, precisamos lidar com isso. Isso também precisará ser adicionado às especificações OCI.

Também percebi que você estava tentando adicionar um FeatureGate para isso, mas fechou o PR, por que isso?

O objetivo dessa porta de recurso era alterar o perfil padrão do seccomp de não confinado para "tempo de execução / padrão". Eu tenho muitas dúvidas sobre compatibilidade com versões anteriores, então isso parecia improvável de acontecer. Atualmente, não temos um plano para alterar os padrões de segurança em geral porque eles estão quebrando. A melhor abordagem que eu acho atualmente é empurrar seccomp para estável e ainda tem que ser um recurso opt-in em vez de opt-out.

Ações seccomp de registro estão disponíveis com Linux kernel 4.14+ ( seccomp doc ).

Acho que, como definiremos um formato seccomp padrão específico do Kubernetes como parte da segunda etapa, também poderíamos ter um que registraria em vez disso. Existe valor suficiente para isso? Poderia ser usado para as pessoas fazerem a transição de "não confinado" para "kube / default" quando o último falha demais? Eles gostariam de mudar para voltar?
Existem distribuições LTS usando 4.13- kernels Linux (Debian - 8,9; RHEL - 6, 7; Ubuntu LTS - 14.04, 16.04), então a compatibilidade do Kernel é definitivamente algo para se manter em mente.

Eu tenho muitas dúvidas sobre compatibilidade com versões anteriores, então isso parecia improvável de acontecer.

Os tempos de execução do contêiner também passaram por essa alteração no passado, quando ativaram o seccomp pela primeira vez. No momento, pelo menos o docker vem com um comportamento padrão, que é menos tolerante do que "não confinado", que poderia ter quebrado alguém. Não acho que estamos fazendo nada de errado se apenas seguirmos o comportamento dos componentes subjacentes (que também fornecem a opção de desativar esse comportamento).

Existe valor suficiente para isso?

Isso pode ser discutido. Meu pensamento original era mudar o padrão de não confinado para registro. Portanto, não temos problema de compatibilidade com versões anteriores. E se pudermos de alguma forma coletar dados e mostrar que em X% dos casos, não vemos nada registrado, o que significa que o perfil padrão não quebraria as coisas. Então, podemos propor a alteração do registro para matar. Coletar parte dos dados é complicado e pode dar muito trabalho. Mesmo se não seguirmos esse caminho, acho que ter um perfil de registro beneficiaria as pessoas quando elas quiserem experimentar o seccomp, mas ainda não estão confiantes.

Os tempos de execução do contêiner também passaram por essa alteração no passado, quando ativaram o seccomp pela primeira vez. No momento, pelo menos o docker vem com um comportamento padrão, que é menos tolerante do que "não confinado", que poderia ter quebrado alguém. Não acho que estamos fazendo nada de errado se apenas seguirmos o comportamento dos componentes subjacentes (que também fornecem a opção de desativar esse comportamento).

Quando o docker alterou o valor padrão, o kubernetes redefiniu explicitamente esse valor como não confinado. Falei com o pessoal da sig-architecture offline antes e eles estão muito preocupados com o problema de compatibilidade com versões anteriores.

E se pudermos de alguma forma coletar dados e mostrar que em X% dos casos, não vemos nada registrado, o que significa que o perfil padrão não quebraria as coisas.

Eu gosto desta ideia. A parte difícil é, claro, conseguir os dados, não tenho ideia de como fazer isso. Além disso, primeiro teríamos que propor essa alteração na especificação OCI e, em seguida, provavelmente implementá-la para pelo menos um tempo de execução do contêiner, certo? Isso seria normal acontecer na parte Beta do ciclo de vida?

Quando o docker alterou o valor padrão, o kubernetes redefiniu explicitamente esse valor como não confinado. Falei com o pessoal da sig-architecture offline antes e eles estão muito preocupados com o problema de compatibilidade com versões anteriores.

Entendo. Talvez pudéssemos de fato ir com o perfil "não confinado" como o padrão (possivelmente substituindo-o por algo como kube/logging mais tarde). Parece que isso pode ser controlado por PSPs em uma regra de negação, onde partimos do pressuposto de que tudo é permitido por padrão e estamos apenas cortando os privilégios mais adiante. Ter um controle de flag sobre isso pode ser útil para os casos em que os PSPs estão desligados, no entanto, para que um deva entrar também, ter esses dois mecanismos usados ​​ao mesmo tempo provavelmente seria um pouco confuso.

Acho que é uma direção um pouco diferente da considerada originalmente - vai contra o trabalho feito em https://github.com/kubernetes/kubernetes/issues/39845 , mas se concordarmos com o acima, devemos pensar nos perfis do seccomp nós iremos eventualmente enviar. Até agora estou vendo runtime/default , kube/default , kube/logging , junto com a opção de definir o perfil para unconfined . O resto é, obviamente, a capacidade de ter localhost/.* perfis, que já é fornecido pela implementação atual.

Isso seria normal acontecer na parte Beta do ciclo de vida?

Parece bom para mim. Embora eu ache que ajuda começar a proposta de especificações OCI mais cedo.

Vá com "não confinado" como o padrão agora parece bom para mim. Para kubernetes / kubernetes # 39845, adicionei anotações aos addons. E não acho que possamos ir mais longe.

Até agora estou vendo runtime / default, kube / default, kube / logging, junto com a opção de definir o perfil como não confinado. O resto é, obviamente, a capacidade de ter perfis localhost /.*, que já é fornecido pela implementação atual.

Funciona para mim. Para kube/default , podemos apenas começar com docker/default .

Ações seccomp de registro estão disponíveis com Linux kernel 4.14+ (seccomp doc).

Meu entendimento é que isso registra a ação com o PID - informações não necessariamente relacionadas ao contêiner. Portanto, o auditd ou algum outro daemon no host precisará fazer uma pesquisa / mapeamento para que o log seja realmente útil ...

E se pudermos de alguma forma coletar dados e mostrar que em X% dos casos, não vemos nada registrado, o que significa que o perfil padrão não quebraria as coisas. Então, podemos propor a alteração do registro para matar. Coletar parte dos dados é complicado e pode dar muito trabalho.

@Jessfraz já não

@tallclair você está certo, meio que me perdi nos comentários de todos os problemas. Para referência, aqui está o comentário informando que os Dockerfiles foram verificados: https://github.com/kubernetes/community/pull/660#issuecomment -303860107. Acho que poderíamos estar seguros tendo um padrão "mortal", afinal.

Oi
Esse aprimoramento já foi rastreado antes, portanto, gostaríamos de verificar e ver se há algum plano de graduar estágios no Kubernetes 1.13. Esta versão é destinada a ser mais 'estável' e terá um cronograma agressivo. Inclua este aprimoramento apenas se houver um alto nível de confiança de que ele atenderá aos seguintes prazos:

• Docs (abrir espaço reservado para PRs): 11/8
• Código Slush: 11/9
• Início do congelamento de código: 15/11
• Documentos completos e revisados: 27/11

Por favor, tome um momento para atualizar os marcos em sua postagem original para rastreamento futuro e ping @ kacole2 se precisar ser incluído na folha de rastreamento de melhorias 1.13

Obrigado!

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema puder ser encerrado agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

Os problemas de aprimoramento abertos em kubernetes/enhancements nunca devem ser marcados como congelados.
Os proprietários de aprimoramentos podem garantir que os aprimoramentos permaneçam atualizados, atualizando consistentemente seus estados ao longo dos ciclos de lançamento.

/ remove-ciclo de vida congelado

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

Se este problema puder ser encerrado agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle podre

/ remove-lifecycle podre

Olá @stlaz @ pweil-, sou o líder de aprimoramento do 1.15. Este recurso estará graduando os estágios alfa / beta / estável no 1.15? Informe-me para que possa ser rastreado corretamente e adicionado à planilha. Isso também exigirá que um KEP seja incluído no 1.15

Assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente.

nenhuma mudança planejada para 1,15

Olá, @tallclair @ pweil- @stlaz , sou o líder / sombra de aprimoramento do 1.16. Este recurso estará graduando os estágios alfa / beta / estável no 1.16? Informe-me para que possa ser adicionado à planilha de rastreamento 1.16 . Se não estiver se formando, vou removê-lo do marco e mudar o rótulo rastreado.

Assim que a codificação começar ou se já tiver começado, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente.

Como um lembrete, todo aprimoramento requer um KEP em um estado implementável com Critérios de Graduação explicando os requisitos de cada estágio alfa / beta / estável.

As datas dos marcos são Enhancement Freeze 7/30 e Code Freeze 29/8.

Obrigada.

Eu tenho o início de um plano para trazê-lo para GA, mas pode ser um exagero fazê-lo em 1.16. Vou tentar fazer uma proposta pelo congelamento de melhorias.

Olá @tallclair @ pweil-, 1.17 Enhancement Shadow aqui! 🙂

Gostaria de entrar em contato para saber *
Informe-me para que este aprimoramento possa ser adicionado à planilha de rastreamento 1.17 .

Obrigado!

🔔 Lembrete Amigável

• A programação de lançamento atual é
  
  
  
  • Segunda-feira, 23 de setembro - Começa o ciclo de lançamento
  
  
  • Terça-feira, 15 de outubro, EOD PST - Congelamento de melhorias
  
  
  • Quinta-feira, 14 de novembro, EOD PST - Código Congelado
  
  
  • Terça-feira, 19 de novembro - os documentos devem ser preenchidos e revisados
  
  
  • Segunda-feira, 9 de dezembro - Kubernetes 1.17.0 lançado
  
  

• Uma Proposta de Aprimoramento do Kubernetes (KEP) deve atender aos seguintes critérios antes do Congelamento de Aprimoramento para ser aceita na versão

  • PR é mesclado em
  • Em um estado implementable
  • Incluir plano de teste e critérios de graduação

• Todos os PRs k / k relevantes devem ser listados nesta edição

Sim, pretendo mudar para estável na v1.17 - KEP aqui: https://github.com/kubernetes/enhancements/pull/1148

Ei @tallclair , vou adicionar este aprimoramento à planilha de rastreamento a ser rastreada 👍

Por favor, veja a mensagem acima para lembretes amigáveis e observe que KEP está em um estado provisório . O KEP deve estar em um estado implementável para ser adicionado à versão 1.17.

/ milestone v1.17
/ estágio estável

Ei @tallclair, você poderia postar links para os testes no testgrid e acompanhar todos os testes adicionados para este aprimoramento?

Obrigado!

Vai fazer. Já existem vários testes seccomp, mas não consigo encontrá-los em nenhuma guia do painel (há alguma maneira de pesquisar em todos os testgrids por um teste específico?)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair não é uma boa maneira de pesquisar em testgrid = /

Meu melhor palpite (pelo menos para os 4 que você referenciou) é que eles não estão realmente sendo incluídos. 😬

Eles parecem que deveriam fazer parte do painel node-kubelet-features , mas a configuração do job para ci-kubernetes-node-kubelet-features tem isso para test_args :

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

Os próprios testes ginkgo são marcados com [Feature:Seccomp] e o sinalizador de foco não corresponde.

Acho que devemos apenas remover a tag de recurso quando isso for movido para o GA. Eu acho que seccomp é padrão no Linux, então a tag [LinuxOnly] deve ser suficiente.

Para o problema geral de testes que não estão sendo executados, eu preenchi https://github.com/kubernetes/test-infra/issues/14647

Olá @tallclair , (terça-feira, 15 de outubro, EOD PST) . Outro lembrete amigável de que para ser capaz de graduar isso na versão 1.17, o KEP deve ser incorporado e deve estar em um estado implementável. Parece que o KEP ainda está aberto e em estado provisório.

Olá @tallclair , infelizmente o prazo para o congelamento de melhorias 1.17 já passou e parece que o KEP ainda está aberto. Vou remover esse aprimoramento do marco 1.17.

Observe que você pode registrar uma exceção de melhoria se precisar obtê-la para 1.17

/ marco claro

Sim, não fez o corte. Na esperança de conseguir
/ milestone v1.18

Isso soa bem! Vou marcar isso como adiado para v1.18 na folha de acompanhamento de melhorias .

Ei, 👋, há algo que podemos fazer para avançar com este aqui. Eu ficaria feliz em contribuir aqui e também no problema do AppArmor.

Ei @tallclair

1.18 Equipe de melhorias verificando! Você está planejando se graduar para estável no 1.18? Parece que o KEP ainda está aberto.

O cronograma de lançamento é o seguinte:

Aprimorar congelamento: 28 de janeiro
Code Freeze: 5 de março
Docs Ready: 16 de março
Versão v1.18: 24 de março

Como um lembrete, o KEP precisa ser mesclado, com o status definido como implementable .

Obrigado!

@saschagrunert obrigado pela oferta! Preciso passar novamente no KEP para acompanhar a revisão da API que fiz com @liggitt. Assim que o KEP for aprovado, gostaria de receber sua ajuda com a implementação.

Acho que a maior questão em aberto no KEP agora é como lidar com o tipo de perfil localhost. Como queremos descontinuar o recurso (de preferência em favor de algo como https://github.com/kubernetes/enhancements/pull/1269, / cc @pjbgf ), gostaria de evitar colocar um campo para ele na API .

Ei @tallclair , alguma atualização sobre se isso vai chegar ao 1.18 ou não? Atualmente está marcado no marco, mas você não confirmou se devemos rastreá-lo ou não.

Obrigado!

v1.18 parece improvável para isso. Eu acho que podemos esbarrar em
/ milestone v1.19

Ótimo, obrigado pela atualização @tallclair :)

Olá @tallclair - 1.19 Líder de melhorias aqui, você planeja graduar este aprimoramento para stable nesta versão?

Não há planos de se graduar na v1.19. Eu tenho um KEP aberto, mas não estarei trabalhando nisso neste trimestre. @pjbgf pode pegá-lo na v1.20

@tallclair - Obrigado pelas atualizações. : ligeiramente_smiling_face:

/ milestone v1.20

Houve uma pequena mudança de planos neste - conforme combinado na reunião de nó de assinatura de ontem. Isso agora está planejado para:

/ milestone v1.19

@pjbgf : você deve ser um membro da equipe kubernetes / milestone -keepers do GitHub para definir o marco. Se você acredita que deveria ser capaz de emitir o comando / milestone, entre em contato com seu e peça que ele o proponha como um delegado adicional para essa responsabilidade.

@palnabarun Você se importa em definir esse problema para o marco v1.19, por favor?

/ assign pjbgf

/ milestone v1.19

Obrigado @pjbgf @tallclair pela atualização. Eu atualizei a folha de rastreamento de acordo com seus planos.

Você pode me informar em qual estágio de graduação você está almejando e um link para o KEP?

Obrigado! Agradeço todos os esforços. : ligeiramente_smiling_face:

A programação de lançamento atual é:

• Segunda-feira, 13 de abril: Semana 1 - Início do ciclo de lançamento
• Terça-feira, 19 de maio: Semana 6 - congelamento de melhorias
• Quinta-feira, 25 de junho: Semana 11 - Code Freeze
• Quinta-feira, 9 de julho: Semana 14 - os documentos devem ser concluídos e revisados
• Terça-feira, 4 de agosto: Semana 17 - Kubernetes v1.19.0 lançado

Segmentando GA

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
O KEP ainda tem seções não resolvidas, com PR de acompanhamento: https://github.com/kubernetes/enhancements/pull/1747

Olá @tallclair , obrigado pela atualização. : +1:

Eu atualizei a folha de acompanhamento de acordo.

PS: Eu atualizei a descrição do problema com links para o KEP e o PR de atualização mais recente do KEP.

obrigado @palnabarun pela atualização. : +1:

Olá @tallclair, 1.19 docs shadow here! Este trabalho de aprimoramento planejado para 1.19 requer novo ou modificação nos documentos?

Lembrete amigável de que se uma nova / modificação nos documentos for necessária, um marcador de posição PR contra k / website (branch dev-1.19 ) será necessário até sexta-feira, 12 de junho.

@annajung isso é para o

Adicionando @hasheddan quem está pegando isso (https://github.com/kubernetes/kubernetes/issues/58211).

Ótimo, obrigado pela atualização! Vou modificar a planilha de rastreamento de acordo.
Informe-nos assim que um espaço reservado para PR em relação a k / website tiver sido feito. Obrigado!

@pjbgf - Você pode, por favor, criar um link para todos os PR de implementação aqui - k / k ou outro? : ligeiramente_smiling_face:

A programação de lançamento atual é:

• ~ Segunda-feira, 13 de abril: Semana 1 - O ciclo de lançamento começa ~
• ~ Terça-feira, 19 de maio: Semana 6 - Congelamento de aprimoramentos ~
• Quinta-feira, 25 de junho: Semana 11 - Code Freeze
• Quinta-feira, 9 de julho: Semana 14 - os documentos devem ser concluídos e revisados
• Terça-feira, 4 de agosto: Semana 17 - Kubernetes v1.19.0 lançado

@palnabarun aqui estão os atuais:
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

Também criei uma edição abrangente que continha todos eles.

Olá @pjbgf @hasheddan. Apenas um lembrete amigável de que um espaço reservado para RP no site k / deve ser feito na sexta-feira, 12 de junho. Por favor, me avise assim que você tiver feito o PR, obrigado!

@annajung, obrigado pelo lembrete! Estará aberto em breve: +1:

Olá @pjbgf - Obrigado por criar o problema guarda-chuva. : +1:

Estamos rastreando o mesmo. : ligeiramente_smiling_face:

Olá @pjbgf - só queria verificar o andamento do aprimoramento.

O cronograma de lançamento foi revisado recentemente, mais detalhes podem ser encontrados aqui .

Por favor, deixe-me saber se você tem alguma dúvida. : ligeiramente_smiling_face:

O cronograma de lançamento revisado é:

• Quinta-feira, 9 de julho: Semana 13 - Código Congelado
• Quinta-feira, 16 de julho: Semana 14 - Documentos devem ser concluídos e revisados
• Terça-feira, 25 de agosto: Semana 20 - Kubernetes v1.19.0 lançado

Obrigado pela atualização @palnabarun. O código está quase todo pronto, mas agora estamos aguardando uma revisão de acompanhamento. No geral, ainda estamos com boa aparência. : +1:

Olá @pjbgf @hasheddan , um lembrete amigável do próximo prazo final que se aproxima.
Lembre-se de preencher o seu documento de RP de espaço reservado e deixá-lo pronto para revisão na segunda-feira, 6 de julho.

Olá @pjbgf @hasheddan : wave :, vejo que ainda há 3 itens de ação pendentes em https://github.com/kubernetes/kubernetes/issues/91286 para mudanças relacionadas à implementação e 1 item de ação pendente para documentação. Você acha que eles conseguirão passar do congelamento de código na quinta-feira, 9 de julho?

Obrigada. : ligeiramente_smiling_face:

O Code Freeze começa na quinta-feira, 9 de julho EOD PST

@palnabarun docs PR está quase todo pronto, apenas adicionando um guia específico para seccomp. Já tem um LGTM de @saschagrunert nas mudanças atuais. Obrigado por nos manter no caminho certo :)

Olá @hasheddan , obrigado pela atualização acima. Apenas um lembrete rápido para deixar seu documento PR pronto para revisão (Remover WIP / rebased / all ready to go) por EOD. Obrigado!

@annajung serve ! Obrigado!

@hasheddan - Obrigado pela atualização. :sorriso:

@pjbgf - Eu vi que em https://github.com/kubernetes/kubernetes/issues/91286 dois itens de ação principais ainda não foram mesclados e não estão no pool de mesclagem também. Você acha que eles entrarão antes do Code Freeze?

Obrigada. : ligeiramente_smiling_face:

@palnabarun estamos tentando fazer isso antes que o código congele, afinal ele já foi todo lgtm. Estamos tendo alguns problemas com alguns testes instáveis ​​do atm. 😅

Obrigado pelo aviso.

Para maior clareza, os 2 prs que estamos esperando para combinar são:
https://github.com/kubernetes/kubernetes/pull/91408 e https://github.com/kubernetes/kubernetes/pull/92856

O último (https://github.com/kubernetes/kubernetes/pull/92856) parece falhar em uma verificação de verificação. De acordo com https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, isso exigirá um rebase / repush / rereview antes que possa ser mesclado.

@kikisdeliveryservice obrigado pelo esclarecimento. Estamos esperando que os testes instáveis ​​em https://github.com/kubernetes/kubernetes/pull/91408 parem de falhar, uma vez que isso for mesclado, podemos rebase o segundo PR que depende dele.

Olá @pjbgf : wave :, Estamos no Code Freeze agora.

Uma vez que https://github.com/kubernetes/kubernetes/pull/91408 está no pool de fusão e https://github.com/kubernetes/kubernetes/pull/92856 requer um rebase em https://github.com/ kubernetes / kubernetes / pull / 91408 de acordo com https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, achamos que a melhor ação aqui seria registrar uma solicitação de exceção para obter tempo adicional para concluir o segundo PR após o pool de mesclagem ficar limpo.

Removendo o aprimoramento do marco por enquanto.

Obrigado!

Melhor,
Equipe de aprimoramentos de versão do Kubernetes v1.19

/ marco claro

Visto que kubernetes / kubernetes # 91408 está no pool de mesclagem e kubernetes / kubernetes # 92856 requer um rebase sobre kubernetes / kubernetes # 91408 de acordo com kubernetes / kubernetes # 92856 (comentário), achamos que a melhor ação aqui seria arquivar uma exceção solicitação para obter tempo adicional para concluir o segundo PR depois que o pool de mesclagem ficar claro.

Um rebase em um PR aprovado na fila de mesclagem não requer uma solicitação de exceção. O PR foi codificado e aprovado um dia inteiro antes do prazo.

Olá @liggitt : wave :, obrigado por suas contribuições. : +1:

Vamos incluir o aprimoramento de volta no ciclo. Todas as nossas apreensões eram em relação ao rebase. Já que isso está resolvido, está pronto para prosseguir. : ligeiramente_smiling_face:

/ milestone v1.19

@pjbgf @saschagrunert @hasheddan - obrigado por todas as suas contribuições. : 100:

Obrigado @palnabarun pelo rastreamento detalhado do aprimoramento. Nos agradecemos! 🙏

@saschagrunert a

@tallclair @pjbgf você acha que podemos encerrar este problema agora, já que seccomp é GA?

@saschagrunert Normalmente esperamos que o lançamento aconteça, então marcamos o KEP correspondente como implemented e então fechamos o problema de aprimoramento.

Sinta-se à vontade para prosseguir e fazer uma alteração para marcar https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md como implemented . : ligeiramente_smiling_face:

@saschagrunert Normalmente esperamos que o lançamento aconteça, então marcamos o KEP correspondente como implemented e então fechamos o problema de aprimoramento.

Sinta-se à vontade para prosseguir e fazer uma alteração para marcar https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md como implemented .

Obrigado pelo esclarecimento, abriu um PR em https://github.com/kubernetes/enhancements/pull/1932

O KEP foi atualizado para ser implementado (PR finalmente fundido!)

Sinta-se à vontade para encerrar este problema @saschagrunert

Obrigado a todos por todo o seu trabalho !!

/ marco claro

/fechar
Isso é feito.

@saschagrunert Não me lembro se discutimos isso antes, mas existe algum plano para limpar as anotações (ou seja, remover o suporte)? A principal motivação para fazer isso é que as ferramentas de terceiros (por exemplo, gatekeeper, krail) não precisem saber para verificar a anotação e o campo

@saschagrunert Não me lembro se discutimos isso antes, mas existe algum plano para limpar as anotações (ou seja, remover o suporte)? A principal motivação para fazer isso é que as ferramentas de terceiros (por exemplo, gatekeeper, krail) não precisem saber para verificar a anotação e o campo

Sim, está planejado para a v1.23. Isso se incorpora ao mecanismo de aviso (ainda não feito), que pode ser feito depois que as funções de utilitário necessárias existirem (ref https://github.com/kubernetes/kubernetes/issues/94626).

Do KEP:

Para aumentar a conscientização sobre o uso de anotações (no caso de automação antiga), um mecanismo de aviso será usado para destacar que o suporte será eliminado na v1.23. Os mecanismos considerados são anotações de auditoria, anotações no objeto, eventos ou um aviso conforme descrito em KEP # 1693.

…

Como oferecemos suporte a até 2 lançamentos menores de desvio de versão entre o mestre e o nó, as anotações devem continuar a ser suportadas e preenchidas para pelo menos 2 versões aprovadas na implementação inicial. No entanto, podemos decidir estender o suporte ainda mais para reduzir a quebra. Se esse recurso for implementado na v1.19, proponho a v1.23 como alvo para a remoção do comportamento antigo.

Você prefere reabrir esse problema até que esses bits também sejam implementados?

Sim, vamos manter isso aberto até que o recurso esteja totalmente concluído. Existe um problema ak / k arquivado para o trabalho que você descreveu?

Sim, vamos manter isso aberto até que o recurso esteja totalmente concluído. Existe um problema ak / k arquivado para o trabalho que você descreveu?

Agora temos um, lá: https://github.com/kubernetes/kubernetes/issues/95171 :)