Aplique políticas de segurança ao nível do pod predefinidas através do PodSecurity


Esta página mostra como aplicar controlos de segurança predefinidos ao nível do pod nos seus clusters do Google Kubernetes Engine (GKE) através do controlador de admissão PodSecurity. A aplicação de controlos de segurança aos seus pods pode ajudar a cumprir os requisitos de segurança e conformidade. Nesta página, saiba mais sobre o PodSecurity e como o aplicar aos seus Pods.

Esta página destina-se a especialistas em segurança que querem aplicar controlos de segurança aos respetivos clusters do GKE. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Acerca de PodSecurity

O PodSecurity é um controlador de admissão do Kubernetes que lhe permite aplicar normas de segurança de pods a pods executados nos seus clusters do GKE. As normas de segurança de pods são políticas de segurança predefinidas que abrangem as necessidades de segurança de pods de alto nível no Kubernetes. Estas políticas variam entre ser altamente permissivas e altamente restritivas.

Pode aplicar as seguintes normas de segurança de pods aos seus clusters do GKE:

  • Privilegiada: uma política não restrita que oferece o nível mais amplo de autorizações. Permite escalamentos de privilégios conhecidos.
  • Base: uma política minimamente restritiva que permite a configuração do pod predefinida e minimamente especificada. Impede escalamentos de privilégios conhecidos.
  • Restrita: uma política altamente restritiva que segue as práticas recomendadas de reforço de pods.

Pode usar o controlador de admissão PodSecurity para aplicar as normas de segurança de pods nos seguintes modos:

  • Aplicar: as violações de políticas rejeitam a criação de pods. Um evento de auditoria é adicionado ao registo de auditoria.
  • Auditoria: as violações de políticas acionam a adição de um evento de auditoria ao registo de auditoria. A criação de pods é permitida.
  • Avisar: as violações de políticas acionam um aviso apresentado ao utilizador. A criação de agrupamentos está autorizada.

O controlador de admissão PodSecurity incorpora estas políticas na API Kubernetes.

Se quiser criar e aplicar políticas de segurança personalizadas ao nível do Pod, considere usar o controlador de admissão Gatekeeper.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
  • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Requisitos

O controlador de admissão PodSecurity está disponível e ativado por predefinição em clusters que executam as seguintes versões do GKE:

  • Versão 1.25 ou posterior: estável
  • Versão 1.23 e versão 1.24: beta

Para verificar se uma versão do GKE está disponível e é a versão predefinida do seu canal de lançamento, consulte o cronograma de lançamentos.

Aplique as normas de segurança de pods através do PodSecurity

Para usar o PodSecurity controlador de admissão, tem de aplicar normas de segurança de pods específicas em modos específicos a espaços de nomes específicos. Pode fazê-lo através de etiquetas de espaço de nomes. Neste exercício, vai fazer o seguinte:

  • Crie dois novos espaços de nomes
  • Aplique políticas de segurança a cada espaço de nomes
  • Teste as políticas configuradas

Nas seguintes versões do GKE, o GKE ignora as políticas que aplica ao espaço de nomes kube-system:

  • 1.23.6-gke.1900 e posterior
  • 1.24.0-gke.1200 e posterior

Nas versões anteriores do GKE, evite aplicar políticas em kube-system.

Crie novos espaços de nomes

Crie namespaces no seu cluster:

kubectl create ns baseline-ns
kubectl create ns restricted-ns

Este comando cria os seguintes espaços de nomes:

  • baseline-ns: para cargas de trabalho permissivas
  • restricted-ns: para cargas de trabalho altamente restritas

Use etiquetas para aplicar políticas de segurança

Aplique as seguintes normas de segurança de pods:

  • baseline: aplique a baseline-ns no modo warn
  • restricted: aplique a restricted-ns no modo enforce
kubectl label --overwrite ns baseline-ns pod-security.kubernetes.io/warn=baseline
kubectl label --overwrite ns restricted-ns pod-security.kubernetes.io/enforce=restricted

Estes comandos alcançam o seguinte resultado:

  • As cargas de trabalho no espaço de nomes baseline-ns que violam a política baseline são permitidas, e o cliente apresenta uma mensagem de aviso.
  • As cargas de trabalho no espaço de nomes restricted-ns que violam a política restricted são rejeitadas, e o GKE adiciona uma entrada aos registos de auditoria.

Verifique se as etiquetas foram adicionadas:

kubectl get ns --show-labels

O resultado é semelhante ao seguinte:

baseline-ns       Active   74s   kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline
restricted-ns     Active   18s   kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted
default           Active   57m   kubernetes.io/metadata.name=default
kube-public       Active   57m   kubernetes.io/metadata.name=kube-public
kube-system       Active   57m   kubernetes.io/metadata.name=kube-system

Teste as políticas configuradas

Para verificar se o controlador de admissão PodSecurity funciona conforme esperado, implemente uma carga de trabalho que viole a política baseline e a política restricted em ambos os espaços de nomes. O manifesto de exemplo seguinte implementa um contentor nginx que permite a escalada de privilégios.

  1. Guarde o seguinte manifesto como psa-workload.yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          privileged: true
    
  2. Aplique o manifesto ao espaço de nomes baseline-ns:

    kubectl apply -f psa-workload.yaml --namespace=baseline-ns
    

    O resultado é semelhante ao seguinte:

    Warning: would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true)
    

    A política baseline permite que o Pod seja implementado no espaço de nomes.

  3. Verifique se o pod foi implementado com êxito:

    kubectl get pods --namespace=baseline-ns -l=app=nginx
    
  4. Aplique o manifesto ao espaço de nomes restricted-ns:

    kubectl apply -f psa-workload.yaml --namespace=restricted-ns
    

    O resultado é semelhante ao seguinte:

    Error from server (Forbidden): error when creating "workload.yaml": pods "nginx"
    is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation
    != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false),
    unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]),
    runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true),
    seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type
    to "RuntimeDefault" or "Localhost")
    

    O Pod não é implementado no espaço de nomes. É adicionada uma entrada de auditoria ao registo.

Veja as violações de políticas nos registos de auditoria

As violações de políticas nos modos audit e enforce são registadas nos registos de auditoria do seu cluster. Pode ver estes registos através do Explorador de registos na Trusted Cloud consola.

  1. Aceda à página Explorador de registos na Trusted Cloud consola.

    Aceda ao Explorador de registos

  2. No campo Consulta, especifique o seguinte para obter registos de auditoria do modo audit e enforce:

    resource.type="k8s_cluster"
    protoPayload.resourceName:"/pods/nginx"
    protoPayload.methodName="io.k8s.core.v1.pods.create"
    (labels."pod-security.kubernetes.io/audit-violations":"PodSecurity" OR protoPayload.response.reason="Forbidden")
    
  3. Clique em Executar consulta.

  4. Na secção Resultados da consulta, expanda a entrada de registo Forbidden para inspecionar os registos de rejeição do modo enforce. Os detalhes são semelhantes aos seguintes:

    {
      ...
      protoPayload: {
        @type: "type.googleapis.com/google.cloud.audit.AuditLog"
        authenticationInfo: {1}
        authorizationInfo: [1]
        methodName: "io.k8s.core.v1.pods.create"
        request: {6}
        requestMetadata: {2}
        resourceName: "core/v1/namespaces/restricted-ns/pods/nginx"
        response: {
          @type: "core.k8s.io/v1.Status"
          apiVersion: "v1"
          code: 403
          details: {2}
          kind: "Status"
          message: "pods "nginx" is forbidden: violates PodSecurity "restricted:latest": privileged
                  (container "nginx" must not set securityContext.privileged=true),
                  allowPrivilegeEscalation != false (container "nginx" must set
                  securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
                  (container "nginx" must set securityContext.capabilities.drop=["ALL"]),
                  runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true),
                  seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type
                  to "RuntimeDefault" or "Localhost")"
          metadata: {0}
          reason: "Forbidden"
          status: "Failure"
          }
          serviceName: "k8s.io"
          status: {2}
        }
      receiveTimestamp: "2022-02-01T19:19:25.353235326Z"
      resource: {2}
      timestamp: "2022-02-01T19:19:21.469360Z"
    }
    
  5. Expanda a entrada do registo audit-violations para inspecionar os registos do modo audit. Os detalhes são semelhantes aos seguintes:

    {
      ...
      labels: {
        ...
        pod-security.kubernetes.io/audit-violations: "would violate PodSecurity "baseline:latest": privileged
                                                    (container "nginx" must not set securityContext.privileged=true)"
        pod-security.kubernetes.io/enforce-policy: "privileged:latest"
      }
      operation: {4}
      protoPayload: {10}
      receiveTimestamp: "2023-12-26T05:18:04.533631468Z"
      resource: {2}
      timestamp: "2023-12-26T05:17:36.102387Z"
    }
    

Limpar

Para evitar incorrer em cobranças na sua conta Trusted Cloud by S3NS , elimine os espaços de nomes:

kubectl delete ns baseline-ns
kubectl delete ns restricted-ns

Alternativas a PodSecurity

Além de usar o PodSecuritycontrolador de admissão do Kubernetes integrado para aplicar as normas de segurança de pods, também pode usar o Gatekeeper, um controlador de admissão baseado no Open Policy Agent (OPA), para criar e aplicar controlos de segurança personalizados ao nível do pod.

O que se segue?