Admissão de segurança de pods

A admissão de segurança do pod implementa os padrões de segurança do pod Kubernetes que restringem o comportamento dos pods, fornecendo mensagens de aviso e eventos de auditoria kube-apiserver para pods que violam a política de perfil de segurança do pod configurada para o namespace relevante.

Red Hat OpenShift on IBM Cloud a versão 4.11 e posteriores incluem suporte para admissão de segurança do pod Kubernetes. Para obter mais informações, consulte Admissão de segurança do pod e Padrões de segurança do pod na documentação Kubernetes.

O Pod Security Admission está sempre ativado para Red Hat OpenShift on IBM Cloud versão 4.11 e posterior. As versões anteriores do site Kubernetes usam políticas de segurança de pod.

Compreensão dos perfis de segurança

Os padrões de segurança do pod Kubernetes definem os três perfis a seguir.

Privilegiado
A configuração padrão de segurança do pod impõe globalmente o perfil de segurança do pod privileged Kubernetes, que é irrestrito e permite escalonamentos de privilégios conhecidos, e gera avisos e eventos de auditoria com base nas políticas definidas pelo perfil restricted.
Linha de base
O perfil baseline é um perfil restritivo que impede o aumento de privilégios conhecidos. Permite a configuração padrão (minimamente especificada) do Pod.
Restrito
O perfil restricted é altamente restrito e segue as práticas recomendadas atuais de proteção de pods.

Para obter mais informações sobre perfis de segurança de pod, consulte Detalhes do perfil na documentação Kubernetes.

O Pod Security Admission contém três modos que definem a ação do plano de controle se uma possível violação for detectada.

aplicar
As violações de política fazem com que o pod seja rejeitado.
auditoria
As violações de política acionam a adição de uma anotação de auditoria ao evento registrado no log de auditoria, mas são permitidas de outra forma.
aviso
As violações de política acionam um aviso para o usuário, mas são permitidas de outra forma.

À medida que os padrões de segurança ou as implementações de perfis mudam para atender a novos recursos, você pode configurar o Pod Security Admission para usar uma versão específica das funções. As seguintes versões são compatíveis.

  • Uma versão Kubernetes major.minor (por exemplo, v1.25)
  • latest

E se o Pod Security Admission não for a escolha certa para mim?

Embora o Pod Security Admission esteja sempre ativado, ele pode ser um dos vários controladores de admissão. Você pode configurar controladores de admissão Kubernetes de terceiros para implementar outros modelos de política de segurança adequados ao seu caso de uso.

Se você configurar o Pod Security Admission para impor, avisar e auditar usando o perfil privileged, o plano de controle permitirá que todos os pods sejam executados. Em seguida, é possível configurar outros controladores de admissão para rejeitá-los.

Você pode instalar um controlador de admissão de terceiros, desde que ele não execute nenhuma das seguintes ações.

  • Ele não instala suas próprias políticas de segurança de pod (PSPs).
  • Ele não depende dos PSPs para aplicar partes da política.

Configuração de rótulos de namespace de admissão de segurança de pods

Você pode definir o modo de controle de admissão que deseja usar para a segurança do pod em cada namespace. Kubernetes define um conjunto de rótulos que você pode configurar para definir qual dos perfis predefinidos do Pod Security Standard você deseja usar para um namespace. O rótulo selecionado define a ação que o plano de controle tomará se uma possível violação for detectada.

Por padrão, o site Red Hat OpenShift on IBM Cloud adiciona os rótulos de segurança do pod privileged aos seguintes namespaces. Esses namespaces são rotulados como enforce, audit e warn usando o perfil privileged.

  • kube-system
  • ibm-system
  • ibm-operators
  • calico-system
  • tigera-operator
  • calico-apiserver (Versão 4.16 e posterior)

Não remova ou altere os rótulos desses namespaces ou de qualquer um dos namespaces do site openshift-*.

Um namespace pode ser rotulado para definir o perfil de segurança do pod para qualquer um ou todos os Pod Security Admission modes.

Por exemplo, você pode rotular um namespace para aplicar o perfil privileged, além de usar warn ou audit usando o perfil baseline.

Esse rótulo permite que os administradores e os desenvolvedores de aplicativos executem aplicativos a seco, procurando apenas avisos e registros de auditoria no perfil baseline sem rejeitar pods. Em seguida, você pode fazer as alterações necessárias em suas cargas de trabalho antes de alterar o modo de aplicação para baseline.

Os rótulos de namespace do Pod Security Admission são do tipo pod-security.kubernetes.io/<MODE>: <LEVEL> e pod-security.kubernetes.io/<MODE>-version: <VERSION>.

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version
  • pod-security.kubernetes.io/audit
  • pod-security.kubernetes.io/audit-version
  • pod-security.kubernetes.io/warn
  • pod-security.kubernetes.io/warn-version

Para rotular um namespace para impor o perfil privileged e gerar avisos e eventos de auditoria para violações do perfil baseline, use os seguintes rótulos.

  • pod-security.kubernetes.io/enforce: privileged
  • pod-security.kubernetes.io/enforce-version: latest
  • pod-security.kubernetes.io/audit: baseline
  • pod-security.kubernetes.io/audit-version: latest
  • pod-security.kubernetes.io/warn: baseline
  • pod-security.kubernetes.io/warn-version: latest

Configuração padrão do plug-in Pod Security Admission

Red Hat OpenShift on IBM Cloud usa o seguinte PodSecurityConfiguration por padrão.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

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

Você pode configurar o comportamento de segurança do pod no nível do namespace com rótulos de segurança de pod predefinidos. Para obter mais informações sobre a configuração, consulte Controle da sincronização de admissão de segurança do pod na documentação Red Hat OpenShift. Observe que as etapas variam para cada versão do cluster, portanto, certifique-se de que está visualizando as etapas para a versão correta.

Para obter mais informações sobre como configurar os registros de apiserver para Red Hat OpenShift on IBM Cloud, consulte Kubernetes Registros de auditoria do servidor de API.

A admissão de segurança de pods oferece a capacidade de impor, advertir e gerar eventos de auditoria para pods que violam os perfis de segurança. Em OpenShift 4.11, a configuração padrão impõe o perfil privilegiado e, ao mesmo tempo, gera avisos e eventos de auditoria com base no perfil restricted. Esse comportamento pode ser controlado no nível do namespace por meio do uso de rótulos de segurança de pod predefinidos nos namespaces. Quando os perfis de segurança do POD são aplicados, você pode ver avisos como o exemplo a seguir.

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

Nesse exemplo, o pod ainda é criado e pode ser executado desde que a conta de serviço esteja autorizada a um perfil SecurityContextConstraint. O aviso indica que as alterações no perfil securityContext do pod e do contêiner são necessárias para que o pod seja executado no perfil de segurança do pod especificado, como a configuração da opção allowPrivilegeEscalation=false ou que um perfil de segurança do pod que permita esses recursos deve ser usado.

Red Hat OpenShift também inclui um controlador que aplica rótulos de namespace com base nas permissões SCC das contas de serviço em um determinado namespace. Tanto a admissão de segurança do pod quanto as SCCs são aplicadas. Você pode usar principalmente SCCs e usar o controlador de sincronização de admissão de segurança do pod para ajustar o rótulo de segurança do pod no namespace. Ou você pode usar principalmente perfis de segurança de pod com uma associação de função de namespace que permita que todas as contas de serviço no namespace usem um SCC equivalente (ou mais privilegiado). Não defina associações de funções ou associações de funções de cluster que se apliquem globalmente, como todos os usuários autorizados ou todas as contas de serviço em todos os namespaces, pois essas associações podem afetar os componentes do Red Hat OpenShift que esperam ser executados em um determinado SCC.

Recursos adicionais