Introdução  À medida que o Kubernetes continua a amadurecer como plataforma líder de orquestração de contêineres, a segurança continua sendo uma preocupação primordial para as organizações que implantam aplicativos em contêineres. Entre as ferramentas fundamentais do arsenal de segurança do Kubernetes,   já desempenharam um papel fundamental. O PSP permitiu que os administradores definissem e aplicassem meticulosamente restrições de segurança nos pods, garantindo que apenas contêineres que atendessem a padrões de segurança específicos pudessem operar no cluster.  No entanto, o cenário da segurança do Kubernetes está evoluindo rapidamente e é importante observar que o PSP agora foi descontinuado, começando com o Kubernetes 1.25 (consulte o link para as notas de lançamento urgente do Kubernetes 1.25). Esta mudança decorre de vários fatores, incluindo a complexidade de gestão e manutenção das políticas de PSP, muitas vezes conduzindo a desafios operacionais para os utilizadores.  Em resposta à suspensão de uso, as organizações estão agora procurando alternativas modernas ao PSP, que não apenas atendam aos requisitos de segurança, mas também simplifiquem o processo de proteção de cargas de trabalho no   .  Neste guia abrangente, embarcamos em uma jornada para navegar nessa mudança nas práticas de segurança do Kubernetes, com foco na transição para Pod Security Admission (PSA). PSA é uma das alternativas mais robustas disponíveis e este artigo a explora em profundidade. No entanto, vale a pena mencionar que duas outras alternativas, Kyverno e OPA Gatekeeper, serão abordadas em artigos separados desta série.  Ao longo deste artigo, você encontrará instruções detalhadas para configurar e instalar o PSA, guias de migração passo a passo para fazer a transição do PSP para o PSA sem problemas e comandos precisos para transferir regras existentes do PSP para o PSA. Além disso, você obterá conhecimento para avaliar namespaces quanto à prontidão para migração usando comandos de simulação personalizados para PSA.  Ao final deste guia, você obterá uma compreensão abrangente dos pontos fortes e limitações do PSA, capacitando-o para tomar uma decisão informada com base nos requisitos de segurança específicos da sua organização e no ambiente Kubernetes.  Com este guia, você pode modernizar com segurança suas práticas de segurança do Kubernetes, garantindo que suas cargas de trabalho permaneçam protegidas enquanto você se despede da era das políticas de segurança de pod. as Políticas de Segurança de Pod (PSP) Kubernetes  Admissão de segurança do pod (PSA)    o PSA garante que os contêineres cumpram os padrões de segurança nativos do Kubernetes, que são definidos pelos padrões de segurança do pod. Esses padrões classificam as políticas de segurança em três perfis distintos, cada um com um nível diferente de restritividade: PSA impõe padrões de segurança do Kubernetes:    : A política Privilegiada é intencionalmente aberta e totalmente irrestrita. Normalmente, esta política visa cargas de trabalho em nível de sistema e infraestrutura gerenciadas por usuários confiáveis. Caracteriza-se pela ausência de restrições. Embora mecanismos permitidos por padrão, como o Gatekeeper, possam ser inerentemente privilegiados, para mecanismos negados por padrão, como a Política de Segurança de Pod (PSP), a política Privilegiada deve desativar todas as restrições. Privilegiado    : a política de linha de base foi projetada para fácil adoção por cargas de trabalho conteinerizadas comuns, evitando escalonamentos de privilégios conhecidos. Ele atende operadores de aplicativos e desenvolvedores de aplicativos não críticos. Linha de base    : a política Restrita se concentra na aplicação de práticas recomendadas rigorosas de proteção de pod, embora às custas potenciais de alguma compatibilidade. Destina-se principalmente a operadores e desenvolvedores de aplicativos críticos para a segurança, bem como a usuários de menor confiança. Para obter uma lista abrangente de controles que devem ser aplicados ou proibidos em cada perfil, consulte a documentação oficial. Restrito    ao contrário de algumas outras soluções, o PSA não oferece um método direto para migrar ou modificar diretamente as regras da política de segurança do pod (PSP). O foco principal do PSA é validar pods em relação aos   , incluindo os perfis mencionados acima. Sem transferência direta de regras do PSP: padrões de segurança estabelecidos do Kubernetes    : Embora o PSA seja eficaz na validação, ele não pode modificar ou personalizar as especificações do pod como o PSP poderia. O principal objetivo do PSA é impor padrões de segurança predefinidos do Kubernetes e não inclui recursos para alterar ou modificar especificações de pod. Ele se concentra principalmente na validação de pods em relação a esses padrões estabelecidos. Sem mutações   Configuração e instalação  Como o PSA é um componente nativo do Kubernetes, para fazê-lo funcionar, você só precisa garantir que o controlador Pod Security Admission (PSA) esteja habilitado em seu cluster Kubernetes. Você pode fazer isso executando o seguinte comando:   kubectl api-versions | grep admission   Etapas de preparação para migração   Avaliar permissões de namespace  O controle da admissão de segurança do pod é influenciado pelos rótulos de namespace. Isso implica que indivíduos com capacidade de atualizar, corrigir ou criar namespaces também têm autoridade para modificar as configurações de segurança do pod para esses namespaces. Esta modificação poderia potencialmente contornar políticas de segurança mais rigorosas. Antes de prosseguir, é essencial verificar se as permissões de namespace são atribuídas exclusivamente a usuários confiáveis e privilegiados. É aconselhável abster-se de conceder essas permissões elevadas a usuários que não necessitam desse acesso. Se forem necessárias restrições adicionais para configurar rótulos de segurança de pod em objetos de namespace, considere utilizar um webhook de admissão para impor essas restrições.   Simplifique e normalize PodSecurityPolicies  Antes de migrar para o Pod Security Admission (PSA), é benéfico normalizar seu PodSecurityPolicies (PSP):    : elimine opções não cobertas pelos padrões de segurança do pod. Essas opções incluem: Remover campos não suportados   .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass    : inicie o processo removendo campos que tenham apenas efeito mutante e não afetem a política de validação. Esses campos, conforme também mencionado na referência "Mapeando PodSecurityPolicies para padrões de segurança de pod", incluem: Elimine campos puramente mutantes   .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities  Nota importante:  A remoção destes campos pode fazer com que as cargas de trabalho não tenham as configurações necessárias, o que pode causar problemas operacionais. É crucial garantir que as cargas de trabalho possam funcionar corretamente com as políticas simplificadas.   Determine o nível de segurança adequado do pod  Ao determinar o nível de segurança do pod apropriado para seu namespace, você deve considerar vários métodos:   Por requisitos de segurança para o namespace  Se você estiver familiarizado com o nível de acesso e os requisitos de segurança esperados para o namespace, poderá selecionar um nível de segurança de pod apropriado com base nesses requisitos específicos. Esta abordagem é semelhante à forma como você abordaria as configurações de segurança em um novo cluster.   Por PodSecurityPolicies existentes:  Utilize a referência   para mapear cada uma de suas políticas de segurança de pod (PSPs) existentes para um nível de padrão de segurança de pod correspondente.  Se seus PSPs não forem originalmente baseados nos padrões de segurança de pod, talvez você precise tomar uma decisão. Escolha um nível de segurança de pod que seja pelo menos tão permissivo quanto seus PSPs ou opte por um nível que seja pelo menos tão restritivo. Para identificar quais PSPs estão em uso para pods em um namespace específico, use o seguinte comando: "Mapeando PodSecurityPolicies para padrões de segurança de pod"   kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u   Por pods existentes:  Realize uma simulação e aplique o comando label da próxima seção para testar os níveis de linha de base e de segurança do pod restrito. Isto ajuda-o a avaliar se estes níveis são suficientemente permissivos para as suas cargas de trabalho existentes. Escolha o nível válido com menos privilégios que se alinhe às suas cargas de trabalho existentes.  É importante observar que as opções mencionadas são baseadas em pods existentes, que podem não levar em conta cargas de trabalho que não estão em execução no momento. Isso inclui CronJobs, cargas de trabalho escaláveis ou outras cargas de trabalho que ainda não foram implantadas.  Testando o nível de segurança do pod  Depois de determinar o nível de segurança do pod para seu namespace (exceto para o nível Privilegiado), é importante validar a política escolhida. O Pod Security oferece opções de teste para garantir uma implementação tranquila e conformidade com os padrões de segurança.   Teste de funcionamento a seco:  Utilize este método para avaliar o impacto da política selecionada sem aplicação imediata.  Para realizar uma simulação, use o comando a seguir, que destacará todos os pods existentes que não atendem ao nível de política especificado:   kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL   Teste do modo de auditoria:  O modo de auditoria permite registrar violações de políticas sem aplicá-las. Os pods violados são registrados nos registros de auditoria para análise posterior. Habilite o modo de auditoria com o comando:   kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL  Se surgirem violações inesperadas da política durante os testes, você poderá:  Atualize cargas de trabalho não conformes para alinhar com a política.  Ajuste o nível de segurança do pod para o namespace, se necessário, para acomodar os requisitos da sua carga de trabalho.   Aplicando o nível de segurança do pod  Quando tiver certeza de que o nível de segurança do pod selecionado é apropriado para seu namespace, você poderá aplicá-lo. Esta etapa garante que os padrões de segurança desejados sejam aplicados ativamente às suas cargas de trabalho no namespace.  Para aplicar o nível de segurança do pod desejado no namespace, use o seguinte comando:   kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL  A execução deste comando ativará e aplicará o nível de segurança do pod especificado, melhorando a postura de segurança do seu namespace.   Ignorando o PSP     Para ignorar efetivamente o PodSecurityPolicy no nível do namespace, você pode vincular uma política de segurança de pod (PSP) totalmente privilegiada a todas as contas de serviço no namespace. Esse processo garante que os pods no namespace não estejam mais sujeitos a modificações ou restrições impostas pelo PodSecurityPolicy. Você pode fazer isso em nível de cluster ou em nível de namespace individual. Configuração com escopo de cluster (necessária apenas uma vez para todo o cluster):  Crie uma política de segurança de pod (PSP) totalmente privilegiada aplicando um arquivo de configuração YAML, como   . Este PSP deve conceder todos os privilégios necessários aos pods e criar uma função de cluster chamada psp privilegiada para permitir o uso de políticas de segurança de pod (PSPs) e associá-la ao PSP privilegiado: privilégiod-psp.yaml   kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged   Desativação por namespace:  Crie uma ligação de função no namespace de destino para associar a função de cluster psp privilegiada ao grupo   . Essa ligação concede efetivamente a todas as contas de serviço no namespace acesso ao PSP totalmente privilegiado, ignorando PodSecurityPolicy: system:serviceaccounts:$NAMESPACE   kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE  Com esta configuração, o PSP privilegiado não sofre mutação e o controlador de admissão PodSecurityPolicy sempre prioriza PSPs sem mutação. Como resultado, os pods neste namespace não serão mais modificados ou restringidos pelo PodSecurityPolicy.  Uma vantagem desta abordagem é a sua reversibilidade. Se surgir algum problema, você pode reverter facilmente a alteração excluindo o RoleBinding associado à desativação do PodSecurityPolicy. Certifique-se de que as políticas de segurança de pod pré-existentes permaneçam em vigor durante esse processo.   Desfazer a desativação do PodSecurityPolicy:  Para reverter a desativação do PodSecurityPolicy para o namespace, basta excluir o RoleBinding criado anteriormente:   kubectl delete -n $NAMESPACE rolebinding disable-psp   Revisite os processos de criação de namespace  Com os namespaces existentes atualizados para impor a admissão de segurança do pod, é essencial revisar e atualizar seus processos e políticas para a criação de novos namespaces. Isso garante que os novos namespaces sejam configurados com um perfil de segurança de pod apropriado desde o início.  Considere as seguintes etapas para aprimorar os processos de criação de namespace:    : atualize as políticas e os procedimentos da sua organização para a criação de novos namespaces para incluir a seleção e a aplicação do nível de segurança de pod desejado. Garanta que os padrões de segurança sejam estabelecidos desde a fase de criação. Ajuste as políticas de criação de namespaces    você pode configurar estaticamente o controlador de admissão do Pod Security para definir níveis padrão de aplicação, auditoria e/ou aviso para namespaces não rotulados. Essa abordagem garante que os namespaces sem rótulos explícitos de segurança de pod ainda sigam os padrões de segurança especificados por padrão. Configuração estática:  Ao revisitar seus processos de criação de namespace, você pode integrar perfeitamente os padrões de segurança de pod ao   e manter uma abordagem consistente e segura em todos os namespaces, antigos e novos. seu ambiente Kubernetes  Desativar PodSecurityPolicy  Quando tiver certeza de que o controlador de admissão PodSecurityPolicy (PSP) não é mais necessário e que o Pod Security Admission (PSA) foi implementado e validado com êxito, você poderá desativar o controlador de admissão PSP.  Aqui estão as etapas para desativar o controlador de admissão PSP:  Modifique a configuração do kube-apiserver:  Abra o arquivo de configuração do seu kube-apiserver, normalmente localizado em  /etc/kubernetes/manifests/kube-apiserver.yaml.  Adicione o sinalizador   para desabilitar o controlador de admissão PSP. Certifique-se de que ele seja removido da lista de plug-ins de admissão ativos. --disable-admission-plugins   kube-apiserver --disable-admission-plugins=PodSecurityPolicy  Salve o arquivo de configuração.   Reinicie o kube-apiserver:  Reinicie o kube-apiserver para aplicar as alterações. Geralmente, você pode conseguir isso reiniciando o plano de controle do Kubernetes ou o próprio pod kube-apiserver.   systemctl restart kubelet   Verificação:  Certifique-se de que o controlador de admissão PSP esteja desabilitado verificando os logs do kube-apiserver ou seu status.  Depois de “tempo de absorção” suficiente para ter certeza de que não será necessário reverter para PSPs, prossiga para a próxima etapa.  Limpar recursos do PSP:  Com o controlador de admissão PSP desativado e o PSA instalado, você pode excluir com segurança seus PodSecurityPolicies existentes, bem como quaisquer funções, ClusterRoles, RoleBindings e ClusterRoleBindings associados.   kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true  Esta etapa de limpeza garante que não haja configurações residuais de PSP em seu cluster.  Ao desativar o controlador de admissão do PSP e eliminar recursos relacionados ao PSP, você simplifica a arquitetura de segurança do seu cluster, concluindo a transição para o Pod Security Admission.   Resumo  Neste guia abrangente, exploramos as etapas e considerações essenciais para fazer uma transição tranquila da   políticas de segurança de pod (PSP) para admissão de segurança de pod (PSA). Essa migração garante que suas cargas de trabalho continuem sendo executadas com segurança, alinhando-se com os padrões de segurança em evolução do Kubernetes. estrutura de segurança do cluster Kubernetes de  Prós e contras do uso do Pod Security Admission (PSA)   Prós:    : PSA é parte integrante do Kubernetes, eliminando a necessidade de instalações de ferramentas de terceiros. Ele aproveita os recursos de segurança integrados da plataforma. Componente nativo do Kubernetes    : o PSA se alinha aos padrões de segurança nativos do Kubernetes, garantindo a conformidade com as melhores práticas da plataforma. Aplica os padrões do Kubernetes   Contras:    : o PSA pode não fornecer o mesmo nível de personalização que o PSP, especialmente para políticas de segurança complexas que exigem mutação nas especificações do pod. Personalização limitada    : as cargas de trabalho existentes devem ser atualizadas para incluir configurações de contexto de segurança, o que pode exigir modificação de arquivos YAML. Atualização necessária  Este guia fornece o conhecimento e as etapas necessárias para migrar com segurança do PSP para o PSA, garantindo uma transição segura e eficiente e ao mesmo tempo protegendo suas cargas de trabalho do Kubernetes. Fique ligado nos próximos artigos, onde explorarei caminhos alternativos de migração para Kyverno e OPA Gatekeeper.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

2022 - HackerNoon Contributor of the Year - Azure

2022 - HackerNoon Contributor of the Year - China

2022 - HackerNoon Contributor of the Year - Cicd

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Docker

2022 - HackerNoon Contributor of the Year - Kubernetes

2022 - HackerNoon Contributor of the Year - Serverless

2022 - Master On the Edge of Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Cicd

Nominated for 2022 - HackerNoon Contributor of the Year - Serverless

Nominated for 2022 - HackerNoon Contributor of the Year - Kubernetes

Nominated for 2022 - HackerNoon Contributor of the Year - China

Nominated for 2022 - HackerNoon Contributor of the Year - Azure

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Docker

Migrating from Pod Security Policies: A Comprehensive Guide (Part 1: Transitioning to PSA)

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Migração de políticas de segurança de pod: um guia abrangente (Parte 1: transição para PSA)

Migração de políticas de segurança de pod: um guia abrangente (Parte 1: transição para PSA)

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Modelo Bitcoin UTXO, alimentando um ecossistema único

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Modelo Bitcoin UTXO, alimentando um ecossistema único

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps