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 criado 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, essa solicitação é recusada e retorna um erro.

Para usar o PodSecurityPolicy, primeiro você tem que criar e definir as políticas que os pods novos e atualizados precisam cumprir. Em seguida, é 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 segundo as políticas definidas.

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

O PodSecurityPolicy está disponível em clusters GKE que executam o Kubernetes versão 1.8.6 ou posterior.

Antes de começar

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

Defina as configurações padrão da gcloud 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

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  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 a 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 possa validar e aceitar os pods.

Os PodSecurityPolicies especificam uma lista de restrições, requisitos e padrões para os pods criados segundo 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 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) pode proteger vários aspectos de 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 nos 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

Contas com o papel cluster-admin podem usar o controle de acesso baseado em papéis para criar um Papel ou ClusterRole (ambos os links em inglês) que concede às contas de serviço acesso a PodSecurityPolicies. Um ClusterRole concede permissões em todo o cluster, e um papel 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 criar 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 que já existe 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 com que o cluster pare de validar e padronizar as políticas existentes, 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 a um PodSecurityPolicy, crie um Role ou ClusterRole do RBAC (em inglês) que tenha permissão para usar o PodSecurityPolicy. Em seguida, vincule o Role ou ClusterRole à 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