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. De acordo com a política de descontinuação do Kubernetes, 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. Essas políticas podem ser aplicadas com várias ferramentas, incluindo as da OPA e da Kyverno. Por exemplo, o Kyverno fornece a coleção completa de políticas de PSS aqui.

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 gerais do Contexto de Segurança.

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.

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\ NETWORK SERVICE, NT AUTHORITY\ 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 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