Como usar PodSecurityPolicies

Nesta página, explicamos como usar PodSecurityPolicies no Google Kubernetes Engine.

Visão geral

O PodSecurityPolicy é um recurso controlador de admissão desenvolvido para validar solicitações de criação e atualização de pods no cluster. O PodSecurityPolicy define um conjunto de condições que os pods precisam atender para serem aceitos pelo cluster. Assim, quando uma solicitação para criar ou atualizar um pod não atende às condições no PodSecurityPolicy, ela é recusada e retorna um erro.

Para usar o PodSecurityPolicy, primeiro é necessário criar e definir as políticas que os pods novos e atualizados precisam cumprir. Depois, é preciso ativar o controlador de admissão do PodSecurityPolicy (em inglês), que valida as solicitações de criação e atualização de pods de acordo com as políticas definidas.

Quando vários PodSecurityPolicies estão disponíveis, o controlador de admissão usa a primeira política validada. As políticas são ordenadas alfabeticamente, e o controlador prioriza políticas constantes (ou seja, que não alteram o pod) em vez de modificáveis.

O PodSecurityPolicy está disponível nos clusters do GKE que executam o Kubernetes versão 1.8.6 ou superior.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Defina configurações gcloud padrão usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Como definir PodSecurityPolicies

Você precisa definir os recursos do PodSecurityPolicy no seu cluster antes que o controlador dele possa validar e aceitar os pods.

Com os PodSecurityPolicies, você especifica uma lista de restrições, requisitos e padrões para os pods criados de acordo com a política. Os exemplos incluem a restrição do uso de contêineres com privilégios, volumes do hostPath e rede do host ou a padronização de todos os contêineres para execução com um perfil seccomp. O controlador de admissão do PodSecurityPolicy valida as solicitações de acordo com os PodSecurityPolicies disponíveis.

O exemplo de PodSecurityPolicy a seguir, my-psp.yaml, impede a criação de pods com privilégios. A política também afeta vários outros aspectos de controle, como a permissão de acesso a todos os volumes disponíveis:

apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: my-psp
    spec:
      privileged: false  # Prevents creation of privileged Pods
      seLinux:
        rule: RunAsAny
      supplementalGroups:
        rule: RunAsAny
      runAsUser:
        rule: RunAsAny
      fsGroup:
        rule: RunAsAny
      volumes:
      - '*'
    

A especificação do PodSecurityPolicy (em inglês) protege vários aspectos do controle. Os aspectos do controle especificados nesse exemplo (seLinux, supplementalGroups, runAsUser e fsGroup) estão definidos como RunAsAny. Isso indica que quaisquer valores válidos nesses campos podem ser usados com essa política.

Para mais informações sobre os PodSecurityPolicies e os respectivos aspectos de controle, consulte O que é uma política de segurança de pods? e a referência da política (páginas em inglês) na documentação do Kubernetes.

Use a ferramenta de linha de comando kubectl para criar esse recurso:

kubectl apply -f my-psp.yaml
    

Para mais exemplos de configuração de PodSecurityPolicies, consulte a seção Exemplo (em inglês) na página "PodSecurityPolicy" da documentação do Kubernetes.

Como autorizar políticas

As contas com o papel cluster-admin podem usar o controle de acesso baseado em papel para criar um Role ou um ClusterRole (links em inglês) que concedem o acesso de contas de serviço a PodSecurityPolicies. Um ClusterRole concede permissões em todo o cluster, e um Role concede permissões em um namespace definido por você.

Por exemplo, o ClusterRole a seguir, my-clusterrole.yaml, concede acesso ao PodSecurityPolicy my-psp, conforme indicado por verb: use:

kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: my-clusterrole
    rules:
    - apiGroups:
      - policy
      resources:
      - podsecuritypolicies
      verbs:
      - use
      resourceNames:
      - my-psp
    

Crie o ClusterRole executando o seguinte comando:

kubectl apply -f my-clusterrole.yaml
    

Depois de criar um Role ou ClusterRole, associe-o às contas de serviço pretendidas ao gerar um recurso RoleBinding ou ClusterRoleBinding (links em inglês).

O RoleBinding a seguir, my-rolebinding.yaml, associa o ClusterRole, my-clusterrole, às contas de serviço em um namespace específico, my-namespace:

# Bind the ClusterRole to the desired set of service accounts.
    # Policies should typically be bound to service accounts in a namespace.
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: my-rolebinding
      namespace: my-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: my-clusterrole
    subjects:
    # Example: All service accounts in my-namespace
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:serviceaccounts
    # Example: A specific service account in my-namespace
    - kind: ServiceAccount # Omit apiGroup
      name: default
      namespace: my-namespace
    

Nesse RoleBinding:

  • o campo subjects especifica a quais contas o ClusterRole está vinculado;
  • o primeiro assunto é um grupo, system:serviceaccounts, que engloba todas as contas de serviço no cluster;
  • o segundo assunto é um ServiceAccount individual, default, que especifica a conta de serviço padrão no namespace.

Crie o RoleBinding executando o seguinte comando:

kubectl apply -f my-rolebinding.yaml
    

Para mais informações sobre o controle de acesso com base no papel (RBAC, na sigla em inglês), consulte Uso da autorização do RBAC (em inglês).

Como ativar o controlador do PodSecurityPolicy

Para usar o controlador de admissão do PodSecurityPolicy, você precisa criar um novo cluster ou atualizar um atual com a sinalização --enable-pod-security-policy.

Para criar um novo cluster com o PodSecurityPolicy, execute o seguinte comando:

gcloud beta container clusters create cluster-name --enable-pod-security-policy
    

Para atualizar um cluster existente:

gcloud beta container clusters update cluster-name --enable-pod-security-policy
    

Como desativar o controlador do PodSecurityPolicy

Para desativar o controlador do PodSecurityPolicy, execute o seguinte comando:

gcloud beta container clusters update cluster-name --no-enable-pod-security-policy
    

Desativar o controlador faz o cluster parar de validar e padronizar as políticas atuais, mas não as exclui. As vinculações também não são excluídas.

Como trabalhar com NetworkPolicy

Se você estiver usando um NetworkPolicy e tiver um pod sujeito ao PodSecurityPolicy, crie um papel RBAC ou ClusterRole (em inglês) que tenha permissão para usar o PodSecurityPolicy Em seguida, vincule-o à conta de serviço do pod. Nesse caso, conceder permissões a contas de usuários não é suficiente. Para mais informações, consulte Como autorizar políticas.

A seguir