Photo by Vlad Tchompalov on Unsplash
Use a Postura de Segurança do GKE para detectar problemas e acabar com as preocupações
Introdução
Recentemente o Google Cloud disponibilizou para o público o painel de Postura de segurança do GKE (GKE Security Posture em inglês), que é uma ferramenta nativa e tem uma importante função na estratégia de simplificar o gerenciamento de segurança e melhorar a proteção de seus clusters do Google Kubernetes Engine (GKE). Esse painel traz uma gama de recursos para detectar configuração incorreta, ou má configuração, em clusters e cargas de trabalho (workloads) do GKE, e verificar vulnerabilidades em imagens de contêiner. Com isso o painel oferece recomendações, sejam elas opinativas ou acionáveis, para fortalecer a sua postura de segurança e garantir que suas aplicações estejam seguras.
Como funciona
Para utilizar o painel de Postura de segurança basta habilitar um ou mais recursos com suporte em clusters que possuem versões compatíveis. Os recursos do painel de Postura de segurança são classificados nos seguintes tipos:
Postura de segurança do Kubernetes que provê duas funcionalidades:
Verificação da configuração da carga de trabalho - Verifica automaticamente a configuração de todas as cargas de trabalho do Kubernetes em execução nos clusters, como as especificações de Pods, Jobs e StatefulSets.
Exibição do boletim de segurança acionável - Quando uma vulnerabilidade é descoberta no GKE, a Google realiza a correção da vulnerabilidade e publica um boletim de segurança para a vulnerabilidade.
Como ativar:
- Disponível para ativação no modo Autopilot ou Standard do GKE que possuem versão 1.21 e posterior. Vale ressaltar que é ativado automaticamente em ambos os modos quando você cria novos clusters executando a versão 1.27 e posterior.
Scan de vulnerabilidade da contêiner: Verifica automaticamente as imagens de contêiner nas cargas de trabalho em execução para encontrar vulnerabilidades conhecidas e conseguir estratégias acionáveis de mitigação, se disponíveis. Atualmente temos duas classes, que são a Standard (flag
standard
) e a Advanced vulnerability insights (flagenterprise
) que está em Preview, cada uma conta com suas capacidades de scan.Como ativar a classe standard:
No modo Autopilot do GKE está disponível para ativação na versão 1.23.5-gke.700 e posterior. É ativado automaticamente neste modo quando você cria novos clusters executando a versão 1.27 e posterior.
No modo Standard do GKE está disponível para ativação na versão 1.23.5-gke.700 e posterior. Não é ativado automaticamente neste modo em nenhuma versão.
Como ativar a classe enterprise:
O cluster precisar estar na versão 1.27 ou superior.
É desabilitado por padrão em ambos modos, Autopilot e Standard, do GKE.
O GKE verifica os clusters cadastrados e executa cargas de trabalho. O painel de postura de segurança no console do Google Cloud exibe os resultados da verificação e fornece recomendações acionáveis para preocupações, quando aplicável. O GKE também envia logs ao Cloud Logging para auditoria e rastreabilidade.
Preço
Muito interessante até aqui, mas quanto vou precisar investir?
De acordo com a documentação oficial, atualmente os recursos de verificação e o painel no console do Google Cloud são oferecidos sem qualquer custo financeiro. Já as informações adicionadas ao Cloud Logging usam os preços do Cloud Logging.
Pelo fato do Scan de vulnerabilidade de pacote de linguagens estar em Preview (na data em que escrevo este post), também não há custos.
Pré-requisitos
Para ativar as verificações, precisamos como pré-requisito habilitar as seguintes APIs no projeto:
Google Kubernetes Engine API;
Container Security API;
Artifact Analysis API (apenas se desejar utilizar o Insight avançado de vulnerabilidades de está em Preview).
Para isso abra o seu Cloud Shell e execute o comando usando o gcloud:
gcloud services enable container.googleapis.com containersecurity.googleapis.com containeranalysis.googleapis.com
Verifique se foram ativados com sucesso executando:
gcloud services list | grep -E "container.googleapis.com|containersecurity.googleapis.com|containeranalysis.googleapis.com"
Se o output for igual o abaixo, significa que as APIs estão devidamente ativadas:
NAME: container.googleapis.com
NAME: containeranalysis.googleapis.com
NAME: containersecurity.googleapis.com
Podemos ativar a Verificação de configuração de workload e o Scan de vulnerabilidade de contêiner em novos cluster ou cluster já em execução, usando a CLI do Google Cloud ou o console do Google Cloud.
Ativando a Verificação da configuração da carga de trabalho
Vamos ativar manualmente esse recurso usando a CLI gcloud
. E só pra lembrar, a verificação de postura de segurança do Kubernetes é habilitada por padrão nos novos clusters Autopilot e Standard executando a versão 1.27 e posterior.
Criando um novo cluster
Vamos criar um novo cluster do GKE, em modo Autopilot para facilitar, com a Verificação de configuração de workload e o Scan de vulnerabilidade de contêiner ativos, usando o comando:
gcloud container clusters create-auto NOME_DO_CLUSTER --region=REGIAO_DO_COMPUTE --security-posture=standard
Substitua:
NOME_DO_CLUSTER
: o nome desejado para o novo cluster.REGIAO_DO_COMPUTE
: a região do Compute Engine do cluster. Para clusters Standard de zona, utilizezone=ZONA_DO_COMPUTE
. Ao não especificar uma rede, será utilizado a rede default do projeto. Para especificar uma rede basta adicionar--network=O_NOME_DA_SUA_REDE
e para especificar uma subnet utilize--subnetwork=O_NOME_DA_SUA_SUBNET
O meu comando completo, por exemplo, ficou assim:
gcloud container clusters create-auto gkesp-cluster --region=us-south1 --security-posture=standard
A criação do seu cluster deve demorar alguns minutos. No meu caso demorou cerca de 10 minutos.
Após finalizado a criação tive o seguinte output:
kubeconfig entry generated for gkesp-cluster.
NAME: gkesp-cluster
LOCATION: us-south1
MASTER_VERSION: 1.27.3-gke.100
MASTER_IP: 34.174.116.159
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.27.3-gke.100
NUM_NODES: 3
STATUS: RUNNING
Para confirmar que está conseguindo utilizar o kubectl
execute:
kubectl get nodes
O seu output deve ser parecido com:
NAME STATUS ROLES AGE VERSION
gk3-gkesp-cluster-default-pool-4e549890-l72s Ready <none> 10m v1.27.3-gke.100
Ativando em um cluster existente
É possível ativar a verificação da configuração de workload e o scan de vulnerabilidade da contêiner (workload) em um cluster existente, para isso precisamos executar dois comandos de atualização separadamente.
Execute o comando para ativar a verificação da configuração de workload:
gcloud container clusters update NOME_DO_CLUSTER --region=REGIAO_DO_COMPUTE --security-posture=standard
Substitua:
NOME_DO_CLUSTER
: o nome desejado para o novo cluster.REGIAO_DO_COMPUTE
: a região do Compute Engine do cluster. Para clusters Standard de zona, utilizezone=ZONA_DO_COMPUTE
.
Validando a ativação
Para validar se tudo foi devidamente ativo via CLI execute:
gcloud container clusters describe NOME_DO_CLUSTER --region=REGIAO_DO_COMPUTE | grep securityPostureConfig -A 2
O seu output deve ser parecido com:
securityPostureConfig:
mode: BASIC
vulnerabilityMode: VULNERABILITY_MODE_UNSPECIFIED
Para validar via console do Google Cloud vá em Kubernetes Engine > Clusters > Clique sobre o nome do seu cluster criado anteriormente, vá na sessão de Segurança e verifique se o item Postura de segurança está como "Ativado".
Criando um workload para teste
Para testar vamos criar um Pod, com uma imagem de contêiner simples chamado busybox, que viola de forma intencional os padrões de segurança do Pod.
Salve o manifesto abaixo como
app-problema.yaml
em seu Cloud Shell:apiVersion: apps/v1 kind: Deployment metadata: name: app-problema labels: app: problema spec: selector: matchLabels: app: problema tier: web template: metadata: labels: app: problema tier: web spec: containers: - name: appbusy-problema image: busybox:1.28 command: [ "sh", "-c", "sleep 1h" ] securityContext: runAsNonRoot: false resources: requests: cpu: 200m
Crie o deployment em seu cluster:
kubectl apply -f app-problema.yaml
Output do comando:
deployment.apps/app-problema created
Aguarde a criação do deployment e para validar execute:
kubectl get deploy app-problema
Se o output for parecido com o abaixo, significa que o deployment está em execução.
NAME READY UP-TO-DATE AVAILABLE AGE
app-problema 1/1 1 1 87s
Podemos visualizar o deployment no console do Google Cloud em Kubernetes Engine > Cargas de trabalho.
Verificando os resultados no painel de Postura de segurança
Após ativação o scan leva cerca de 15 minutos para retornar os resultados. Para verificar basta ir no painel de Postura de segurança dentro do GKE.
Vá em Kubernetes Engine > Postura de segurança e então visualizará o Painel com uma visão geral dos Problemas, Tipos, Clusters e Cargas de trabalho.
Na parte inferior do painel observamos mais informações sobre as más configurações e vulnerabilidades descobertas.
Clique na aba Problemas para listar todos.
Também é possível filtrar marcando a caixa desejada, seja por Gravidade, Tipo de preocupação, Local do seu workload e Cluster do GKE.
Verificando os detalhes do problema e recomendações
Vamos visualizar as informações detalhadas sobre uma preocupação de configuração específica, para isso clique na linha que contém essa preocupação.
Por exemplo, clique na preocupação "O contêiner do pod permite o escalonamento de privilégios na execução" e são exibidas as seguintes informações:
Descrição: uma breve descrição da preocupação.
Ação recomendada: uma lista das ações que podem ser realizadas para corrigir o problema de configuração, incluindo detalhes como:
Quais são os recursos que precisam ser corrigidos;
Comandos de exemplo que podem ser executados para aplicar a correção aos recursos afetados;
Se aplicável, as instruções do console do Google Cloud para corrigir o problema.
Verificando os problemas descobertos no Cloud Logging
O GKE por padrão adiciona os registros ao Cloud Logging para cada problema descoberto, vamos entender como verificar estes logs.
Acesse o Buscador de registros, para isso basta pesquisar no campo de pesquisa por Logs Explorer e clicar, ou clique no link abaixo:
Acessar o Buscador de registros
No campo Consulta, insira a seguinte consulta:
resource.type="k8s_cluster" jsonPayload.@type="type.googleapis.com/cloud.kubernetes.security.containersecurity_logging.Finding" jsonPayload.type="FINDING_TYPE_MISCONFIG"
Por fim, clique em Gerar consulta (Run query).
Caso não tenha nenhum retorno, se atente no período que está realizando a consulta.
Exemplo do Log da preocupação "O contêiner do pod permite o escalonamento de privilégios na execução", que vimos anteriormente pela console.
{
"insertId": "1e8dghoas",
"jsonPayload": {
"finding": "PRIVILEGE_ESCALATION",
"resourceName": "apps/v1/namespaces/default/Deployment/appweb-hello",
"type": "FINDING_TYPE_MISCONFIG",
"@type": "type.googleapis.com/cloud.kubernetes.security.containersecurity_logging.Finding",
"state": "ACTIVE",
"severity": "SEVERITY_MEDIUM"
},
"resource": {
"type": "k8s_cluster",
"labels": {
"project_id": "615537239033",
"location": "us-south1",
"cluster_name": "gkesp-cluster"
}
},
"timestamp": "2023-08-22T19:23:48.526604578Z",
"severity": "INFO",
"logName": "projects/gkesecurityposture-demo/logs/containersecurity.googleapis.com%2Ffinding",
"receiveTimestamp": "2023-08-22T19:23:49.138710074Z"
}
Resolvendo problemas de Configuração
Vamos corrigir os problemas de configuração previamente encontrados.
Edite o manifesto
app-problema.yaml
, usado para criar o deployment, e configure conforme abaixo:apiVersion: apps/v1 kind: Deployment metadata: name: app-problema labels: app: problema spec: selector: matchLabels: app: problema tier: web template: metadata: labels: app: problema tier: web spec: containers: - name: appbusy-problema image: busybox:1.28 command: [ "sh", "-c", "sleep 1h" ] securityContext: runAsUser: 1000 # Executar com o User ID 1000 runAsNonRoot: true # Não permitir a execução como root allowPrivilegeEscalation: false # Não permitir a elevação de privilégio resources: requests: cpu: 200m
Entendendo as modificações que realizamos no manifesto para corrigir os problemas:
O campo
spec.containers[*].securityContext.runAsUser
configurado com o valor 1000, especificará que todos os containers no Pod, e todos os processos executem com o user ID 1000.O campo
spec.containers[*].securityContext.runAsNonRoot
configurado com o valortrue
, resolverá a preocupação de "O contêiner do pod pode ser executado como raiz".O campo
spec.containers[*].securityContext.allowPrivilegeEscalation
configurado com o valorfalse
, resolverá a preocupação de "O contêiner do pod permite o escalonamento de privilégios na execução".
Aplique as alterações executando o comando:
kubectl apply -f app-problema.yaml
O seu output deve ser parecido com:
deployment.apps/appweb-hello configured
Vamos aguardar 15 minutos para que a verificação seja concluída e o painel seja atualizado.
Após a verificação, podemos observar que não consta mais nenhum problema no painel.
Verificando logs de remediação dos problemas no Cloud Logging
Podemos usar o Cloud Logging para verificar exatamente o horário que os problemas foram remediados.
Acesse o Buscador de registros (Logs explorer).
No campo Consulta, insira a seguinte consulta:
resource.type="k8s_cluster" jsonPayload.@type="type.googleapis.com/cloud.kubernetes.security.containersecurity_logging.Finding" jsonPayload.type="FINDING_TYPE_MISCONFIG" jsonPayload.state="REMEDIATED"
Por fim, clique em Gerar consulta (Run query).
Então devemos ter dois registros como resultado da consulta. Abaixo temos um exemplo do Log que foi remediado, da preocupação "O contêiner do pod permite o escalonamento de privilégios na execução".
{
"insertId": "17kld9san",
"jsonPayload": {
"eventTime": "2023-08-22T19:53:50.692473470Z",
"state": "REMEDIATED",
"resourceName": "apps/v1/namespaces/default/Deployment/appweb-hello",
"severity": "SEVERITY_MEDIUM",
"type": "FINDING_TYPE_MISCONFIG",
"finding": "PRIVILEGE_ESCALATION",
"@type": "type.googleapis.com/cloud.kubernetes.security.containersecurity_logging.Finding"
},
"resource": {
"type": "k8s_cluster",
"labels": {
"cluster_name": "gkesp-cluster",
"location": "us-south1",
"project_id": "615537239033"
}
},
"timestamp": "2023-08-22T19:53:50.711924469Z",
"severity": "INFO",
"logName": "projects/gkesecurityposture-demo/logs/containersecurity.googleapis.com%2Ffinding",
"receiveTimestamp": "2023-08-22T19:53:50.928852982Z"
}
Conclusão
Quem deseja melhorar a segurança das suas cargas de trabalho e não pode investir muito, a Postura de segurança do GKE vai te ajudar a fazer o básico bem feito, de forma nativa da nuvem (cloud native) e sem qualquer custo. O painel é intuitivo, direto ao ponto e os problemas encontrados tem um ótimo detalhamento, que facilita o entendimento e correção, para que você se livre das preocupações.
Por se tratar de uma ferramenta nova, tem pontos de melhoria, como:
Atualmente o tempo de verificação leva cerca de 15 minutos, mas poderia ser menor.
Uma visão no painel de Postura de segurança do GKE sobre os problemas corrigidos ajudaria muito no acompanhamento da evolução de postura de segurança em um ambiente produtivo com dezenas de clusters em execução.
Pra saber a hora exata em que um problema foi remediado, preciso verificar as logs de remediação no Cloud Logging, facilitaria se pudesse fazer isso diretamente no painel de Postura de segurança do GKE.
Para finalizar, mesmo com os pontos de melhoria que mencionei acima, eu gostei muito desta adição. Vejo que o Google está constante evoluindo todos os seus produtos do Google Cloud, principalmente os focado em Segurança e em breve devem melhorar ainda mais.
Espero ter te agregado algum conhecimento e obrigado por ler até aqui! Em caso de dúvidas e melhorias estou à disposição.
Me siga para acompanhar novas publicações e até breve!
Referências
(Google Cloud Blog - GKE Security Posture dashboard now generally available with enhanced features, 2023) https://cloud.google.com/blog/products/identity-security/gke-security-posture-now-generally-available-with-enhanced-features
(Google Cloud - About the security posture dashboard, 2023) https://cloud.google.com/kubernetes-engine/docs/concepts/about-security-posture-dashboard
(Google Cloud - About Kubernetes security posture scanning, 2023) https://cloud.google.com/kubernetes-engine/docs/concepts/about-configuration-scanning
(Google Cloud - Automatically scan workloads for configuration issues, 2023) https://cloud.google.com/kubernetes-engine/docs/how-to/protect-workload-configuration
(Google Cloud - Cloud SDK, 2023) https://cloud.google.com/sdk/gcloud/reference/container/clusters/create
(Kubernetes Documentation - Pod Security Standards, 2023) https://kubernetes.io/docs/concepts/security/pod-security-standards/