Nesta página, você conhecerá os recursos de segurança incluídos no GKE On-Prem, incluindo cada camada da infraestrutura e como configurar esses recursos de segurança para atender às suas necessidades.
Visão geral
O GKE On-Prem oferece vários recursos para ajudar a proteger suas cargas de trabalho, incluindo o conteúdo da imagem do contêiner, o ambiente de execução do contêiner, a rede do cluster e o acesso ao servidor da API do cluster.
É melhor adotar uma abordagem em camadas para proteger clusters e cargas de trabalho. É possível aplicar o princípio do menor privilégio (em inglês) ao nível de acesso fornecido aos usuários e cargas de trabalho. Talvez seja necessário fazer concessões para permitir o nível certo de flexibilidade e segurança.
Autenticação e autorização
Você faz a autenticação nos clusters do GKE On-Prem usando o OpenID Connect
(OIDC) (via kubectl) ou o token da conta de serviço do Kubernetes pelo do
Console do Cloud.
Para configurar um acesso mais granular aos recursos do Kubernetes no nível do cluster ou nos namespaces do Kubernetes, use o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes. O RBAC permite criar políticas detalhadas que definem quais operações e recursos você quer permitir que usuários e contas de serviço acessem. Com o RBAC, é possível controlar o acesso de qualquer identidade validada fornecida.
Para simplificar e agilizar ainda mais a estratégia de autenticação e autorização do Kubernetes Engine, o GKE On-Prem desativa o controle de acesso baseado em atributo legado (ABAC, na sigla em inglês).
Segurança do plano de controle
Os componentes do plano de controle incluem o programador, os controladores e o servidor da API Kubernetes, além do banco de dados etcd (em inglês) em que a configuração do Kubernetes é mantida. Já no Kubernetes Engine, os componentes do plano de controle do Kubernetes são gerenciados e mantidos pelo Google, os administradores locais gerenciam os componentes do plano de controle no GKE On-Prem.
No GKE On-Prem, os componentes do plano de controle são executados na rede corporativa. É possível proteger o servidor da API GKE On-Prem usando firewalls e políticas de rede corporativa atuais. Também é possível atribuir um endereço IP particular ao servidor da API e limitar o acesso ao endereço particular.
Toda a comunicação no GKE On-Prem ocorre por canais TLS, que são regidos por três autoridades de certificação (CAs, na sigla em inglês): etcd, cluster e org:
- A autoridade de certificação etcd protege a comunicação do servidor da API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Essa CA é autoassinada.
- A CA cluster protege a comunicação entre o servidor da API e todos os clientes internos da API Kubernetes (kubelets, controladores, programadores). Essa CA é autoassinada.
- A CA org é uma CA externa usada para exibir a API Kubernetes para usuários externos. Você gerencia essa CA.
Para planos de controle do administrador, as chaves são armazenadas no nó (em inglês) do plano de controle. Para clusters de usuários, as chaves são armazenadas como secrets do Kubernetes no plano de controle de administrador. O servidor da API é configurado com um certificado fornecido pelo usuário e assinado pela CA org. O servidor da API usa a indicação de nome do servidor (SNI, na sigla em inglês) para determinar qual chave assinada será usada, a da CA cluster ou a da CA org.
A autenticação de cluster no GKE On-Prem é processada por certificados e tokens do portador da conta de serviço. Como administrador, você se autentica no plano de controle usando o OIDC ou o certificado administrativo (usado para a criação da vinculação de papel inicial ou para fins de emergência).
A rotação de certificados é processada das maneiras a seguir:
- Para planos de controle, nós e o servidor de API, os certificados são criados ou alternados a cada upgrade.
- As CAs podem ser alternados raramente ou sob demanda.
Segurança de nós
O GKE On-Prem implanta as cargas de trabalho em instâncias de VMware, que são anexadas aos clusters como nós. Nas seções a seguir, mostramos como aproveitar os recursos de segurança no nível do nó disponíveis no GKE On-Prem.
Ubuntu
O GKE On-Prem usa uma versão otimizada do Ubuntu como o sistema operacional em que o plano de controle e os nós do Kubernetes serão executados. O Ubuntu inclui um conjunto rico de recursos de segurança modernos, e o GKE On-Prem implementa vários recursos de melhoria de segurança para clusters, incluindo:
- Conjunto de pacotes otimizado
- Kernel Linux personalizado para o Google Cloud
- Atualizações automáticas de segurança do SO opcionais
- Contas de usuário limitadas e login raiz desativado
Há guias de segurança extras disponíveis para o Ubuntu, como estae (links em inglês):
Upgrades de nós
Atualize seus nós regularmente. Às vezes, pode ser necessário fazer upgrade dos nós com mais urgência por conta de problemas de segurança no ambiente de execução do contêiner, no próprio Kubernetes ou no sistema operacional dos nós. Quando você faz o upgrade do cluster, cada software do nó é atualizado para as versões mais recentes.
Como proteger suas cargas de trabalho
O Kubernetes permite que os usuários provisionem, escalonem e atualizem rapidamente as cargas de trabalho baseadas em contêiner. Nesta seção, descrevemos as táticas que os administradores e usuários podem usar para limitar a capacidade dos contêineres em execução que afetam outros contêineres no cluster, os hosts em que eles são executados e os serviços do GCP ativados no projeto.
Como limitar os privilégios de processos em contêiner de pod
A limitação dos privilégios de processos em contêiner é importante para a segurança geral do cluster. O Kubernetes Engine permite que você defina opções relacionadas à segurança por meio do contexto de segurança em pods e contêineres. Com essas configurações, é possível alterar as configurações de segurança dos seus processos, como:
- usuário e grupo de execução;
- recursos disponíveis do Linux;
- escalonamento de privilégios.
Para alterar essas configurações no nível do cluster, e não no nível do pod ou do contêiner, crie um recurso PodSecurityPolicy. O PodSecurityPolicies garante que todos os pods em um cluster cumpram uma política de valor de referência mínima definida por você.
O sistema operacional padrão do nó do GKE On-Prem, Ubuntu, aplica as políticas de segurança Docker AppArmor padrão a todos os contêineres iniciados pelo Kubernetes. É possível ver o modelo do perfil no GitHub (em inglês). Entre outras coisas, o perfil nega os seguintes recursos aos contêineres:
- Gravar em arquivos diretamente em um diretório de ID do processo (/proc/)
- Gravar em arquivos que não estão em /proc/
- Gravar em arquivos em /proc/sys em vez de /proc/sys/kernel/shm*
- Montar sistemas de arquivos
Audit logging
Com a geração de registros de auditoria do Kubernetes os administradores podem reter, consultar, processar e alertar sobre eventos que ocorrem nos ambientes do GKE On-Prem. Os administradores podem usar as informações registradas para fazer análises forenses, emitir alertas em tempo real ou catalogar como e por quem uma frota de clusters do Kubernetes Engine está sendo usada.
Por padrão, o GKE On-Prem registra a atividade do administrador. Se quiser, você também pode registrar eventos de acesso a dados, dependendo dos tipos de operações que você quer inspecionar.
O agente do Connect se comunica apenas com o servidor da API local em execução no local, e cada cluster precisa ter o próprio conjunto de registros de auditoria. Todas as ações que os usuários realizam a partir da IU por meio do Connect são registradas por esse cluster.
Encryption
O Cloud Key Management Service (Cloud KMS) é um serviço de gerenciamento de chaves hospedado na nuvem que permite gerenciar chaves criptográficas para seus serviços. É possível gerar, usar, alternar e destruir chaves criptográficas AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 e EC P384. O Cloud KMS é integrado ao Cloud IAM e Cloud Audit Logging, o que permite gerenciar permissões para chaves individuais e monitorar como elas são usadas. Use o Cloud KMS para proteger secrets e outros dados confidenciais que você precisa armazenar.
Se os clusters e as cargas de trabalho do GKE On-Prem estiverem conectados com segurança aos serviços do Google Cloud pela VPN do Cloud, use o Cloud KMS para gerenciar as chaves. Se não, use uma das alternativas a seguir:
- Secrets do Kubernetes
- Hashicorp Vault
- Hardware Security Module (HSM)
Secrets do Kubernetes
Os recursos secrets do Kubernetes armazenam nos clusters dados confidenciais, como senhas, tokens OAuth e chaves SSH. Armazenar dados confidenciais em secrets é mais seguro do que armazená-los em ConfigMaps de texto simples ou nas especificações do pod. Com os secrets, você controla como os dados confidenciais são usados e reduz o risco de expô-los a usuários não autorizados.
HashiCorp Vault
- Hashicorp Vault (em inglês)
- Vault no GKE (em inglês)