Com a velocidade do desenvolvimento no Kubernetes, muitas vezes há novos recursos de segurança para você usar. Nesta página, você verá como implementar nossa orientação atual para o aumento da proteção dos seus clusters do GKE On-Prem.
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 nós do cluster do GKE On-Prem 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 Boletins de segurança do GKE On-Prem.
Você é responsável por manter seus clusters do GKE On-Prem atualizados. Para cada versão, consulte as Notas de lançamento. Planeje as atualizações 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:
- Estabeleça um processo para realizar correções e upgrades em tempo hábil (em inglês) das máquinas virtuais.
- Confira os avisos em inglês de segurança da VMware mais recentes.
- Siga as orientações em inglês sobre como aplicar patches nos hosts.
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
O GKE On-Prem precisa de quatro contas de serviço do Google Cloud:
- Uma conta de serviço com permissão para acessar o software GKE On-Prem Você a cria ao comprar o Anthos.
- Uma conta de serviço de registro que será usada pelo Connect para registrar clusters no GKE On-Prem com o Google Cloud.
- Uma conta de serviço de conexão que será usada pelo Connect para estabelecer uma conexão entre os clusters do GKE On-Prem 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 o GKE On-Prem, o IAM não se aplica a clusters do GKE On-Prem.
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 da versão 1.2 do GKE On-Prem. Se for necessário restringir o acesso, configure o firewall no local adequadamente.
Gerenciamento de secrets
Para fornecer uma camada extra de proteção a dados confidenciais, como os Secrets do Kubernetes armazenados no etcd, configure um gerenciador de secrets integrado aos clusters do GKE On-Prem.
Se você estiver executando cargas de trabalho em vários ambientes, talvez prefira uma solução que funcione para o Google Kubernetes Engine e o GKE On-Prem. Se você optar por usar um gerenciador de secrets externo, como o HashiCorp Vault, precisará configurá-lo antes de criar os clusters do GKE On-Prem.
Há várias opções de gerenciamento de secrets.
- É possível usar os Secrets do Kubernetes nativamente no GKE On-Prem. 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 nós de cluster no GKE On-Prem são criados usando endereços RFC 1918. Não altere isso. Implemente regras de firewall na rede no 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 um cluster do GKE On-Prem podem se comunicar uns com os outros. É 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:
- 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.
- 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 os clusters do GKE On-Prem. É possível usá-los 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 automaticamente essas configurações, use uma solução que funcione com seus clusters do GKE On-Prem, independentemente de onde eles estejam 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. O GKE On-Prem é integrado ao pacote de operações do Google Cloud por
padrão. Ative o pacote de operações do Google Cloud durante a instalação
preenchendo a especificação stackdriver no arquivo de configuração
do GKE On-Prem.
Todos os clusters do GKE On-Prem 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 GKE On-Prem integram a geração de registros de auditoria do Kubernetes aos registros de auditoria do Google Cloud e ao Cloud Logging. O GKE On-Prem também pode rotear o Logging 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 o GKE On-Prem. 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 no GKE On-Prem.
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) está desativado nos clusters do GKE On-Prem. Não o ative.