Configuração de admissão de segurança do pod

Rótulos de admissão de segurança de pod

O Kubernetes define três tipos de rótulos para admissão de segurança de pods (consulte Tabela 2). Você pode definir esses rótulos em um namespace para definir o nível de padrão de segurança do pod a ser usado. No entanto, não altere o nível do padrão de segurança do pod em namespaces do sistema, como o kube-system. Caso contrário, os pods no namespace do sistema podem estar com defeito.

Os pods geralmente são criados indiretamente, criando um objeto de carga de trabalho, como uma Implementação ou tarefa. Para ajudar a detectar violações precocemente, os modos de auditoria e aviso são aplicados aos recursos da carga de trabalho. No entanto, o modo de imposição é aplicado somente aos objetos de pod resultantes.

Impor a admissão de segurança de pod com rótulos de namespace

Você pode rotular namespaces para impor os padrões de segurança do pod. Suponha que um espaço de nomes está configurado da seguinte forma:

apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.25
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.25
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.25

    # The label can be in either of the following formats:
    # pod-security.kubernetes.io/<MODE>: <LEVEL> 
    # pod-security.kubernetes.io/<MODE>-version: <VERSION>  
    # The audit and warn modes inform you of which security behaviors are violated by the load.

Os rótulos de namespace indicam qual nível de política aplicar para o modo. Para cada modo, há dois rótulos que determinam a política usada:

• pod-security.kubernetes.io/<MODE>: <LEVEL>
  • <MODE>: deve ser enforce, audit ou warn. Para obter detalhes sobre os modos, consulte Tabela 2.
  • <LEVEL>: deve ser privileged, baseline ou restricted. Para obter detalhes sobre os níveis, consulte Tabela 1.
• pod-security.kubernetes.io/<MODE>-version: <VERSION>

  Opcional, que fixa a política em uma determinada versão do Kubernetes.

  • <MODE>: deve ser enforce, audit ou warn. Para obter detalhes sobre os modos, consulte Tabela 2.
  • <VERSION>: número da versão do Kubernetes. Por exemplo, v1.25. Você também pode usar latest.

Se os pods forem implementados no namespace anterior, as seguintes restrições de segurança se aplicam:

1. A verificação no modo de impor é ignorada (modo impor + nível privilegiado).
2. As restrições relacionadas com a política de linha de base são verificadas (modo de auditoria + nível de linha de base). Ou seja, se o pod ou o contêiner violar a política, o evento correspondente será registrado no log de auditoria.
3. Restrições relacionadas à política restrita são verificadas (modo de aviso + nível restrito). Ou seja, se o pod ou contêiner violar a política, o usuário receberá um alarme ao criar o pod.

Migrar política de segurança do pod para a admissão de segurança do pod

Se você usar políticas de segurança de pods em um cluster anterior à v1.25 e precisar substituí-las pela admissão de segurança de pods em um cluster v1.25 ou posterior, siga o guia em Migração de PodSecurityPolicy para o controlador de admissão interno de PodSecurity.

1. A admissão de segurança do pod suporta apenas três modos de isolamento, menos flexíveis do que as políticas de segurança do pod. Se você precisar de mais controle sobre restrições específicas, será necessário usar um Webhook de validação de admissão para impor essas políticas.
2. Admissão de segurança de pod é um controlador de admissão não-mutante, o que significa que não irá modificar pods antes de validá-los. Se você estava confiando neste aspecto da PSP, você precisará modificar o contexto de segurança em suas cargas de trabalho ou usar um Webhook de admissão com mutação para fazer essas alterações.
3. A PSP permite que você vincule políticas diferentes a contas de serviço diferentes. Essa abordagem tem muitas armadilhas e não é recomendada, mas se você precisar desse recurso de qualquer maneira, precisará usar um webhook de terceiros.
4. Não aplique a admissão de segurança do pod aos namespaces onde os componentes do CCE, como kube-system, kube-public e kube-node-lease, são implementados. Caso contrário, os componentes do CCE e funções adicionais serão anormais.

Documentação

• Admissão de segurança de pod
• Mapeamento de PodSecurityPolicies para padrões de segurança de pods
• Aplicação de padrões de segurança do pod com rótulos de namespace
• Aplicação de padrões de segurança do pod configurando o controlador de admissão embutido