Skip to main content

Pod Security Standards

Documentação

Os Pod Security Standards (PSS) são uma série de políticas de segurança no Kubernetes para garantir que os pods sejam criados e executados com as práticas de segurança adequadas. Eles foram introduzidos para substituir o modelo de PodSecurityPolicy (PSP), que foi descontinuado na versão 1.25.

Funcinam através de um Admission Controller que intercepta a solicitação e verifica a política.

O Kubernetes permite aplicar esses padrões por namespace, usando labels para definir o nível de segurança que deve ser imposto. Isso garante que cada namespace tenha suas próprias regras de segurança, sem afetar todo o cluster.

Os PSS definem três níveis de segurança:

  • Privileged: Este nível oferece o mínimo de restrições de segurança, permitindo pods com permissões amplas, como execução como root ou uso de capacidades privilegiadas. É utilizado para workloads que requerem mais controle sobre o sistema. Exemplo de uso: ambientes de desenvolvimento ou pods que precisam acessar diretamente o host.

  • Baseline (Padrão): Este é o nível recomendado para a maioria dos workloads, oferecendo uma segurança balanceada. Ele impõe restrições mínimas para prevenir ações inseguras, como a execução de processos como root, mas ainda permite alguma flexibilidade. Exemplo de uso: aplicações comuns que não precisam de permissões elevadas ou acesso direto ao host.

  • Restricted: Este é o nível mais seguro e aplica as restrições mais rígidas, garantindo o uso de práticas de segurança ideais. Ele proíbe o uso de root, previne containers privilegiados, e impõe controles rígidos sobre permissões e capacidades. Exemplo de uso: aplicações críticas ou em ambientes altamente regulamentados, onde a segurança é uma prioridade.

Os níveis de segurança podem ser aplicados em 3 diferentes cenários:

  • enforce: Imposição do nível da política que garantirá que todos os pods criados no namespace atendam, no mínimo, a essa política. Se um pod não estiver em conformidade com as regras da política escolhida, ele será bloqueado.

  • warn: O nível que irá gerar avisos. Assim, quando um pod não atender aos padrões impostos, os usuários receberão uma notificação, mas o pod ainda será permitido.

  • audit: A política de auditoria que irá gravar eventos em logs, permitindo que você acompanhe quais pods estão violando essa política, sem afetar a execução dos pods.

Para aplicar um PSS é necessário somente colocar a label correta no namespace.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

Ela permite que você faça a imposição de uma política de segurança mais permissiva (como baseline), enquanto simultaneamente audita e emite avisos para uma política mais restrita (como restricted). Vamos detalhar cada parte:

Não é necessário usar tudo isso, coloquei só para mostrar possibilidades.

Explicação de cada label:

  • pod-security.kubernetes.io/enforce=baseline: Define que o nível de segurança baseline será enforced (imposto) no namespace. Isso significa que qualquer pod que violar as regras mínimas de segurança definidas pelo nível "baseline" será bloqueado durante a criação ou modificação.

  • pod-security.kubernetes.io/enforce-version=latest: Especifica a versão da política de segurança que será aplicada. No caso, ele usa a versão mais recente (latest) da política de segurança de pods. Não é obrigatório.

  • pod-security.kubernetes.io/warn=restricted: Aplica o nível de segurança restricted no modo de aviso (warn). Isso significa que, se um pod violar as regras mais rígidas do nível "restricted", o Kubernetes emitirá um aviso para o usuário, mas não bloqueará a criação do pod. É útil para preparar a transição para políticas mais rígidas sem interromper operações.

  • pod-security.kubernetes.io/warn-version=latest: Define que a versão mais recente do nível restricted será usada para gerar os avisos.

  • pod-security.kubernetes.io/audit=restricted: Aplica o nível de segurança restricted no modo de auditoria (audit). Quando um pod é criado ou modificado e viola as regras do nível "restricted", isso será registrado nos logs de auditoria do Kubernetes, permitindo rastrear eventos sem bloquear ou avisar o usuário.

  • pod-security.kubernetes.io/audit-version=latest: Usa a versão mais recente do nível restricted para a auditoria. Objetivo da Configuração:

Se você aplicar os Pod Security Standards (PSS) em um namespace que já possui pods em execução, o comportamento depende da label que você utiliza e do estado atual dos pods.

  • Os pods que já estão em execução não serão afetados imediatamente pelas regras de segurança, pois o PSS é verificado apenas durante a criação ou alteração dos pods. Se os pods não forem reiniciados ou recriados, eles continuarão rodando normalmente, mesmo que não estejam em conformidade com as novas regras do PSS.

  • Novos pods ou pods recriados serão bloqueados caso não atendam as regras.

Se você tentar criar novos pods ou recriar (por exemplo, em um cenário de rollout ou upgrade de deployment) e eles não estiverem em conformidade com o nível de segurança definido (como "baseline" ou "restricted"), o Kubernetes irá impedir a criação desses pods. Isso também afeta pods que passam por eventos de reschedule (como falhas de nó ou manutenções) ou pods que fazem parte de workloads como Deployments ou StatefulSets. Ajustes necessários:

Antes de aplicar uma política de segurança mais restrita, como "restricted", é recomendável revisar e adaptar seus pods para garantir que eles cumpram as novas regras.