Contextos de segurança do pod

As Políticas de Segurança de Pod (PSP) e os Padrões de Segurança de 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, e o Pod Security Standard (PSS) é a abordagem recomendada pelo Kubernetes para reforçar a segurança daqui para frente.

Uma Política de Segurança de 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 de 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 de 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 (não restritiva) 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 possíveis atritos, exigindo uma lista mínima de exceções. Ele serve como um bom ponto de partida para a segurança da carga de trabalho. Se você estiver usando PSPs no momento, recomendamos mudar para 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, Kyverno fornece a coleção completa de políticas de PSS aqui. https://kyverno.io/policies/

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 Linux-based cargas de trabalho padrão quando se trata de contextos de segurança.

O Windows usa um objeto de trabalho 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 instalada. 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 o restante são opções gerais do Contexto de Segurança.

Para obter uma lista de atributos de contexto de segurança compatíveis com 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 AsUserName configuração de execução para pods e contêineres, que é uma opção do Windows, é um equivalente aproximado da AsUser configuração de Linux-specific execução 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

No exemplo a seguir, o contexto de segurança no nível do contêiner substitui o contexto de segurança no nível do 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 AsUserName campo de execução: ContainerAdministrator, ContainerUser, NT AUTHORITY\ NETWORK SERVICE, NT AUTHORITY\ LOCAL SERVICE

Geralmente, é uma boa ideia executar seus contêineres com pods ContainerUser para Windows. Os usuários não são compartilhados entre o contêiner e o host, ContainerAdministrator mas têm privilégios adicionais no 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