Como aumentar a segurança do seu cluster

Com a velocidade do desenvolvimento no Kubernetes, muitas vezes há novos recursos de segurança para você usar. Esta página orienta você na implementação da nossa orientação atual para fortalecer seu cluster do Google Kubernetes Engine. 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.

Desativar a interface do usuário da Web do Kubernetes (painel)

Desative a interface do usuário da Web do Kubernetes (painel) ao executá-la no GKE.

A IU da web do Kubernetes (painel) é apoiada por uma conta de serviço do Kubernetes altamente privilegiada. O Console do 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

Desativar ABAC

Desative o controle de acesso baseado em atributos (ABAC, na sigla em inglês) e, em vez disso, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês) no GKE.

No Kubernetes, o RBAC é usado para conceder permissões a recursos no nível de cluster e 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 e agora está estável no Kubernetes, então é hora de desativar o 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

Restringir o tráfego entre pods com uma política de rede

Por padrão, todos os pods em um cluster podem se comunicar uns com os outros. Controle a comunicação entre pods conforme necessário para sua carga de trabalho.

Você pode usar as políticas de rede do Kubernetes para tornar muito mais difícil para os invasores moverem-se lateralmente dentro do cluster. Você também pode usar a API Kubernetes Network Policy para criar regras de firewall no nível do pod. Essas regras de firewall determinam quais pods e serviços podem acessar um ao outro dentro do cluster.

Para ativar a imposição da política de rede ao criar um novo cluster, especifique a sinalização --enable-network-policy:

gcloud container clusters create [CLUSTER_NAME] \
    --zone=[COMPUTE_ZONE] \
    --enable-network-policy

Depois de ativar a política de rede, você precisa definir uma política. Como é específico para a topologia exata, não podemos fornecer uma recomendação específica. A documentação do Kubernetes, no entanto, tem um excelente passo a passo para uma implantação simples do nginx.

Para saber mais sobre as políticas de rede no GKE, consulte Como definir uma política de rede de cluster.

Como usar NetworkPolicy e PodSecurityPolicy juntas

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 à 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.

Usar as contas de serviço com privilégios mínimos para seus nós

Cada nó do GKE tem uma conta de serviço do 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 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 executar seu cluster GKE em vez de usar a conta de serviço padrão do Compute Engine.

O GKE exige, no mínimo, que a conta de serviço tenha as funções monitoring.viewer, monitoring.metricWriter e logging.logWriter. 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:

gcloud iam service-accounts create [SA_NAME] \
    --display-name=[SA_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

Se você usa imagens particulares no Google Container Registry, também precisa conceder acesso a elas:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
  --role roles/storage.objectViewer

Se você quiser que outro usuário possa criar novos clusters ou pools de nós com essa conta de serviço, atribua a eles o papel de Usuário da conta de serviço:

gcloud iam service-accounts add-iam-policy-binding \
  [SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com \
  --member=user:[USER] \
  --role=roles/iam.serviceAccountUser

Se o cluster já existir, crie um novo pool de nós com essa nova conta de serviço:

gcloud container node-pools create [NODE_POOL] \
  --service-account=[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com \
  --cluster=[CLUSTER_NAME]

Se você precisar que seu cluster do GKE tenha acesso a outros serviços do Google Cloud, crie uma conta de serviço adicional e conceda às suas cargas de trabalho acesso à conta de serviço, armazenando a respectiva chave privada em um segredo do Kubernetes. Para saber mais, consulte Como se autenticar no Google Cloud Platform com contas de serviço.

Reduzir os escopos da conta de serviço do nó

Se você não quiser usar uma conta de serviço personalizada, uma recomendação alternativa é reduzir as permissões da conta de serviço do nó padrão.

Por padrão, sua conta de serviço do nó tem escopos de acesso. Escopos de acesso são o método legado de especificação das permissões da sua instância. Quando não havia papéis do IAM, os escopos de acesso eram a única forma de conceder permissões a contas de serviço.

Se você não estiver criando uma conta de serviço separada para seus nós, limite os escopos da conta de serviço do nó para reduzir a possibilidade de um escalonamento de privilégios em um ataque. Isso garante que sua conta de serviço padrão não tenha permissões além das necessárias para executar seu cluster. Embora os escopos padrão sejam limitados, eles podem incluir escopos além dos minimamente necessários para executar seu cluster.

Os escopos padrão para os nós no GKE são devstorage.read_only, logging.write, monitoring, service.management.readonly, servicecontrol e trace.append. Ao definir escopos, eles são especificados como gke-default. Se você estiver acessando imagens particulares no Google Container Registry, os escopos minimamente necessários são apenas logging.write, monitoring e devstorage.read_only.

Para criar um cluster com os escopos personalizados, use a opção --scopes:

gcloud container clusters create [CLUSTER_NAME] \
    --scopes=[CUSTOM_SCOPES]

Se você não especificar escopos ou uma conta de serviço personalizada, o gke-default será usado. Se especificar uma conta de serviço personalizada, o cloud-platform e o userinfo.email serão usados.

Se sua configuração do gcloud inclui container/new_scopes_behavior true, esse comportamento já está ativado para todas as versões do Kubernetes. Para definir o padrão para seu ambiente:

gcloud config set container/new_scopes_behavior true

Para saber mais sobre permissões para todos os escopos, consulte Escopos do Google.

Restringir métodos de autenticação do cliente

Há vários métodos de autenticação (em inglês) no servidor da API Kubernetes. No GKE, os métodos suportados são tokens OAuth, certificados de cliente x509 e senhas estáticas. Para gerenciar a autenticação via gcloud, o GKE usa o método de token OAuth, define a configuração do Kubernetes, recebe um token de acesso e o mantém atualizado.

Os outros métodos de autenticação (certificados x509 e senhas estáticas) apresentam uma superfície mais ampla de ataque para comprometimento do cluster. Com esses outros métodos, as credenciais são geradas para você ao criar um novo cluster. A menos que seu aplicativo esteja usando esses métodos de autenticação, desative-os. Use o OAuth para se realizar a autenticação no servidor da API Kubernetes. Assim, a kubectl é autenticada quando você executa gcloud container clusters get-credentials. Desative os métodos de autenticação do certificado de cliente e senha estática do cluster.

O certificado do cliente e a senha estática só podem ser recuperados por um usuário com a permissão container.clusters.getCredentials. Os papéis roles/container.admin, roles/owner e roles/editor têm essa permissão. Portanto, use-os com sabedoria. Leia mais sobre os papéis do IAM do GKE.

Desativar a autenticação com um certificado de cliente pré-provisionado

Com a autenticação de certificado, um cliente apresenta um certificado que o servidor de API verifica com a autoridade de certificação especificada. No GKE, os certificados de cliente são assinados pela autoridade de certificação raiz do cluster.

Com o ABAC, o certificado de cliente pré-provisionado é totalmente autorizado no servidor de API. Mas com o RBAC ativado, os certificados de cliente precisam receber permissões. Um cluster com RBAC ativado e ABAC desativado ainda tem esse certificado, mas é efetivamente inútil, a menos que receba permissões específicas usando RoleBindings do RBAC.

Para criar um cluster sem gerar um certificado de cliente, use a sinalização --no-issue-client-certificate:

gcloud container clusters create [CLUSTER_NAME] \
    --no-issue-client-certificate

Atualmente, não há como remover um certificado de cliente de um cluster existente.

Desativar autenticação com uma senha estática

Uma senha estática é uma combinação de nome de usuário e senha que o servidor da API valida. No GKE, eles são gerados por um nome de usuário "admin" por padrão.

Para criar um cluster sem gerar uma senha estática, use a opção --no-enable-basic-auth:

gcloud container clusters create [CLUSTER_NAME] \
    --no-enable-basic-auth

Para atualizar um cluster existente e remover a senha estática:

gcloud container clusters update [CLUSTER_NAME] \
    --no-enable-basic-auth

Proteger metadados do nó

Alguns ataques práticos contra o Kubernetes dependem do acesso ao servidor de metadados da VM para extrair as credenciais do nó.

O uso de uma conta de serviço com privilégios mínimos, conforme recomendado acima, é o primeiro passo para atenuar esses ataques. A próxima etapa é evitar que as cargas de trabalho representem os nós. Desative as APIs do servidor de metadados legado e use a ocultação de metadados para ajudar a proteger os metadados do sistema potencialmente confidenciais das cargas de trabalho em execução no cluster.

Para saber mais, consulte Como proteger metadados de cluster.

Faça upgrade automático dos seus nós

Manter a versão do Kubernetes atualizada é uma das coisas mais simples que você pode fazer para melhorar sua segurança. O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança.

No Google Kubernetes Engine, os mestres são corrigidos e atualizados para você, mas os nós continuam sendo sua responsabilidade. Ative o upgrade automático dos nós para receber automaticamente atualizações e patches de segurança para seus pools de nós.

Para saber mais, consulte Como fazer o upgrade automático dos nós.

Se você não quiser ativar o upgrade automático dos nós, certifique-se de consultar atentamente os boletins de segurança do Kubernetes Engine para ver informações sobre patches de segurança.

Restringir permissões de pod com uma política de segurança de pod (Beta)

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 oferece controles para que os pods sejam executados apenas com os recursos mínimos necessários. A política de segurança de pods permite que você defina padrões inteligentes para seus pods e imponha controles que você quer ativar em toda sua frota. As políticas que você define precisam ser específicas para as necessidades do seu aplicativo. A política de exemplo restricted-psp.yaml é um bom ponto de partida.

Para saber mais sobre a política de segurança de pods, consulte Como usar PodSecurityPolicies.

Se você estiver usando as políticas de segurança do pod e de rede no cluster, consulte Como usar políticas de segurança do pod e de rede em conjunto.

Restringir permissões de RBAC na detecção de 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 do system:discovery e do ClusterRoleBindings system:basic-user pode incluir qualquer pessoa com credenciais válidas do Google (usuários do Gmail, por exemplo) e não representa um nível significativo de segurança para clusters no GKE.

Os usuários que quiserem se aprofundar nas APIs de detecção do cluster precisam considerar seguir uma ou mais destas etapas:

  • Configurar redes autorizadas para restringir o acesso a intervalos de IP definidos.
  • Configurar um cluster particular para restringir o acesso a um VPC.
  • Organizar os assuntos do padrão system:discovery e ClusterRoleBindings de system:basic-user. Por exemplo, em vez do padrão Kubernetes de permitir acesso ao system:(un)authenticated, considere apenas permitir acesso ao grupo system:serviceaccounts, além de outros usuários e grupos conhecidos.

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine