Versão 1.5. Esta versão é totalmente compatível, oferecendo os patches e as atualizações mais recentes para vulnerabilidades de segurança, exposições e problemas que afetam o GKE On-Prem. Consulte as notas da versão para saber mais detalhes. Esta não é a versão mais recente.

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 orientações atuais para proteger seus clusters do Anthos em clusters do VMware (GKE no local).

Este guia prioriza as mitigações de segurança de alto valor que exigem ação no momento da criação do cluster. Recursos menos importantes, configurações seguras por padrão e aqueles que podem ser ativados após a criação do cluster são mencionados mais abaixo. Para uma visão geral dos tópicos de segurança, consulte Segurança.

Como criptografar VMs do vSphere

Os clusters do Anthos em nós do cluster do VMware são executados em máquinas virtuais (VMs) no cluster do vSphere. Siga as orientações da prática de segurança do VMware vSphere e as práticas recomendadas para criptografar VMs.

Fazer upgrade da infraestrutura em tempo hábil

O Kubernetes apresenta frequentemente novos recursos de segurança e fornece patches de segurança. Para informações sobre patches de segurança, consulte Clusters do Anthos em boletins de segurança da VMware.

Você é responsável por manter seus clusters do Anthos nos clusters no VMware atualizados. Para cada versão, consulte as notas de lançamento para atualizar para novas versões de patch a cada mês e versões secundárias a cada três meses. Saiba como fazer upgrade dos clusters.

Você também é responsável por fazer upgrade e proteger a infraestrutura do vSphere:

Configurar o OpenID Connect

Se você quiser configurar a autenticação de usuários dos clusters, use o OpenID Connect (OIDC).

Você também precisa usar os grupos OIDC ao conceder acesso pelo controle de acesso baseado em papéis (RBAC, na sigla em inglês). Isso elimina a necessidade de atualizar manualmente a configuração do RBAC à medida que os usuários alteram os papéis.

Usar o princípio do menor privilégio para contas de serviço do Google Cloud

Os clusters do Anthos no VMware exigem quatro contas de serviço do Google Cloud:

  • Uma conta de serviço permitida para acessar os clusters do Anthos no software VMware. Você a cria ao comprar o Anthos.
  • Uma conta de serviço de registro a ser usada pelo Connect para registrar clusters Anthos nos clusters do VMware com o Google Cloud.
  • Uma conta de serviço de conexão a ser usada pelo Connect para estabelecer uma conexão entre os clusters do Anthos nos clusters no VMware e o Google Cloud.
  • Uma conta de serviço do Cloud Logging para coletar registros do cluster para uso no Cloud Logging.

Durante a instalação, você vincula os papéis de gerenciamento de identidade e acesso a essas contas de serviço. Esses papéis concedem privilégios específicos às contas de serviço no projeto. É preciso configurar essas contas de serviço usando o princípio do menor privilégio (em inglês): conceda somente os privilégios necessários para atender aos respectivos papéis da conta de serviço.

Usar namespaces do Kubernetes e RBAC para restringir o acesso

Para conceder às equipes acesso de privilégio mínimo ao Kubernetes, crie namespaces (em inglês) ou clusters específicos do ambiente do Kubernetes. Atribua centros de custo e rótulos apropriados a cada namespace para responsabilidade e estorno. Forneça aos desenvolvedores apenas o nível de acesso aos namespaces necessários para implantar e gerenciar os aplicativos, especialmente na produção.

Mapeie as tarefas que os usuários precisam realizar no cluster e defina as permissões necessárias para concluir cada tarefa. Para conceder permissões no nível do cluster e do namespace, use o RBAC do Kubernetes.

Além das permissões para contas de serviço do Google Cloud usadas para instalar clusters do Anthos no VMware, o IAM não se aplica a clusters do Anthos em clusters do VMware.

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 (CRDs). Essas permissões são reduzidas no Kubernetes 1.14, que estará disponível a partir de clusters do Anthos na versão 1.2 do VMware. Se for necessário restringir o acesso, configure o firewall local adequadamente.

Gerenciamento de secrets

Para fornecer uma camada extra de proteção para dados confidenciais, como os secrets do Kubernetes armazenados no etcd, configure um gerenciador de secrets integrado aos clusters do Anthos nos clusters do VMware.

Se você estiver executando cargas de trabalho em vários ambientes, talvez prefira uma solução que funcione para clusters do Google Kubernetes Engine e do Anthos no VMware. Se você optar por usar um gerenciador de secrets externo, como o HashiCorp Vault, precisará configurá-lo antes de criar seus clusters do Anthos nos clusters do VMware.

Há várias opções de gerenciamento de secrets.

  • É possível usar os secrets do Kubernetes nativamente nos clusters do Anthos no VMware. Esperamos que os clusters usem a criptografia vSphere para as VMs, conforme descrito anteriormente, que fornece proteção básica de criptografia em repouso para secrets. Os secrets não recebem mais criptografia do que isso por padrão. Para criptografar esses secrets na camada do aplicativo, é possível editar EncryptionConfig (em inglês) e usar um plug-in de serviço de gerenciamento de chaves.
  • É possível usar um gerenciador de secrets externo, como o HashiCorp Vault. Para autenticar no HashiCorp, use uma conta de serviço do Kubernetes ou do Google Cloud.

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 opções não podem ser alteradas após a criação do cluster.

Por padrão, os clusters do Anthos em nós do cluster VMware são criados usando endereços RFC 1918. Não altere isso. Implemente regras de firewall na rede local para restringir o acesso ao plano de controle.

Usar políticas de rede para restringir o tráfego entre pods

Por padrão, todos os serviços em clusters do Anthos no cluster do VMware podem se comunicar entre si. É necessário controlar a comunicação entre serviços conforme necessário para as 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. Para controlar o tráfego L7 aos endpoints dos aplicativos, use o Istio. Escolha essa opção se você tiver interesse em balanceamento de carga, autorização de serviço, limitação, cotas e métricas.
  2. Para controlar o tráfego L4 entre pods, use as políticas de rede (em inglês) do Kubernetes. Escolha essa opção se estiver procurando a funcionalidade básica de controle de acesso exposta pelo Kubernetes.

É possível ativar a política de rede do Istio e do Kubernetes depois de criar seus clusters do Anthos nos clusters do VMware. Use-os juntos, se necessário.

Usar o controlador de políticas do Anthos Config Management

Os controladores de admissão (em inglês) do Kubernetes são plug-ins que controlam e aplicam a maneira como um cluster do Kubernetes é usado. Ative os controladores de admissão para usar os recursos avançados de segurança do Kubernetes. Os controladores de admissão são uma parte importante da abordagem de defesa em profundidade para aumentar a proteção do cluster.

A prática recomendada é usar o controlador de políticas do Anthos Config Management. O controlador de políticas usa o framework de restrições de OPA (em inglês) para descrever e aplicar a política como CRDs. As restrições que você quer aplicar ao cluster são definidas em modelos de restrição, que são implantados nos clusters.

Monitorar a configuração do cluster

Audite as configurações do seu cluster para desvios das configurações definidas. Para verificar essas configurações automaticamente, use uma solução que funcione com os clusters do Anthos nos clusters VMware, independentemente de onde sejam implantados. Consulte Parceiros do Anthos.

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

Há vários métodos de autenticação no servidor da API Kubernetes (em inglês). O OIDC é o mecanismo de autenticação recomendado. A autenticação básica (em inglês) está desativada por padrão. Não use o certificado x509 para autenticação.

Deixar o Cloud Logging 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. Por padrão, os clusters do Anthos no VMware são integrados ao pacote de operações do Google Cloud. É preciso ativar o pacote de operações do Google Cloud durante a instalação preenchendo a especificação stackdriver nos clusters do Anthos no arquivo de configuração da VMware.

Todos os clusters do Anthos em clusters da VMware têm a geração de registros de auditoria do Kubernetes ativada por padrão. A geração de registros de auditoria mantém um registro cronológico das chamadas que foram feitas para o servidor da API Kubernetes. As entradas de registros de auditoria são úteis para investigar solicitações de API suspeitas, coletar estatísticas e criar alertas de monitoramento para chamadas de API indesejadas.

Os clusters do Anthos em clusters do VMware integram os registros de auditoria do Kubernetes com registros de auditoria do Google Cloud e Cloud Logging. Os clusters do Anthos no VMware também podem exportar a partir do pacote de operações do Google Cloud para seu próprio sistema de geração de registros.

O pacote de operações do Google Cloud coleta e agrega registros dos clusters. Ao ativar o pacote de operações do Google Cloud, o suporte que você recebe do Google é aprimorado. Para mais informações, consulte Geração de registros e monitoramento.

Deixar o painel do Kubernetes desativado (padrão)

O Painel do Kubernetes é respaldado por uma conta de serviço do Kubernetes altamente privilegiada e passou por vários ataques de teste de alto perfil no Kubernetes. O Console do Google Cloud é a interface da Web recomendada para clusters Anthos no VMware. Ele tem grande parte da mesma funcionalidade, é compatível com o IAM e o Kubernetes RBAC sem privilégios elevados e fornece funcionalidades do Anthos, como o gerenciamento de vários clusters.

O painel do Kubernetes não está incluído nos clusters do Anthos no VMware.

Deixar o controle de acesso baseado em atributos desativado (padrão)

No Kubernetes, você usa o RBAC para conceder permissões a recursos no nível do cluster e do namespace. O RBAC permite definir papéis com regras que contêm um conjunto de permissões.

Por padrão, o controle de acesso baseado em atributos (ABAC, na sigla em inglês) é desativado em clusters do Anthos em clusters do VMware, e você não precisa ativá-lo.

A seguir