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. 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 mitigações de segurança de alto valor que exigem açã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 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.

Fazer o upgrade da sua infraestrutura do GKE em tempo hábil (padrão 2019-11-11)

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 mestres recebem patches e upgrades 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

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 mestres e nós. Essa é uma boa opção se você configurou sua rede local para se conectar ao Google Cloud usando Cloud Interconnect e Cloud VPN. Essas tecnologias conectam efetivamente a rede da empresa à nuvem VPC.
  • Acesso ao endpoint público ativado, redes principais autorizadas ativadas (recomendado): esta opção dá ao plano de controle um endereço IP público, mas instala um firewall configurável pelo cliente na frente que permite restringir quais endereços IP podem se comunicar com o plano de controle. Essa é uma boa opção se você não tem uma infraestrutura de VPN ou se tem colaboradores externos ou filiais que se conectam pela Internet pública em vez da VPN corporativa e do Cloud Interconnect/Cloud VPN.
  • Acesso ao endpoint público ativado, redes principais autorizadas desativadas: esse é 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 tooloption gcloud --enable-private-nodes na criação do cluster.

Isso informa ao GKE para provisionar os nós com endereços IP particulares RFC 1918, 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 principais autorizadas e os nós particulares. Isso garante que o plano de controle possa ser alcançado pelos:

  • CIDRs permitidos em redes principais autorizadas;
  • nós na VPC do cluster;
  • jobs de produção internos do Google que gerenciam seu mestre.

Isso corresponde às seguintes sinalizações gcloud no momento da criação do cluster:

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Autenticação de grupo (Beta)

Esta configuração só pode ser ativada no momento da criação do cluster.

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 usando os Grupos do Google, ative Grupos do Google para o GKE ao criar seu 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.

Para ativar o Grupos do Google no GKE, crie um Grupo do Google, gke-security-groups, para gerenciar o acesso de usuários e especifique a sinalização gcloud --security-group no momento da criação do cluster.

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 nós do GKE protegidos (Beta)

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.

Para ativar os nós do GKE protegidos, especifique a opção gcloud --enable-shielded-nodes na criação ou atualização do cluster. Os 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 ativar a inicialização segura, especifique a sinalização gcloud --shielded-secure-boot na criação do cluster.

Escolher uma imagem de nó reforçada com o ambiente de execução containerd (Beta)

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 do Kubernetes (CRI, na sigla em inglês). 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, especifique a sinalização gcloud --image-type=cos_containerd na criação do cluster ou no momento da atualização.

A cos_containerd é a imagem preferencial do GKE, já que foi personalizada, otimizada e reforçada especificamente para executar contêineres.

Ativar a Identidade da carga de trabalho (Beta)

A identidade de carga de trabalho é a maneira recomendada de autenticação para as APIs do Google. Ela substitui as práticas anteriores de usar a conta de serviço do nó ou exportar chaves de conta de serviço para secrets, conforme descrito em Como autenticar no Google Cloud Platform com Contas de Serviço.

A identidade de carga de trabalho também dispensa o uso de ocultação de metadados, e as duas abordagens são incompatíveis. Os metadados confidenciais protegidos por ocultação de metadados também são protegidos pela identidade da carga de trabalho.

Permissões

Usar contas de serviço do Google com privilégios mínimos

Cada nó do GKE tem uma conta de serviço do Cloud Identity and Access Management (Cloud 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 navegando até a seção Cloud IAM do Console do Cloud (em inglês). 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.

Com o lançamento da identidade da carga de trabalho, 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 provisionadas como identidades do Google com a identidade da carga de trabalho.

O GKE exige, no mínimo, que a conta de serviço tenha os papéis 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 Cloud IAM com o mínimo de permissões necessárias para operar o GKE:

gcloud

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

Config Connector

Observação: esta etapa requer o Config Connector. Siga as instruções de instalação para instalar o Config Connector no cluster.

  1. Para criar a conta de serviço, faça o download do seguinte recurso como service-account.yaml. Substitua [SA_NAME] pelo nome que você quer usar para a conta de serviço.

    Ver no GitHub (em inglês)
    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    Depois, execute:
    kubectl apply -f service-account.yaml

  2. Aplique o papel logging.logWriter à conta de serviço. Faça o download do seguinte recurso como policy-logging.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    Ver no GitHub (em inglês)
    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Aplique o papel monitoring.metricWriter. Faça o download do seguinte recurso como policy-metrics-writer.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    Ver no GitHub (em inglês)
    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  4. Aplique o papel monitoring.viewer. Faça o download do seguinte recurso como policy-monitoring.yaml. Substitua [SA_NAME] e [PROJECT_ID] por suas próprias informações.

    Ver no GitHub (em inglês)
    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

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

gcloud

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

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

Ver no GitHub (em inglês)
apiVersion: iam.cnrm.cloud.google.com/v1alpha1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
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.serviceAccountUser

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

Ver no GitHub (em inglês)
apiVersion: iam.cnrm.cloud.google.com/v1alpha1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

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 acesso às cargas de trabalho usando a identidade da carga de trabalho.

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 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 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.
  • Selecione os assuntos dos clustersRoleBindings system:discovery e system:basic-user padrão. Por exemplo, em vez de permitir acesso a system:(un)authenticated padrão do Kubernetes, considere permitir somente o acesso ao grupo system:serviceaccounts mais outros Usuários e Grupos.

Usar namespaces e RBAC para restringir o acesso aos recursos do cluster

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.

O Cloud IAM e 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 Cloud IAM apropriados para o GKE para 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.

Para mais informações, consulte Como preparar um ambiente do Kubernetes Engine para produção.

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 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:

  1. Use o Istio (em inglês). Consulte Como instalar o Istio no GKE e escolha esta opção se você estiver interessado em balanceamento de carga, autorização de serviço, limitação, cota, métricas e muito mais.
  2. Use políticas de rede do Kubernetes (em inglês). Consulte Como configurar 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. A documentação do Kubernetes tem um excelente tutorial (em inglês) para uma implantação simples do nginx.

O Istio e a Política de rede podem ser usados em conjunto se isso for necessário.

Gerenciamento de secrets

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 funcionarão no GKE e no GKE On-Prem e, por isso, podem ser preferenciais se você estiver executando 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 oferece controles para restringir a execução de pods com apenas recursos explicitamente concedidos. A política de segurança (em inglês) 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 uma NetworkPolicy, e tiver um pod sujeito à PodSecurityPolicy, crie um papel RBAC ou ClusterRole (em inglês) 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.

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 os metadados do nó (padrão para 1.12+)

O servidor de metadados da instância do Compute Engine expõe endpoints /0.1/ e /v1beta1/ herdados, que não impõem cabeçalhos de consulta de metadados. Essas APIs foram desativadas por padrão para novos clusters 1.12+. Se você fez upgrade de clusters de versões mais antigas, precisará desativar essas APIs legadas manualmente.

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 identidade de carga de trabalho ou ocultação de metadados.

Os endpoints do servidor de metadados Compute Engine v1beta1 e v0.1 estão suspensos e programados para o encerramento. Certifique-se de atualizar todas as solicitações para usar o endpoint v1.

Para saber mais, consulte Como proteger metadados de cluster.

Deixar os métodos de autenticação do cliente legado desativados (padrão 1.12+)

Há vários métodos de autenticação (em inglês) no servidor da API Kubernetes.

No GKE, os métodos compatíveis são tokens de suporte de conta de serviço, tokens OAuth, certificados de cliente x509 e senhas estáticas. 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 Google OAuth, o certificado x509 pré-provisionado ou a senha estática eram os únicos métodos de autenticação disponíveis, mas agora não são recomendados e desativados por padrão em novos clusters desde 1.12+.

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:

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

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 registro do Stackdriver ativado (padrão)

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 Anthos são integrados ao Stackdriver 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 o Stackdriver Logging. Os registros podem ser exportados do Stackdriver para seus próprios sistemas de registro, se você quiser.

Deixar a IU da Web do Kubernetes (Painel de controle) desativada (padrão para 1.10+)

Não ative ativar a IU da Web do Kubernetes (Dashboard) 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 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 (padrão para 1.10+)

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

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine