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:
- Documentação do Kubernetes para o controlador de admissão de segurança de pods
- Documentação do Kubernetes para as normas de segurança de pods
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.
- Certifique-se de que tem um cluster do GKE Autopilot ou Standard com a versão 1.23 ou posterior.
- Para clusters do Autopilot, inscreva-se num canal de lançamento em que a versão predefinida seja 1.23 ou posterior.
- Para clusters padrão, inscreva-se num canal de lançamento ou atualize o cluster para uma versão específica.
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 permissivasrestricted-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 abaseline-ns
no modowarn
restricted
: aplique arestricted-ns
no modoenforce
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íticabaseline
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íticarestricted
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.
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
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.Verifique se o pod foi implementado com êxito:
kubectl get pods --namespace=baseline-ns -l=app=nginx
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.
Aceda à página Explorador de registos na Trusted Cloud consola.
No campo Consulta, especifique o seguinte para obter registos de auditoria do modo
audit
eenforce
: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")
Clique em Executar consulta.
Na secção Resultados da consulta, expanda a entrada de registo
Forbidden
para inspecionar os registos de rejeição do modoenforce
. 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" }
Expanda a entrada do registo
audit-violations
para inspecionar os registos do modoaudit
. 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 PodSecurity
controlador 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?
- Saiba mais sobre as normas de segurança de pods.
- Saiba mais sobre o
PodSecurity
controlador de admissão. - Migre da PodSecurityPolicy para o controlador de admissão
PodSecurity
.