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

Prepare-se para a tarefa tomando as seguintes medidas:

  • Verifique se você ativou a API Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Verifique se o SDK do Cloud está instalado.
  • Defina o código padrão do projeto:
    gcloud config set project [PROJECT_ID]
  • Se você estiver trabalhando com clusters zonais, defina a zona de computação padrão:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Se você estiver trabalhando com clusters regionais, defina a região de computação padrão:
    gcloud config set compute/region [COMPUTE_REGION]
  • Atualize o 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, simplesmente impede a criação de pods com privilégios. A política também afeta outros aspectos de controle, como permissão de acesso a todos os volumes disponíveis:

apiVersion: extensions/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 de controle seLinux, supplementalGroups, runAsUser e fsGroup especificados neste exemplo estão todos configurados como RunAsAny. Isso indica que quaisquer valores válidos para esses campos podem ser usados com essa política.

Para mais informações sobre as PodSecurityPolicies e os aspectos de controle delas, consulte O que é uma política de segurança de pod? e a referência de políticas (ambos em inglês) na documentação do Kubernetes.

Você cria esse recurso usando a ferramenta de linha de comando kubectl:

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 no papel para criar um papel ou um ClusterRole que concede o acesso de contas de serviço a PodSecurityPolicies. Um ClusterRole concede permissões cluster-wide, e um papel concede permissões em um namespace definido por você.

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

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

Crie o ClusterRole executando o seguinte comando:

kubectl apply -f my-clusterrole.yaml

Depois de criar um papel ou ClusterRole, associe-o às contas de serviço pretendidas ao criar um recurso RoleBinding ou ClusterRoleBinding.

O RoleBinding a seguir, my-rolebinding.yaml, vincula 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;
  • a primeira entidade é um grupo, system:serviceaccounts, que engloba todas as contas de serviço no cluster;
  • a segunda entidade é uma 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 cluster existente 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 papel ou ClusterRole do RBAC 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine