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.

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 interface do usuário da Web do Kubernetes Web (painel) é apoiada por uma conta de serviço 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 uma NetworkPolicy e tiver um pod sujeito a uma PodSecurityPolicy, crie um Role ou ClusterRole do RBAC que tenha permissão para usar a 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 você pode encontrar navegando até a 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 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 necessários minimamente serã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 no servidor da API Kubernetes. No GKE, os métodos compatíveis são tokens de conexão OpenID, certificados de cliente x509 e senhas estáticas. O GKE gerencia a autenticação via gcloud usando o método de token de conexão OpenID, definindo a configuração do Kubernetes, recebendo um token de acesso e mantendo-o 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. É preciso usar o método de autenticação OpenID e desativar os métodos de autenticação de certificado de cliente e senha estática do seu 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 autenticação com um certificado de cliente

Com a autenticação de certificado, um cliente apresenta um certificado que o servidor da 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, os certificados do cliente podem autenticar no servidor da API por padrão. Mas com o RBAC ativado, os certificados de cliente precisam receber permissões. Um cluster com o RBAC ativado e o ABAC desativado ainda tem esses certificados, mas os certificados são efetivamente inúteis.

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 rede e de segurança do pod no cluster, consulte este artigo.

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine