Entendendo perfis de segurança

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

Privilegiado

A configuração de segurança pod padrão reforça globalmente o perfil de segurança pod privileged Kubernetes, que é irrestrito e permite escalações de privilégio conhecidas, além de gerar avisos e eventos de auditoria com base nas políticas definidas pelo perfil restricted.

Linha de base

O perfil baseline é um perfil restritivo que previne escalações de privilégio conhecidas. Permite a configuração Pod padrão (minimamente especificado).

Restrito

O perfil restricted é fortemente restrito e segue o pod atual endureirando as melhores práticas.

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

Pod Security Admissão contém três modos que definem o que ação o plano de controle toma se uma violação em potencial é detectada.

aplicar

As violações de política fazem com que a poda seja rejeitada.

auditoria

Violações de políticas acionam a inclusão de uma anotação de auditoria para o evento registrado no log de auditoria, mas são permitidos de outra forma.

aviso

As violações de políticas acionam um aviso voltado para o usuário, mas são permitidas de outra forma.

Como as normas de segurança ou implementações de perfis mudam para tratar de novos recursos, é possível 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?

Enquanto O Pod Security Admissão está sempre ativado, ele pode ser um dos múltiplos controladores de admissão. Você pode configurar os controladores de admissão de Kubernetes de terceiros para implementar outros modelos de política de segurança que se adequam ao seu caso de uso.

Se você configurar o Pod Security Admission para impingir, avisar e auditar usando o perfil privileged, então o plano de controle permite 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 tome nenhuma das ações a seguir.

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

Configurando etiquetas de namespace de admissão Pod Security

Você pode definir o modo de controle de admissão que deseja usar para segurança pod em cada namespace. Kubernetes define um conjunto de etiquetas que você pode configurar para definir qual dos perfis predefinidos de Pod Security Standard você deseja usar para um namespace. A etiqueta que você seleciona define qual ação o plano de controle toma se uma violação em potencial é detectada.

Por padrão, IBM Cloud Kubernetes Service adiciica os rótulos privileged Pod Security 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 (Versão 1.29 e posterior)
• tigera-operator (Versão 1.29 e posterior)
• calico-apiserver (Versão 1.31 )

Não remova ou altere os rótulos para estes namespaces.

Um espaço de nomes pode ser rotulado para configurar o perfil de segurança pod para qualquer ou toda a Admissão de Segurança do Pod modes.

Por exemplo, é possível rotular um namespace para impingir o perfil privileged além de usar warn ou audit usando o perfil baseline.

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

As Etiquetas de Nomes de Nomes de Admissão de Segurança do Pod são do formulário 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 espaço de nomes para fazer valer o perfil privileged e gerar avisos e eventos de auditoria para violações do perfil baseline, utilize 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 do plug-in de Admissão de Segurança de Pod Padrão

IBM Cloud Kubernetes Service 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: []

Customizando a configuração do plug-in de Admissão de Segurança de Pod

A configuração do plug-in de Admissão de Segurança de Pod em todo o cluster define o comportamento enforce, audit e warn para todos os namespaces que não têm rótulos ou isenções de segurança de pod

Para clusters Kubernetes 1.24, o apiVersion deve ser pod-security.admission.config.k8s.io/v1beta. Para 1.25 e posterior pod-security.admission.config.k8s.io/v1 é preferencial, mas a versão da API v1beta ainda pode ser usada.

1. Crie um arquivo YAML que contenha um recurso PodSecurityConfiguration É possível usar a configuração padrão para iniciar

   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: []
   

2. Faça as personalizações que você deseja usar. Revise as seguintes informações sobre cada seção da configuração.

   defaults

   A seção defaults da configuração define os padrões de todo o cluster para namespaces que não possuem rótulos de segurança de pod Os campos podem ter os mesmo valores que os rótulos de namespace correspondentes.

   exemptions

   A seção exemptions da configuração permite criar pods que, de outra forma, são proibidos devido à política associada a um namespace específico. As dimensões de isenção incluem os seguintes casos.

   • Nomes de usuário: as solicitações de usuários com um nome de usuário autenticado (ou personificado) isento são ignorados.. Geralmente, os nomes de usuário são usuários do IAM ou contas de serviços Por exemplo, usernames: [ "IAM#user@example.com" ]. Também é possível isentar o nome do usuário associado a um certificado cliente admin kubeconfig. Se desejar especificar um certificado admin kubeconfig, o nome do usuário será o componente CN do certificado de cliente atual.

     kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
     /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
     

     No exemplo a seguir, o nome do usuário é IBMid-27000xxxxx-admin-2023-05-12 Se você obtiver um novo admin kubeconfig, o nome do usuário poderá ser diferente

     openssl x509 -in <client-certificate> -subject -noout`
     subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
     

   • RuntimeClassNames: Os pods e os recursos de carga de trabalho que especificam um nome de classe de tempo de execução isento são ignorados.

   • Namespaces: Pods e recursos de carga de trabalho em um namespace isento são ignorados.

3. Salve seu arquivo YAML de customizações..

4. Execute o comando ibmcloud ks cluster master pod-security set .

   ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
   

Ao executar o comando ibmcloud ks cluster master pod-security set, a admissão de segurança do pod será reconfigurada para a configuração padrão se você não especificar um arquivo de configuração..