O código do controlador de admissão está em revisão em: https://github.com/kubernetes/kubernetes/pull/24600

Esse recurso está pulando direto para o Beta, pois teve exposição inicial no OpenShift.

Ele será desativado por padrão em kubernetes/kubernetes#24600. Depois disso, precisamos de alterações no controlador de admissão para vincular os PSPs aos usuários.

Observando https://github.com/kubernetes/kubernetes/pull/20573 como uma dependência para a próxima etapa no PSP (acesso em nível de assunto)

Qual é o estado disso? A descrição do primeiro comentário está atualizada?

A descrição no primeiro comentário está atualizada

não (não tenho permissão para atualizar). Acredito que todos os requisitos alfa foram atendidos. Os tipos iniciais, api e testes foram mesclados. O controlador de admissão não está habilitado por padrão.

IMO, o trabalho restante para beta/1.4 é integração de autenticação para permissões, atualização para novos campos que queremos restringir (seccomp - em andamento, sysctl) e quaisquer documentos/tutoriais necessários.

E um teste e2e.

Em terça-feira, 12 de julho de 2016 às 6h23, Paul Weil [email protected] escreveu:

A descrição no primeiro comentário está atualizada

não (não tenho permissão para atualizar). Eu acredito que todos os alfas
requisitos foram atendidos. Os tipos iniciais, api e testes foram
mesclado. O controlador de admissão não está habilitado por padrão.

IMO, o trabalho restante para beta/1.4 é integração de autenticação para permissões,
atualização para novos campos que queremos restringir (seccomp - em andamento,
sysctl) e quaisquer documentos/tutoriais necessários.

—
Você está recebendo isso porque foi o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
ou silenciar o thread
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

Que tal interações com provedores de nuvem? Seria bom atribuir facilmente a cada pod diferentes funções do IAM para que eles pudessem acessar apenas o subconjunto de serviços de nuvem de que realmente precisam. Estaria no escopo ou é considerado um detalhe do SecurityContext?

@therc que deve ser feito via ServiceAccount.

@goltermann Percebi que isso foi marcado com alfa, mas acredito que provavelmente precisa da tag beta com base em https://github.com/kubernetes/features/issues/5#issuecomment -217939650

@erictune o beta soa certo com base no comentário @pweil-?

@goltermann Acho que tecnicamente isso teria sido beta no 1.3, não é novo no 1.4, embora o desenvolvimento esteja em andamento.

Sim, beta está correto. Eu estava incorreto quando disse alfa hoje cedo.

ótimo, consertei

@pweil- Os documentos estão prontos? Atualize os documentos para https://github.com/kubernetes/kubernetes.github.io e adicione números de PR e marque a caixa de documentos na descrição do problema

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

edit: https://github.com/kubernetes/kubernetes.github.io/pull/1206 é o 1.4 PR correto

cc @kubernetes/feature-reviewers

@pweil- suponho que este PR é real - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

correto

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

Evite o fechamento automático de problemas com um comentário /lifecycle frozen .

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

Envie feedback para sig-testing, kubernetes/test-infra e/ou @fejta .
/ciclo de vida obsoleto

trabalho está acontecendo em 1.10 para mover o PSP para seu grupo de API sem extensões
cc @php-coder

Atualizações do documento @erictune , por favor? Consulte também [a planilha de rastreamento de recursos 1.10[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). lmk se você tiver alguma dúvida. Precisamos que um PR de documentos seja revisado e mesclado até 9/3. Obrigado!

@php-coder ^

@Bradamant3 @liggitt Quais atualizações de documentos são necessárias?

Para as alterações relacionadas à transição do grupo de API, enviei: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 e https:// /github.com/kubernetes/examples/pull/208

Eu não sou o dono certo das atualizações do PSP Doc.

Em sex, 2 de março de 2018 às 11h26, Vyacheslav Semushin <
[email protected]> escreveu:

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt Quais atualizações de documentos são necessárias?

Para as alterações relacionadas à transição do grupo de APIs, enviei:
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
e kubernetes/examples#208
https://github.com/kubernetes/examples/pull/208

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

Isso é tudo que precisamos. Eu adicionei o PR à planilha de acompanhamento. Obrigado!

@php-coder @liggitt @tallclair
Algum plano para isso em 1.11?

Em caso afirmativo, você pode garantir que o recurso esteja atualizado com o apropriado:

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

cc @idvoretskyi

@php-coder Você pode responder ao comentário do @justaugustus com o trabalho que está fazendo aqui? Existem outras alterações além da movimentação do grupo de políticas?

Existem outras alterações além da movimentação do grupo de políticas?

Não, só trabalhei nisso.

Espero que @liggitt atualize a descrição quando tiver tempo (porque não tenho permissões apropriadas).

Feito.

@tallclair apenas para esclarecer, estamos rastreando estável como o alvo para 1.11, correto?
Atualizei o rótulo, só quero ter certeza.

Não, isso ainda será beta. Não tenho certeza se PodSecurityPolicy algum dia irá para estável (ou seja, será substituído por outra coisa), mas outros podem discordar de mim sobre isso.

Entendi. Obrigado pela atualização, @tallclair!

@justaugustus Vou remover isso do marco 1.11, pois não haverá progresso significativo na versão atual.

Nenhuma atualização planejada para 1.12

@tallclair eu posso conseguir os botões RunAsGroup PSP em 1.12

Confirmar Isso ainda estará em beta embora. No momento não há planos para a PSP ir para GA. Existem alguns problemas importantes de usabilidade que precisam ser resolvidos antes de avançarmos com isso. (consulte https://github.com/kubernetes/kubernetes/issues/60001 e https://github.com/kubernetes/kubernetes/issues/56174)

/desatribuir

/atribuir @tallclair

Oi
Esse aprimoramento já foi rastreado antes, então gostaríamos de verificar se há algum plano para isso para graduar estágios no Kubernetes 1.13. Esta versão visa ser mais 'estável' e terá um cronograma agressivo. Por favor, inclua este aprimoramento apenas se houver um alto nível de confiança de que ele cumprirá os seguintes prazos:

• Documentos (RPs de espaço reservado aberto): 8/11
• Código Slush: 9/11
• Início do congelamento de código: 15/11
• Documentos concluídos e revisados: 27/11

Reserve um momento para atualizar os marcos em sua postagem original para rastreamento futuro e ping @kacole2 se precisar ser incluído na 1.13 Folha de acompanhamento de aprimoramentos

Obrigado!

Nenhuma mudança planejada em 1.13.

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

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

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

@tallclair Olá - sou o líder do aprimoramento para 1.14 e estou verificando esse problema para ver qual trabalho (se houver) está sendo planejado para a versão 1.14. O congelamento de aprimoramentos é em 29 de janeiro e quero lembrar que todos os aprimoramentos devem ter um KEP

Nada planejado para 1.14.

Quais são as lacunas para que isso seja GA? Posso pensar em poucos, mas não vejo nenhum critério na descrição.

Antes que isso possa ir para o GA, precisamos corrigir estes problemas:

1. Modelo de autorização falho - o uso do PSP é concedido por meio do RBAC e pode ser concedido ao usuário ou ao pod criado. Conceder ao usuário é a abordagem intuitiva, mas é problemática (ver explicação). Essa abordagem também tem alguns problemas de segurança.
2. Difícil de implantar - Como os pods são rejeitados por padrão, não podemos implantar o PSP em todos os clusters sem quebrá-los. Da mesma forma, os usuários que desejam habilitar o PSP precisam garantir a cobertura completa de todas as cargas de trabalho antes de ativá-lo, o que dificulta a habilitação (daí o uso relativamente baixo). Como o recurso deve ser ativado explicitamente, não temos cobertura de teste adequada (a matriz de recursos é muito complexa).
3. API inconsistente - Menos de um problema fundamental, mas a evolução da API PSP ao longo de um longo período de lançamentos do k8s levou a várias inconsistências, dificultando o uso. Em particular, a mutação é agrupada com a validação, o que pode levar a alguns resultados inesperados quando um pod tem acesso a vários PSPs.

@liggitt e eu temos algumas ideias sobre como resolver isso, mas há uma questão em aberto sobre se isso pertence ao núcleo do Kubernetes. Eu gostaria de ter um roteiro para o próximo mês, seja um plano para ir para o GA ou um plano para suspensão de uso.

Obrigado por compartilhar as informações!

Como os pods são rejeitados por padrão, não podemos implantar o PSP em todos os clusters sem quebrá-los.

Acho que não é bem isso. Fizemos isso criando um PodSecurityPolicy que é aberto o suficiente (ou mesmo aberto tudo) primeiro e depois refinando isso gradualmente.

@zhouhaibing089 um usuário do Kubrenetes pode usar esse método que funciona porque controla as políticas. No entanto, não podemos implementar isso como um padrão do Kubernetes, pois o PodSecurityPolicy apenas abre o cluster, o que significa que é muito difícil gerenciar o PSP de permissão para todos controlado pelo sistema.

Olá @liggitt @tallclair , sou o líder de aprimoramento para 1.15. Esse recurso estará graduando os estágios alfa/beta/estável na versão 1.15? Por favor, avise-me para que possa ser rastreado corretamente e adicionado à planilha. A proposta da comunidade precisará ser migrada para um KEP para inclusão em 1.15.

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

Nenhuma mudança planejada para 1.15

@tallclair Adoraria ver esta terra como GA em 1.16. Isso é possível?

@lachie83 Não, não temos certeza se queremos que o PodSecurityPolicy vá para o GA. Não está claro se este é um caso de uso que deve ser resolvido pelo núcleo do Kubernetes, e estamos procurando alternativas fora do núcleo. Se você quiser discutir isso com mais detalhes, é um bom tópico para o SIG-Auth.

@tallclair Coisas como o gatekeeper do Open Policy Agent seriam um caminho melhor para descer?

Sim, exatamente. Esse pode ser o principal concorrente, e estou trabalhando em estreita colaboração com essa equipe para garantir que ela abranja esses casos de uso.

A única coisa que eu estava esperando, é uma ferramenta que poderia traduzir PodSecurityPolicy --> OPA rego policy. Isso tornaria muito mais fácil depreciá-los do seu ponto de vista.

@tallclair agradecemos a pronta resposta

@SEJeff concordou. Não descontinuaremos o PodSecurityPolicy até que haja uma substituição clara com paridade de recursos e caminho de migração.

Ei @tallclair , você mencionou um roteiro para o GA ou um plano para suspensão de uso. Parece que estamos inclinados para o último.

Temos algo escrito para ajudar as pessoas que estão olhando para os PSPs como uma solução a fechar o ciclo?

Ainda não. Parte da hesitação é que não queremos dizer que vamos depreciá-lo em favor de outra coisa até que haja uma substituição clara. Embora eu esteja empolgado com o gatekeeper, ele ainda não tem os recursos (ou estabilidade) que precisamos para substituir o PSP. Outra possibilidade é que pudéssemos tirar o PSP da árvore e trazê-lo para o GA como um webhook de admissão (as 2 opções não são mutuamente exclusivas). Ainda não estabelecemos formalmente um roteiro.

Wtf

Oi @tallclair parece que nada está acontecendo aqui para 1.16 também, então vou manter o mesmo.

Olá @tallclair -- 1.17 Lead de aprimoramento aqui -- parece que isso vai ficar como está para 1.17. Se isso mudar, não hesite em me dar um cutucão e posso adicioná-lo à folha de rastreamento 👍

Houve mais discussão sobre um caminho claro para o futuro da PSP?

Sim, exatamente. Esse pode ser o principal concorrente, e estou trabalhando em estreita colaboração com essa equipe para garantir que ela abranja esses casos de uso.

@tallclair - implementamos a maioria das verificações de PSP em Kyverno. Você pode ajudar a dar uma olhada? Gostaria de discutir ideias e detalhes.

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

O projeto Gatekeeper também está analisando como seria um mundo pós-PSP. Nossa abordagem inicial foi dividir o recurso PSP em restrições individuais . Estávamos imaginando quais eram os pensamentos da comunidade sobre essa abordagem. Talvez seja um bom momento para repensar como essas políticas se compõem? A migração para novos usuários e usuários de PSP existentes também será importante.

cc @maxsmythe @sozercan @tsandall

Tenho algumas preocupações sobre dividir as políticas em restrições individuais, ou seja, preciso criar muito mais objetos de restrição. Se eu achar que preciso clonar ou alterá-los para diferentes cargas de trabalho, estou preocupado que isso se torne muito complexo.

Acho que a melhor abordagem seria centrada no usuário. Se pudermos obter feedback real sobre como os PSPs estão sendo usados ​​e ver como seria uma configuração semelhante nesses plugins alternativos, isso pode ajudar a moldar o design.

@tallclair um dos casos de uso que estamos buscando está relacionado à multilocação baseada em namespace. A intenção é usar políticas para impor restrições e garantir que os namespaces sejam configurados corretamente.

Antes que isso possa ir para o GA, precisamos corrigir estes problemas:

1. Modelo de autorização falho - o uso do PSP é concedido por meio do RBAC e pode ser concedido ao usuário ou ao pod criado. Conceder ao usuário é a abordagem intuitiva, mas é problemática (ver explicação). Essa abordagem também tem alguns problemas de segurança.

@tallclair , estou me perguntando sobre o acima - você pode explicar como essa abordagem é problemática e/ou tem problemas de segurança?

Alguém mais informado pode confirmar este tweet:

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

E se isso for verdade, o que as pessoas que usam o PSP para limitar os recursos do Linux hoje devem fazer daqui para frente?

Olá a todos,
Esta é uma discussão muito interessante e atualmente estamos procurando soluções para proteger a criação de Pods em clusters Kubernetes.

Demos uma olhada no OPA Gatekeeper e no PodSecurityPolicies, bem como o esforço para reimplementar o PSP nas restrições do OPA.
A questão fundamental que encontramos com essa comparação é que estamos lidando com dois modelos opostos.

• O OPA Gatekeeper segue o modelo open-by-default, no qual tudo é permitido e o administrador proíbe certas coisas com restrições.
• O PSP segue o modelo closed-by-default, no qual tudo é proibido e o admin permite certas coisas com políticas.

Do ponto de vista da segurança, eu diria que o modelo PSP é melhor, embora mais difícil de trazer para os clusters existentes, pois todas as cargas de trabalho devem estar em conformidade com ele.

Como você planeja preencher essa lacuna fundamental na arquitetura, entre o PSP e o Constraint Framework?

/cc @ritazh Eu adoraria ouvir sua opinião sobre isso, já que você trabalhou na portabilidade da funcionalidade do PSP para o OPA.

As diferentes abordagens definitivamente tornam a migração mais complicada. Estamos explorando diferentes maneiras de tornar a transição mais suave.

Em um mundo perfeito, concordo que negar tudo por padrão é a abordagem mais segura. No entanto, é uma das coisas que torna o PSP tão difícil de usar e implantar. Na prática, acho que diminuir gradualmente as permissões é mais viável e, como diz o velho ditado, "a melhor segurança é a segurança que você usa".

Em uma nota lateral, também estamos discutindo como desativar/excluir/obter exceções para restrições (por exemplo, para proteger o namespace kube-system). Dependendo de como isso funciona, você pode implementar uma abordagem de negação por padrão bloqueando tudo e, em seguida, concedendo exceções. Não tenho certeza se esse é um caso de uso para o qual queremos projetar ...

@tallclair você espera algum progresso nisso em 1.18? Eu sou uma sombra de aprimoramentos para o lançamento e gostaria de saber se devemos acompanhar isso.

Nenhuma mudança planejada para 1.18

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

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

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

@tallclair Olá, Tim. Algum plano para isso em 1.19?

Não há planos para a v1.19, embora eu espere ver algum movimento no prazo da v1.20.

Acabei de encontrar as Políticas de segurança do pod do Kubernetes com o Open Policy Agent . @tallclair você pode compartilhar o que está nos bloqueando e onde a ajuda é necessária, feliz em contribuir também.

você pode compartilhar o que está nos bloqueando

Basicamente, só precisamos tomar uma decisão sobre um caminho a seguir. Atualmente, acho que há um acordo de que o PSP não deve ser GA em sua forma atual, mas ainda não decidimos uma substituição. Opções que discutimos:

1. Sem substituição - recomendamos escolher uma opção de terceiros com um webhook de admissão. O documento de padrões de segurança do Pod recentemente publicado está tentando tornar isso mais suave, promovendo uma funcionalidade equivalente.
2. Controles integrados alternativos
   
   
   
   1. @deads2k propôs upstreaming de turnos abertos SecurityContextConstraints
   
   
   2. Propus um recurso minimamente configurável que aplica apenas as políticas padrão vinculadas acima (e recomendo uma solução de terceiros quando for necessária mais configurabilidade)
   
   
3. Corrigir a política de segurança do pod - Embora alguns dos problemas sejam essenciais o suficiente para o design, isso precisaria ser não compatível com versões anteriores, ponto em que poderia ser uma nova alternativa em (2)

Estou lendo https://github.com/kubernetes/kubernetes/pull/90603 corretamente que, como os padrões de segurança do pod são publicados, não há substituição planejada para PSPs no servidor de API e qualquer substituição precisará ser implementada como um sistema externo?

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

O cronograma de descontinuação para a versão beta atual em 1.22 é independente se uma implementação em árvore dos perfis de segurança de pod padrão será fornecida ou não. Isso ainda não foi determinado.

Obrigado @liggitt estava confirmando que nada havia sido definido. pensava originalmente que nada seria obsoleto até que um substituto estivesse disponível. Não ficou claro se uma decisão foi tomada de uma forma ou de outra.

A linha do tempo de descontinuação não é específica para PSP e foi adicionada como parte de https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

se estou lendo isso corretamente, o que está empurrando a descontinuação é que nenhuma API deve estar na mesma versão beta por mais de 9 meses, então o PSP precisa ser promovido ou preterido e, como não haverá novos betas ou GA do psp ele precisa entrar no caminho certo para a descontinuação, mesmo que uma substituição não tenha sido decidida?

se estou lendo isso corretamente, o que está empurrando a depreciação é que nenhuma API deve estar na mesma versão beta por mais de 9 meses

exatamente. todas as versões beta futuras de todas as APIs integradas virão com um destino de descontinuação e remoção pré-preparados quando forem introduzidas pela primeira vez

Olá @tallclair

Melhorias Lidere aqui. Algum plano para isso em 1.20?

Obrigado,
Kirsten

Não há planos para v1.20.

Essa situação é extremamente frustrante para aqueles que precisam executar clusters de alta segurança. Nossas opções são:

1. Sente-se e espere que os PSPs sejam preteridos.
2. Terceirize a aplicação da segurança do tempo de execução da carga de trabalho para um fornecedor (Styra), pois o OPA não documenta como executar uma substituição de PSP totalmente restritiva com o Rego.

Então, minha empresa implementou PSPs totalmente bloqueados. Eles não são fáceis de implementar e depurá-los é uma tarefa árdua, mas são altamente funcionais e realmente funcionam. Até publicamos uma postagem no blog detalhando como eles podem ser usados ​​dessa maneira e como lidar com exceções quando elas acontecem.

IMO, o PSP beta deve ser mesclado como está no núcleo principal do kubernetes. Meus motivos são:

1. Embora os PSPs tenham falhas, eles funcionam e funcionaram por 10 versões.
2. O Kubernetes como um projeto deve se preocupar com a segurança do tempo de execução da carga de trabalho. As fugas de contêineres são fáceis demais. Os PSPs são uma das poucas ferramentas que tornam isso mais difícil para os invasores.
3. Perfeito é inimigo do Feito. Mescle os PSPs como estão e empurre a implementação "melhor" para a política/v2.
4. Finalmente, e mais importante, ele permite que desenvolvedores de OSS executem clusters de segurança mais alta, não apenas empresas que podem pagar fornecedores como Styra.

@zapman449 você pode esclarecer o que quer dizer com uma "substituição totalmente restritiva do PSP"?

Espero que a biblioteca Gatekeeper PSP facilite a aplicação de regras semelhantes às usadas pelo PSP. Estou definitivamente interessado em quaisquer lacunas funcionais que você esteja vendo.

@zapman449 você teria um link para essa postagem no blog?

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

@maxsmythe Não entendi o que o Gatekeeper PSP está fazendo, vou revisar.

No entanto, o que quero dizer é:

1. Controle total sobre recursos de processo como NET_BIND_SERVICE, SYS_ADMIN, etc.
2. Restringir UID/GID/FSGroups a valores diferentes de zero
3. Listagem explícita de caminhos de host que podem ser montados
4. Listagem explícita de tipos de montagens de volume permitidas
5. Bloquear Privilegiados, bloquear escalonamento de privilégios
6. Bloquear o acesso às primitivas de comunicação entre processos no nível do host
7. Bloquear o acesso à rede do host
8. restringir quais portas de host são permitidas
9. Aplicar readOnlyRootFilesystem
10. Ponto de conexão para SELinux

Estes são fornecidos hoje com PSPs.

Se estamos pedindo uma lista de desejos, eu adoraria:

1. Padrões inteligentes para SysCalls de contêineres. Há uma pequena porcentagem da lista total de syscalls do linux que a maioria dos contêineres precisa. Deixe-me restringir a maioria dos contêineres a essa lista e permitir explicitamente determinadas chamadas para determinados pods pertencentes a determinadas contas de serviço ou conceder carta branca a contas de serviço específicas.
2. Deixe-me sonhar um pouco mais, e eu vou inventar algo. ;-)

@zapman449 - Se você não viu, discutimos o futuro dos PSPs na última reunião sig-auth (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u ). Continuaremos a discussão na reunião de 9 de dezembro, se você puder, mas também não tomaremos nenhuma decisão final sem que uma proposta seja enviada à lista de discussão.

Nossa intenção aqui é absolutamente não deixar ninguém na mão. Sabemos que os PSPs atendem a uma importante necessidade de segurança para o Kubernetes, e o objetivo dessas discussões é descobrir qual é a melhor maneira de atender a essas necessidades no futuro.