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:
- Verifique se você ativou a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Verifique se o SDK do Cloud está instalado.
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.
-
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
-
Siga as instruções para autorizar a
gcloud
a usar sua conta do Google Cloud. - Crie uma nova configuração ou selecione uma atual.
- Escolha um projeto do Google Cloud.
- 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
- Verifique se você entendeu como usar o controle de acesso baseado em papéis no GKE.
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
- Saiba mais sobre o controle de acesso com base no papel.
- Saiba como proteger seu cluster usando o gerenciamento de identidade e acesso.
- Saiba mais sobre os pods do sandbox