Com a velocidade do desenvolvimento no Kubernetes, muitas vezes há novos recursos de segurança para você usar. Nesta página, orientamos você na implementação de nossas diretrizes atuais para proteger seu cluster do Google Kubernetes Engine (GKE).
Neste guia, priorizamos as medidas de mitigação dos riscos de segurança em situações em que a segurança é particularmente importante e que exigem a intervenção do cliente no momento da criação do cluster. Recursos menos críticos, configurações de segurança padrão e funções que podem ser ativadas após a criação do cluster são mencionados posteriormente no documento. Para ver informações gerais sobre os tópicos de segurança, leia a Visão geral de segurança.
Muitas dessas recomendações, bem como outros erros de configuração comuns, podem ser verificados automaticamente usando a análise de integridade de segurança.
Quando as recomendações abaixo forem referentes a uma recomendação de referência do CIS para GKE essas serão especificadas.
Fazer upgrade da infraestrutura GKE em tempo hábil
Recomendação de referência do CIS para GKE: 6.5.3. Verificar se o upgrade automático de nós está ativado para os nós do GKE
Manter a versão do Kubernetes atualizada é uma das ações mais simples para melhorar sua segurança. O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança.
Consulte os boletins de segurança do GKE para conferir informações sobre patches de segurança.
No Google Kubernetes Engine, os planos de controle são corrigidos e atualizados automaticamente. Também é possível manter os nós do cluster atualizados com upgrades automáticos.
Se você optar por desativar o upgrade automático do nó, recomendamos fazer o upgrade mensal conforme sua programação. Os clusters mais antigos precisam ativar o upgrade automático de nós e acompanhar de perto os boletins de segurança do GKE para patches críticos.
Para saber mais, consulte Como fazer o upgrade automático dos nós.
Restringir o acesso à rede ao plano de controle e aos nós
Recomendações de referência do CIS para GKE: 6.6.2. Preferir clusters nativos de VPC, 6.6.3. Verificar se a rede autorizada principal está ativada, 6.6.4. Verificar se os clusters foram criados com o endpoint privado ativado e o acesso público desativado, e 6.6.5. Verificar se os clusters foram criados com os nós particulares
Limite a exposição do plano de controle de cluster e nós à Internet. Essas configurações só podem ser definidas no momento da criação do cluster.
Por padrão, os nós e o plano de controle do cluster do GKE têm endereços de Internet roteáveis que podem ser acessados de qualquer endereço IP.
Para o plano de controle do cluster do GKE, consulte Como criar um cluster particular. Há três tipos diferentes de clusters particulares que podem fornecer proteção no nível de rede:
- Acesso ao endpoint público desativado: essa é a opção mais segura, já que evita todo o acesso à Internet para planos de controle e nós. É a escolha mais adequada se você configurou sua rede no local para se conectar ao Google Cloud usando o Cloud Interconnect e o Cloud VPN. Essas tecnologias conectam efetivamente a rede da empresa à nuvem VPC.
- Acesso ao endpoint público ativado, redes autorizadas ativadas (recomendado): esta opção dá acesso restrito ao plano de controle a partir dos endereços IP de origem que você definir. Essa é uma ótima opção se você não tem uma infraestrutura de VPN ou se tem usuários remotos ou filiais que se conectam pela Internet pública em vez da VPN corporativa, do Cloud Interconnect ou do Cloud VPN.
- Acesso ao endpoint público ativado, redes autorizadas desativadas: este é o padrão e permite que qualquer pessoa na Internet faça conexões de rede com o plano de controle.
Para desativar o acesso direto à Internet nos nós, especifique a opção --enable-private-nodes da CLI gcloud na criação do cluster.
Isso informa ao GKE para provisionar os nós com endereços IP internos, o que significa que os nós não são alcançáveis diretamente pela Internet pública.
Recomendamos que os clusters usem, pelo menos, redes autorizadas e nós particulares. Isso garante que o plano de controle seja acessível por:
- CIDRs permitidos em redes autorizadas;
- nós na VPC do cluster;
- jobs de produção internos do Google que gerenciam o plano de controle.
Isso corresponde às seguintes sinalizações gcloud no momento da criação do cluster:
--enable-ip-alias--enable-private-nodes--enable-master-authorized-networks
Usar regras de firewall de privilégio mínimo
Minimizar o risco de acesso não intencional usando o princípio do menor privilégio para regras de firewall
O GKE cria regras de firewall VPC padrão para ativar a funcionalidade do sistema e aplicar boas práticas de segurança. Para uma lista completa de regras de firewall criadas automaticamente, consulte Regras de firewall criadas automaticamente.
O GKE cria essas regras de firewall padrão com uma prioridade de 1.000. Se você criar regras de firewall permissivas com uma prioridade mais alta, como uma regra de firewall allow-all para depuração, seu cluster corre o risco de acesso não intencional.
Autenticação de grupo
Recomendação de referência do CIS para GKE: 6.8.3. Gerencie usuários RBAC do Kubernetes com os Grupos do Google para GKE
Use grupos para gerenciar seus usuários. Isso permite que as identidades sejam controladas usando seu sistema de gerenciamento de identidades e administradores de identidade. O ajuste da participação no grupo dispensa a atualização da configuração RBAC sempre que alguém for adicionado ou removido do grupo.
Para gerenciar permissões de usuário no Grupos do Google, ative Grupos do Google para RBAC no cluster. Isso permite que você gerencie facilmente os usuários com as mesmas permissões e permite que os administradores de identidade gerenciem os usuários de maneira centralizada e consistente.
Consulte Grupos do Google para RBAC para instruções sobre como ativar os Grupos do Google para RBAC.
Opções de nós do contêiner
As seções a seguir descrevem as opções de configuração de nós seguros.
Ativar os nós protegidos do GKE
Recomendação de referência do CIS para GKE: 6.5.5. Verificar se os nós do GKE protegidos estão ativados
Os nós do GKE protegidos fornecem identidade e integridade de nó confiável para aumentar a segurança dos nós do GKE e precisam ser ativados em todos os clusters do GKE.
É possível ativar os nós do GKE protegidos na criação ou atualização do cluster. Nós do GKE protegidos precisam ser ativados com inicialização segura. A inicialização segura não poderá ser usada se você precisar de módulos de kernel não assinados de terceiros. Para instruções sobre como ativar nós protegidos do GKE e como ativar a inicialização segura com nós protegidos do GKE, consulte Como usar nós protegidos do GKE.
Escolha uma imagem de nó com aumento da proteção junto com o ambiente de execução containerd
A imagem do Container-Optimized OS com containerd (cos_containerd) é uma variante da imagem que usa o containerd como ambiente de execução principal de contêineres e tem integração direta com o Kubernetes.
O containerd (em inglês) é o principal componente do ambiente de execução do Docker e foi projetado para fornecer a funcionalidade central da interface de ambiente de execução de contêiner (CRI, na sigla em inglês) do Kubernetes. Ele é significativamente menos complexo que o daemon Docker completo e, portanto, tem uma superfície de ataque menor.
Para usar a imagem cos_containerd no cluster, consulte Imagens de contêiner.
A imagem cos_containerd é a preferencial para o GKE porque foi personalizada, otimizada e reforçada com aumento da proteção especificamente para executar contêineres.
Ativar a federação de identidade da carga de trabalho do GKE
Recomendação de referência do CIS para GKE: 6.2.2. Prefira usar as contas de serviço e o recurso Identidade da carga de trabalho do Google Cloud dedicadas
A federação de identidade da carga de trabalho do GKE é a maneira recomendada de autenticação nas APIs do Google Cloud.
A federação de identidade da carga de trabalho do GKE substitui a necessidade de usar a ocultação de metadados, e, por isso, as duas abordagens são incompatíveis. Os metadados confidenciais protegidos por ocultação de metadados também são protegidos pela federação de identidade da carga de trabalho do GKE.
Como aumentar a proteção do isolamento da carga de trabalho com o GKE Sandbox
Recomendação de referência do CIS para GKE: 6.10.4. Considere o GKE Sandbox para aumentar o isolamento da carga de trabalho, especialmente para cargas de trabalho não confiáveis
O GKE Sandbox fornece uma camada extra de segurança para evitar que códigos maliciosos afetem o kernel do host nos nós do cluster.
É possível executar contêineres em um ambiente sandbox para reduzir a maioria dos ataques de escape, também chamados de ataques de escalonamento de privilégios locais. Para vulnerabilidades de escape de contêineres anteriores, consulte os boletins de segurança. Esse tipo de ataque permite que um invasor tenha acesso à VM host do contêiner e, portanto, tenha acesso a outros contêineres na mesma VM. Um sandbox como o GKE Sandbox pode ajudar a limitar o impacto desses ataques.
Considere colocar uma carga de trabalho no sandbox em situações como estas:
- A carga de trabalho executa um código não confiável
- Você quer limitar o impacto se um invasor comprometer um contêiner na carga de trabalho.
Saiba como usar o GKE Sandbox em Como aumentar o isolamento de cargas de trabalho com o GKE Sandbox.
Ativar notificações do boletim de segurança
Quando os boletins de segurança estão disponíveis e são relevantes para o cluster, o GKE publica notificações sobre esses eventos como mensagens para tópicos do Pub/Sub que você configura. É possível receber essas notificações em uma assinatura do Pub/Sub, fazer a integração com serviços de terceiros e filtrar os tipos de notificação que você quer receber.
Para mais informações sobre como receber boletins de segurança usando notificações de cluster do GKE, consulte Notificações de cluster.
Permissões
Usar contas de serviço do IAM com privilégios mínimos
Recomendação de referência do CIS para GKE: 6.2.1. Preferir não executar clusters do GKE usando a conta de serviço padrão do Compute Engine
Cada nó do GKE tem uma conta de serviço do gerenciamento de identidade e acesso (IAM) associada a ele. Por padrão, os nós recebem a conta de serviço padrão do Compute Engine, que pode ser encontrada na seção "IAM" do Console do Google Cloud. Essa conta tem acesso amplo por padrão, o que a torna útil para uma grande variedade de aplicativos, mas tem mais permissões do que as necessárias para executar o cluster do Kubernetes Engine. Crie e use uma conta de serviço com privilégios mínimos para seus nós usarem em vez da conta de serviço padrão do Compute Engine.
Com o lançamento da federação de identidade da carga de trabalho para o GKE, sugerimos um caso de uso mais limitado para a conta de serviço do nó. Esperamos que a conta de serviço do nó seja usada pelos daemons do sistema responsáveis pela geração de registros, pelo monitoramento e por tarefas semelhantes. As cargas de trabalho em pods precisam ser identidades provisionadas com a federação de identidade de carga de trabalho para o GKE.
O GKE exige, no mínimo, que a conta de serviço tenha os
papéis monitoring.viewer,
monitoring.metricWriter, logging.logWriter, stackdriver.resourceMetadata.writer e autoscaling.metricsWriter.
Leia mais sobre papéis de monitoramento e papéis de geração de registro.
Os seguintes comandos criam uma conta de serviço do IAM com as permissões mínimas necessárias para operar o GKE. Também é possível usar a conta de serviço para recursos em outros projetos. Para ver instruções, consulte Como ativar a representação da conta de serviço em projetos.
gcloud
gcloud iam service-accounts create SA_NAME \
--display-name=DISPLAY_NAME
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/monitoring.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/stackdriver.resourceMetadata.writer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
--role roles/autoscaling.metricsWriter
Substitua:
SA_NAME: o nome da nova conta de serviço.DISPLAY_NAME: o nome de exibição da nova conta de serviço, o que facilita a identificação da conta.PROJECT_ID, o ID do projeto em que você quer criar a nova conta de serviço.
Config Connector
Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.
Para criar a conta de serviço, faça o download do seguinte recurso como
service-account.yaml.Substitua:
SA_NAME: o nome da nova conta de serviço.DISPLAY_NAME: o nome de exibição da nova conta de serviço, o que facilita a identificação da conta.
Depois, execute:
kubectl apply -f service-account.yaml
Aplique o papel
logging.logWriterà conta de serviço. Faça o download do seguinte recurso comopolicy-logging.yaml. Substitua[SA_NAME]e[PROJECT_ID]por suas próprias informações.kubectl apply -f policy-logging.yaml
Aplique o papel
monitoring.metricWriter. Faça o download do seguinte recurso comopolicy-metrics-writer.yaml. Substitua[SA_NAME]e[PROJECT_ID]por suas próprias informações.kubectl apply -f policy-metrics-writer.yaml
Aplique o papel
monitoring.viewer. Faça o download do seguinte recurso comopolicy-monitoring.yaml. Substitua[SA_NAME]e[PROJECT_ID]por suas próprias informações.kubectl apply -f policy-monitoring.yaml
Aplique o papel
autoscaling.metricsWriter. Faça o download do seguinte recurso comopolicy-autoscaling-metrics-writer.yaml. Substitua[SA_NAME]e[PROJECT_ID]por suas próprias informações.kubectl apply -f policy-autoscaling-metrics-writer.yaml
Conceder acesso a repositórios de imagens particulares
Para usar imagens particulares no Artifact Registry, conceda o
papel de leitor do Artifact Registry
(roles/artifactregistry.reader) à conta de serviço.
gcloud
gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
--member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--role=roles/artifactregistry.reader
Substitua REPOSITORY_NAME pelo nome do repositório do
Artifact Registry.
Config Connector
Observação: esta etapa requer o Config Connector. Siga estas instruções para instalar o Config Connector no cluster.
Salve o seguinte manifesto como
policy-artifact-registry-reader.yaml:Substitua:
- SA_NAME: o nome da conta de serviço do IAM.
- PROJECT_ID: é seu ID do projeto no Google Cloud.
- REPOSITORY_NAME: o nome do repositório do Artifact Registry
Conceda o papel de leitor do Artifact Registry à conta de serviço:
kubectl apply -f policy-artifact-registry-reader.yaml
Se você usa imagens particulares no Google Container Registry, também precisa conceder acesso a elas:
gsutil
gsutil iam ch \
serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
gs://BUCKET_NAME
O intervalo que armazena as imagens tem o nome BUCKET_NAME do formulário:
artifacts.PROJECT_ID.appspot.compara imagens enviadas para um registro no hostgcr.ioouSTORAGE_REGION.artifacts.PROJECT_ID.appspot.com
Substitua:
PROJECT_ID: é o ID do projeto no Console do Google Cloud.STORAGE_REGION: é o local do bucket de armazenamento:uspara registros no hostus.gcr.ioeupara registros no hosteu.gcr.ioasiapara registros no hostasia.gcr.io
Consulte a documentação do gsutil iam
para mais informações sobre o comando.
Config Connector
Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.
Aplique o papel storage.objectViewer à sua conta de serviço. Faça o download do seguinte recurso como policy-object-viewer.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.
kubectl apply -f policy-object-viewer.yaml
Se quiser que outro usuário humano possa criar novos clusters ou pools de nós com essa conta de serviço, conceda a ele o papel Usuário de conta de serviço nesta conta de serviço:
gcloud
gcloud iam service-accounts add-iam-policy-binding \
SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--member=user:USER \
--role=roles/iam.serviceAccountUserConfig Connector
Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.
Aplique o papel iam.serviceAccountUser à sua conta de serviço. Faça o download do seguinte recurso como policy-service-account-user.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.
kubectl apply -f policy-service-account-user.yaml
Para clusters padrão atuais, agora é possível criar um novo pool de nós com essa nova conta de serviço. Para clusters do Autopilot, é necessário criar um novo cluster com a conta de serviço. Para acessar instruções, consulte Criar um cluster do Autopilot.
Crie um pool de nós que use a nova conta de serviço:
gcloud container node-pools create NODE_POOL_NAME \ --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --cluster=CLUSTER_NAME
Se você precisar que o cluster do GKE tenha acesso a outros serviços do Google Cloud, use a federação de identidade da carga de trabalho para o GKE.
Restringir o acesso à descoberta de APIs do cluster
Por padrão, o Kubernetes inicializa clusters com um conjunto permissivo de ClusterRoleBindings de detecção, que fornece amplo acesso a informações sobre as APIs de um cluster, incluindo aquelas de CustomResourceDefinitions (em inglês).
Os usuários precisam estar cientes de que o grupo system:authenticated incluído nos assuntos dos ClusterRoleBindings system:discovery e system:basic-user pode incluir qualquer usuário autenticado (incluindo qualquer pessoa com uma Conta do Google) e não representa um nível significativo de segurança para clusters no GKE. Para mais informações, consulte
Evitar papéis e grupos padrão.
Para usar as APIs de descoberta do cluster, considere uma ou mais das seguintes opções:
- Configurar redes autorizadas para restringir o acesso a intervalos de IP definidos.
- Configurar um cluster particular para restringir o acesso a um VPC.
Se nenhuma dessas opções for adequada ao caso de uso do GKE, trate todas as informações de descoberta de API (ou seja, o esquema de CustomResources, definições de APIService e informações de descoberta hospedadas pelos servidores da API de extensão) como divulgado publicamente.
Ambas as opções permitem acesso ao endereço IP do servidor da API do Cloud Run e do Cloud Functions. Esse acesso está sendo removido. Portanto, não confie nesses serviços para se comunicar com o servidor de API. Para mais informações, consulte a postagem do blog do Google Cloud.
Usar namespaces e RBAC para restringir o acesso aos recursos do cluster
Recomendação de referência do CIS para GKE: 5.6.1. Criar limites administrativos entre recursos usando namespaces
Conceda aos grupos privilégios mínimos de acesso ao Kubernetes criando namespaces ou clusters separados para cada equipe e ambiente. Atribua centros de custo e rótulos apropriados a cada namespace para responsabilidade e estorno. Forneça aos desenvolvedores o nível de acesso ao namespace necessário para implantar e gerenciar o aplicativo, especialmente na produção. Mapeie as tarefas que os usuários precisam executar no cluster e defina as permissões necessárias para executar cada tarefa.
Para saber mais sobre a criação de namespaces, consulte a documentação do Kubernetes. Para ver as práticas recomendadas ao planejar a configuração do RBAC, consulte Práticas recomendadas para o RBAC do GKE.
O IAM e o Controle de acesso baseado em papéis (RBAC, na sigla em inglês) trabalham em conjunto, e uma entidade precisa ter permissões suficientes em qualquer nível para trabalhar com recursos no cluster.
Atribua os Papéis do IAM apropriados para o GKE relacionados a grupos e usuários para fornecer permissões no nível do projeto e usar RBAC para conceder permissões em um nível de cluster e de namespace. Para saber mais, consulte Controle de acesso.
É possível usar as permissões do IAM e do RBAC em conjunto com namespaces para restringir interações de usuários com recursos de cluster no console do Google Cloud. Saiba mais em Ativar acesso e visualização de recursos do cluster por namespace.Restringir o tráfego entre pods com uma política de rede
Recomendação de referência do CIS para GKE: 6.6.7. Verificar se a política de rede está ativada e fazer as configurações adequadas
Por padrão, todos os pods em um cluster podem se comunicar uns com os outros. Controle a comunicação de pod para o pod conforme necessário para suas cargas de trabalho.
Restringir o acesso à rede aos serviços dificulta muito a migração lateral dos invasores dentro do cluster, além de oferecer aos serviços alguma proteção contra negação de serviço acidental ou deliberada. Veja as duas maneiras recomendadas de controlar o tráfego:
- Use o Istio. Consulte Como instalar o Istio no Google Kubernetes Engine se você tiver interesse em balanceamento de carga, autorização de serviço, limitação, cota, métricas e muito mais.
- Use políticas de rede do Kubernetes. Consulte Como criar uma política de rede de cluster. Escolha essa opção se você estiver procurando a funcionalidade básica de controle de acesso exposta pelo Kubernetes. Para implementar abordagens comuns a fim de restringir o tráfego usando políticas de rede, siga o guia de implementação dos blueprints de segurança do GKE Enterprise. Além disso, a documentação do Kubernetes tem um tutorial incrível para uma implantação simples do nginx. Use o registro de políticas de rede para verificar se as políticas de rede estão funcionando conforme o esperado.
O Istio e a Política de rede podem ser usados em conjunto se isso for necessário.
Gerenciamento de secrets
Recomendação de referência do CIS para GKE: 6.3.1. Criptografar secrets do Kubernetes usando chaves gerenciadas no Cloud KMS
Forneça uma camada adicional de proteção para dados confidenciais, como secrets, armazenados em etcd (em inglês). Para fazer isso, configure um gerenciador de secrets integrado aos Clusters do GKE. Algumas soluções vão funcionar no GKE e no GKE on VMware e, por isso, poderão ser preferenciais ao executar cargas de trabalho em vários ambientes. Se você optar por usar um gerenciador de secrets externos, como o HashiCorp Vault, convém ter essa configuração antes de criar seu cluster.
Há várias opções de gerenciamento de secrets.
- É possível usar os secrets do Kubernetes nativamente no GKE. Como alternativa, é possível criptografá-los na camada de aplicativos com uma chave gerenciada, usando a criptografia de secrets da camada de aplicativos.
- É possível usar um gerenciador de secrets, como HashiCorp Vault. Quando executado em um modo de HA aprimorado, isso fornecerá uma maneira consistente e pronta para produção para gerenciar secrets. É possível se autenticar no HashiCorp Vault usando uma conta de serviço do Kubernetes ou uma conta de serviço do Google Cloud. Para saber mais sobre como usar o GKE com o Vault, consulte Como executar e conectar ao HashiCorp Vault no Kubernetes.
As VMs do GKE são criptografadas na camada de armazenamento por padrão, o que inclui o etcd.
Use os controladores de admissão para aplicar a política
Os controladores de admissão (em inglês) são plug-ins que regem e impõem o modo como o cluster é usado. Eles precisam ser ativados para usar alguns dos recursos de segurança mais avançados do Kubernetes e são uma parte importante da defesa em profundidade para proteger seu cluster
Por padrão, os pods no Kubernetes podem operar com recursos além do que eles exigem. Restrinja os recursos do pod apenas àqueles necessários para essa carga de trabalho.
O Kubernetes é compatível com vários controles para restringir a execução de pods com apenas recursos explicitamente concedidos. Por exemplo, o Policy Controller está disponível para clusters em frotas. O Kubernetes também tem o controlador de admissão do PodSecurity integrado, que permite aplicar os padrões de segurança do pod em clusters individuais.
O Controlador de Políticas é um recurso do GKE Enterprise que permite aplicar e validar a segurança de clusters do GKE em escala usando políticas declarativas. Para saber como usar o Policy Controller para aplicar controles declarativos no cluster do GKE, consulte Instalar o Policy Controller.
O controlador de admissão do PodSecurity permite aplicar políticas predefinidas em namespaces específicos ou em todo o cluster. Essas políticas correspondem aos diferentes padrões de segurança de pods.
Restringir a capacidade de automodificação das cargas de trabalho
Certas cargas de trabalho do Kubernetes, principalmente as cargas de trabalho do sistema, têm permissão para se automodificar. Por exemplo, algumas cargas de trabalho escalonam automaticamente na vertical. Embora seja conveniente, isso pode permitir que um invasor que já tenha comprometido um nó escalone ainda mais no cluster. Por exemplo, um invasor pode fazer com que uma carga de trabalho do nó se automodifique para ser executada como uma conta de serviço com mais privilégios que existe no mesmo namespace.
O ideal é que as cargas de trabalho não recebam permissão para se automodificar. Quando a automodificação for necessária, limite as permissões aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca de código aberto do Gatekeeper, que fornece várias medidas de segurança úteis.
Ao implantar políticas, geralmente é necessário permitir que os controladores que
gerenciam o ciclo de vida do cluster ignorem as políticas. Isso é necessário para que
os controladores possam fazer alterações no cluster, como a aplicação de upgrades
de cluster. Por exemplo, se você implantar a política NoUpdateServiceAccount no
GKE, será necessário definir os seguintes parâmetros em Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:addon-manager
Restringir o uso do tipo de volume gcePersistentDisk descontinuado
O tipo de volume gcePersistentDisk, descontinuado, permite montar um disco permanente
do Compute Engine em pods. Recomendamos que você restrinja o uso do
tipo de volume gcePersistentDisk nas cargas de trabalho. O GKE não
realiza verificações de autorização do IAM no pod ao ativar
esse tipo de volume, embora o Google Cloud realize verificações de autorização ao
anexar o disco à VM subjacente. Um invasor que já consegue criar pods em um namespace pode acessar o conteúdo dos discos permanentes do Compute Engine no seu projeto do Google Cloud.
Para acessar e usar os discos permanentes do Compute Engine, use
PersistentVolumes e
PersistentVolumeClaims. Aplique políticas de segurança no cluster que
evitem o uso do tipo de volume gcePersistentDisk.
Para evitar o uso dogcePersistentDisk volume, aplique a política de referência ou
restrita com a
Controlador de admissão do PodSecurity ,
ou defina uma restrição personalizada em
Controlador de políticas
ou no controlador de admissão Gatekeeper.
Para definir uma restrição personalizada para restringir esse tipo de volume, faça o seguinte:
Instale um controlador de admissão com base em políticas, como o Policy Controller ou o Gatekeeper OPA.
Policy Controller
Instale o Policy Controller no seu cluster.
Observação: o Policy Controller é um recurso pago para usuários do GKE. O Controlador de Políticas é baseado no Gatekeeper de código aberto, mas você também tem acesso à biblioteca completa de modelos de restrição, pacotes de políticas e integração com os painéis do console do Google Cloud para ajudar a observar e fazer a manutenção dos clusters. Os pacotes de políticas são práticas recomendadas opinativas que podem ser aplicadas aos clusters, incluindo pacotes com base em recomendações como o Comparativo de mercado CIS do Kubernetes.
Gatekeeper
Instale o Gatekeeper no cluster.
Para clusters do Autopilot, abra o manifesto
gatekeeper.yamldo Gatekeeper em um editor de texto. Modifique o camporulesna especificaçãoMutatingWebhookConfigurationpara substituir caracteres curinga (*) por nomes de recursos e grupos de API específicos, como no exemplo a seguir:apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration ... webhooks: - admissionReviewVersions: - v1 - v1beta1 ... rules: - apiGroups: - core - batch - apps apiVersions: - '*' operations: - CREATE - UPDATE resources: - Pod - Deployment - Job - Volume - Container - StatefulSet - StorageClass - Secret - ConfigMap sideEffects: None timeoutSeconds: 1Aplique o manifesto
gatekeeper.yamlatualizado ao cluster do Autopilot para instalar o Gatekeeper. Isso é necessário porque, como medida de segurança integrada, o Autopilot não permite caracteres curinga na mutação de webhooks de admissão.Implante o ConstraintTemplate integrado aos tipos de volume da política de segurança de pods:
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yamlSalve a seguinte restrição com uma lista de tipos de volumes permitidos como
constraint.yaml:apiVersion: constraints.gatekeeper.sh/v1beta1 kind: k8sPSPVolumeTypes metadata: name: nogcepersistentdisk spec: match: kinds: - apiGroups: [""] kinds: ["Pods"] parameters: volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]Essa restrição restringe os volumes à lista no campo
spec.parameters.volumes.Implante a restrição:
kubectl apply -f constraint.yaml
Monitorar a configuração do cluster
Audite as configurações do seu cluster para desvios das configurações definidas.
Muitas das recomendações abordadas neste guia de proteção, bem como outras configurações incorretas comuns, podem ser verificadas automaticamente usando Security Health Analytics.
Padrões seguros
As seções a seguir descrevem opções que são configuradas com segurança por padrão em novos clusters. Verifique se os clusters preexistentes estão configurados com segurança.
Proteger metadados do nó
Recomendações de referência do CIS para GKE: 6.4.1. Verificar se as APIs de metadados da instância legada do Compute Engine estão desativadas e 6.4.2. Verificar se o servidor de metadados do GKE está ativado
O uso dos endpoints v0.1 e v1beta1 do servidor de metadados do Compute Engine foi suspenso
e encerrado em 30 de setembro de 2020. Esses endpoints não impõem cabeçalhos de consulta de metadados.
Para a programação de desativação, consulte Suspensão de uso dos endpoints dos servidores de metadados v0.1 e v1beta1.
Alguns ataques práticos contra o Kubernetes dependem do acesso ao servidor de metadados da VM para extrair credenciais. Esses ataques serão bloqueados se você estiver usando a federação de identidade da carga de trabalho para o GKE ou a ocultação de metadados.
Deixar os métodos de autenticação do cliente legado desativados
Recomendações de referência do CIS para GKE: 6.8.1. Verificar se a autenticação básica com senhas estáticas está desativada e 6.8.2. Verificar se a autenticação com certificados do cliente está desativada
Há vários métodos de autenticação
no servidor da API Kubernetes. No GKE, os métodos compatíveis
são tokens do portador da conta de serviço, tokens OAuth e certificados do cliente x509.
O GKE gerencia a autenticação com gcloud para você por meio do
método de token OAuth, da configuração do Kubernetes, de um token
de acesso e mantendo-o atualizado.
Antes da integração do GKE com o OAuth, um certificado x509 exclusivamente gerado ou uma senha estática eram os únicos métodos de autenticação disponíveis, mas agora não são recomendados e devem ser desativados. Esses métodos apresentam uma superfície mais ampla de ataque para comprometimento de cluster e foram desativados por padrão desde a versão 1.12 do GKE. Se você estiver usando métodos de autenticação legados, recomendamos desativá-los. A autenticação com uma senha estática está obsoleta e foi removida desde a versão 1.19 do GKE.
Os clusters atuais precisam ser movidos para o OAuth. Se uma credencial de longa duração for necessária por um sistema externo ao cluster, recomendamos que você crie uma conta de serviço do Google ou uma conta de serviço do Kubernetes com os privilégios necessários e exporte a chave.
Para atualizar um cluster atual e remover a senha estática, consulte Como desativar a autenticação com uma senha estática.
Atualmente, não é possível remover o certificado de cliente emitido de um cluster atual, mas ele não tem permissões se o RBAC estiver ativado e o ABAC estiver desativado.
Deixar o Cloud Logging ativado
Recomendação de referência do CIS para GKE: 6.7.1. Verificar se o Stackdriver Kubernetes Logging e Monitoring estão ativados
Para reduzir a sobrecarga operacional e manter uma visualização consolidada dos registros, implemente uma estratégia de registro que seja consistente sempre que seus clusters forem implantados. Os clusters do GKE Enterprise são integrados ao Cloud Logging por padrão e precisam permanecer configurados.
Todos os clusters do GKE têm registros de auditoria do Kubernetes ativados por padrão, o que mantém um registro cronológico das chamadas feitas ao servidor da API do Kubernetes. As entradas de registro de auditoria do Kubernetes são úteis para investigar solicitações de API suspeitas, coletar estatísticas ou criar alertas de monitoramento para chamadas de API indesejadas.
Os clusters do GKE integram o Kubernetes Audit Logging com os registros de auditoria do Cloud e com o Cloud Logging. Os registros podem ser roteados do Cloud Logging para seus próprios sistemas de registro.
Deixar a IU da Web do Kubernetes (painel) desativada
Recomendação de referência do CIS para GKE: 6.10.1. Verificar se a IU da Web do Kubernetes está desativada
Não ative a IU da Web do Kubernetes (painel) ao executar no GKE.
A IU da Web do Kubernetes (painel) é apoiada por uma conta de serviço do Kubernetes altamente privilegiada. O Console do Google Cloud fornece grande parte da mesma funcionalidade. Portanto, você não precisa dessas permissões.
Para desativar a interface do usuário da Web do Kubernetes:
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED
Sair do ABAC desativado
Recomendação de referência do CIS para GKE: 6.8.4. Verificar se a autorização legada (ABAC) está desativada
Desative o controle de acesso baseado em atributos (ABAC) e, em vez disso, use o controle de acesso baseado em papéis (RBAC) no GKE.
Por padrão, o ABAC está desativado para clusters criados com o GKE versão 1.8 e posterior. No Kubernetes, o RBAC é usado para conceder permissões a recursos no nível do cluster e do namespace. O RBAC permite definir funções com regras que contêm um conjunto de permissões. O RBAC tem vantagens significativas de segurança em relação ao ABAC.
Se você ainda depende do ABAC, primeiro examine os pré-requisitos para usar o RBAC. Se você atualizou seu cluster de uma versão mais antiga e está usando o ABAC, atualize sua configuração de controles de acesso:
gcloud container clusters update CLUSTER_NAME \
--no-enable-legacy-authorization
Para criar um novo cluster com a recomendação acima:
gcloud container clusters create CLUSTER_NAME \
--no-enable-legacy-authorization
Deixe o controlador de admissão DenyServiceExternalIPs ativado
Não desative o controlador de admissão DenyServiceExternalIPs.
O controlador de admissão
DenyServiceExternalIPs
impede que os Serviços usem ExternalIPs e mitiga uma
vulnerabilidade de segurança conhecida.
O controlador de admissão DenyServiceExternalIPs é ativado por padrão em novos
clusters criados nas versões 1.21 e mais recentes do GKE. Para clusters
que fazem upgrade para as versões 1.21 e posteriores do GKE, ative o
controlador de admissão usando este comando:
gcloud beta container clusters update CLUSTER_NAME \
--no-enable-service-externalips
A seguir
- Saiba mais sobre segurança no GKE na Visão geral da segurança.
- Entenda o modelo de responsabilidade compartilhada do GKE.
- Entenda como aplicar a Referência do CIS para GKE ao cluster.
- Saiba mais sobre o controle de acesso no GKE.
- Leia a visão geral de redes no GKE.
- Leia a visão geral de multilocação do GKE.