Ajudar a melhorar esta página
Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.
Migração de políticas de segurança de pod (PSP) herdadas
A PodSecurityPolicy
foi descontinuada no Kubernetes1.21
1.25
. Se você estiver usando o PodSecurityPolicy no cluster, deverá migrar para os padrões de segurança Pod do Kubernetes integrados (PSS), ou para uma solução de política como código, antes de atualizar o cluster para a versão1.25
, a fim de evitar interrupções nas workloads. Selecione qualquer pergunta frequente para saber mais.
O PodSecurityPolicy
Essa é uma mudança upstream no projeto do Kubernetes, e não uma mudança feita no Amazon EKS. O PSP foi descontinuado no Kubernetes 1.21
e removido no Kubernetes 1.25
. A comunidade Kubernetes identificou sérios problemas de usabilidade com o PSP. Isso incluiu a concessão acidental de permissões mais amplas do que o pretendido e a dificuldade de inspecionar quais PSPs se aplicam a uma determinada situação. Esses problemas não poderiam ser resolvidos sem fazer alterações significativas. Esse é o principal motivo pelo qual a comunidade Kubernetes decidiu remover o PSP
Para verificar se você está usando PSPs em seu cluster, execute o seguinte comando:
kubectl get psp
Para ver os Pods que o PSPs do cluster está afetando, execute o seguinte comando: Esse comando gera o nome do Pod, o namespace e o PSPs:
kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'
Antes de atualizar seu cluster para 1.25
, migre o PSPs para uma das seguintes alternativas:
Kubernetes PSS.
Soluções de política como código do ambiente do Kubernetes.
Em resposta à depreciação do PSP e à necessidade contínua de controlar a segurança do Pod desde o início, a comunidade Kubernetes criou uma solução integrada com o (PSS)
Você pode revisar as melhores práticas para migrar PSPs para as PSS incorporadas no Guia de melhores práticas do EKS
As soluções de política como código fornecem barreiras para orientar os usuários do cluster e evitam comportamentos indesejados por meio de controles automatizados prescritos. As soluções de política como código normalmente usam os Controladores de Admissão Dinâmicos do Kubernetes
Existem várias soluções de política como código de código aberto disponíveis para o Kubernetes. Para analisar as melhores práticas para migrar PSPs para uma solução de política como código, consulte a seção Política como código
Os clusters do Amazon EKS com a versão 1.13
do Kubernetes e posteriores têm uma política de segurança de PSP padrão denominada eks.privileged
. Essa política é criada em clusters 1.24
e anteriores. Não é usado no 1.25
e em clusters posteriores. O Amazon EKS migra automaticamente essa PSP para uma fiscalização baseada na PSS. Não é necessária nenhuma ação da sua parte.
Não. Além disso, eks.privileged
que é uma PSP criada pelo Amazon EKS, nenhuma alteração será feita a outras PSPs no cluster quando você fizer o upgrade para o 1.25
.
Não. O Amazon EKS não impedirá a atualização do cluster para a versão 1.25
se você ainda não tiver migrado da PSP.
Quando um cluster que contém a PSP é atualizado para o Kubernetes versão 1.25
, o servidor da API não reconhece o recurso PSP na versão 1.25
. Isso pode fazer com que os Pods obtenham escopos de segurança incorretos. Para obter uma lista completa de implicações, consulte Migrar da PodSecurityPolicy para o controlador de admissão PodSecurity integrado
Não esperamos nenhum impacto específico nas cargas de trabalho do Windows. PodSecurityContext tem um campo chamado windowsOptions
na API PodSpec v1
para Pods do Windows. Isso usa o PSS no Kubernetes 1.25
. Para obter mais informações e as práticas recomendadas para a imposição de PSS em workloads do Windows, consulte o Guia de práticas recomendadas do EKS