As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Contextos de segurança do pod **As Políticas de Segurança do Pod (PSP)** e os **Padrões de Segurança do Pod (PSS)** são duas formas principais de reforçar a segurança no Kubernetes. Observe que PodSecurityPolicy está obsoleto a partir do Kubernetes v1.21 e será removido na v1.25. O Pod Security Standard (PSS) é a abordagem recomendada pelo Kubernetes para reforçar a segurança no futuro. A Política de Segurança do Pod (PSP) é uma solução nativa no Kubernetes para implementar políticas de segurança. O PSP é um recurso em nível de cluster que controla aspectos sensíveis à segurança da especificação do Pod. Usando a Política de Segurança do Pod, você pode definir um conjunto de condições que os pods devem atender para serem aceitos pelo cluster. O recurso PSP está disponível desde os primórdios do Kubernetes e foi projetado para impedir que pods mal configurados sejam criados em um determinado cluster. [Para obter mais informações sobre as políticas de segurança do Pod, consulte a documentação do Kubernetes.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) De acordo com a [política de descontinuação do Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/), as versões mais antigas deixarão de receber suporte nove meses após a descontinuação do recurso. Por outro lado, os Padrões de Segurança do Pod (PSS), que são a abordagem de segurança recomendada e normalmente implementados usando contextos de segurança, são definidos como parte das especificações do pod e do contêiner no manifesto do pod. O PSS é o padrão oficial que a equipe do projeto Kubernetes definiu para abordar as melhores práticas relacionadas à segurança para pods. Ele define políticas como linha de base (minimamente restritiva, padrão), privilegiada (irrestritiva) e restrita (mais restritiva). Recomendamos começar com o perfil básico. O perfil básico do PSS fornece um equilíbrio sólido entre segurança e potencial atrito, exigindo uma lista mínima de exceções e serve como um bom ponto de partida para a segurança da carga de trabalho. Se você estiver usando atualmente, PSPs recomendamos mudar para o PSS. [Mais detalhes sobre as políticas do PSS podem ser encontrados na documentação do Kubernetes.](https://kubernetes.io/docs/concepts/security/pod-security-standards/) [Essas políticas podem ser aplicadas com várias ferramentas, incluindo as da [OPA e da Kyverno](https://www.openpolicyagent.org/).](https://kyverno.io/) [Por exemplo, o Kyverno fornece a coleção completa de políticas de PSS aqui.](https://kyverno.io/policies/pod-security/) As configurações de contexto de segurança permitem conceder privilégios para selecionar processos, usar perfis de programas para restringir recursos a programas individuais, permitir escalonamento de privilégios, filtrar chamadas do sistema, entre outras coisas. Os pods do Windows no Kubernetes têm algumas limitações e diferenciais das cargas de trabalho padrão baseadas em Linux quando se trata de contextos de segurança. O Windows usa um objeto Job por contêiner com um filtro de namespace do sistema para conter todos os processos em um contêiner e fornecer isolamento lógico do host. Não há como executar um contêiner do Windows sem a filtragem de namespace em vigor. Isso significa que os privilégios do sistema não podem ser declarados no contexto do host e, portanto, os contêineres privilegiados não estão disponíveis no Windows. A seguir `windowsOptions` estão as únicas opções documentadas [do Contexto de Segurança do Windows, enquanto as demais são opções](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#windowssecuritycontextoptions-v1-core) gerais do [Contexto de Segurança](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#securitycontext-v1-core). Para obter uma lista dos atributos de contexto de segurança que são suportados no Windows versus Linux, consulte a documentação oficial [aqui](https://kubernetes.io/docs/setup/production-environment/windows/_print/#v1-container). As configurações específicas do pod são aplicadas a todos os contêineres. Se não for especificado, as opções do PodSecurityContext serão usadas. Se definido em SecurityContext e PodSecurityContext, o valor especificado em SecurityContext tem precedência. Por exemplo, a configuração de runAsUser nome para pods e contêineres, que é uma opção do Windows, é um equivalente aproximado da runAsUser configuração específica do Linux e, no manifesto a seguir, o contexto de segurança específico do pod é aplicado a todos os contêineres. ``` apiVersion: v1 kind: Pod metadata: name: run-as-username-pod-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo nodeSelector: kubernetes.io/os: windows ``` Já a seguir, o contexto de segurança em nível de contêiner substitui o contexto de segurança em nível de pod. ``` apiVersion: v1 kind: Pod metadata: name: run-as-username-container-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo .. securityContext: windowsOptions: runAsUserName: "ContainerAdministrator" nodeSelector: kubernetes.io/os: windows ``` Exemplos de valores aceitáveis para o campo runAsUser Nome: ContainerAdministrator, ContainerUser, NT AUTHORITY\$1 NETWORK SERVICE, NT AUTHORITY\$1 LOCAL SERVICE Geralmente, é uma boa ideia executar seus contêineres com ContainerUser pods do Windows. Os usuários não são compartilhados entre o contêiner e ContainerAdministrator o host, mas têm privilégios adicionais dentro do contêiner. Observe que há [limitações](https://kubernetes.io/docs/tasks/configure-pod-container/configure-runasusername/#windows-username-limitations) de nome de usuário que você deve conhecer. Um bom exemplo de quando usar ContainerAdministrator é definir PATH. Você pode usar a diretiva USER para fazer isso, assim: ``` USER ContainerAdministrator RUN setx /M PATH "%PATH%;C:/your/path" USER ContainerUser ``` Observe também que os segredos são escritos em texto não criptografado no volume do nó (em comparação com tmpfs/in-memory no Linux). Isso significa que você precisa fazer duas coisas + Use o arquivo ACLs para proteger a localização do arquivo secreto + Use criptografia em nível de volume usando [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)