Segurança

Esta página descreve as funcionalidades de segurança incluídas no GKE on AWS, incluindo cada camada da respetiva infraestrutura, e como pode configurar as funcionalidades de segurança de acordo com as suas necessidades.

Vista geral

O GKE on AWS oferece várias funcionalidades para ajudar a proteger as suas cargas de trabalho, incluindo o conteúdo da sua imagem de contentor, o tempo de execução do contentor, a rede do cluster e o acesso ao servidor da API do cluster.

É melhor adotar uma abordagem em camadas para proteger os seus clusters e cargas de trabalho. Pode aplicar o princípio do menor privilégio ao nível de acesso que concede aos seus utilizadores e cargas de trabalho. Pode ter de fazer concessões para permitir o nível certo de flexibilidade e segurança.

Responsabilidades partilhadas

Quando usa o GKE na AWS, aceita assumir determinadas responsabilidades pelos seus clusters. Para mais informações, consulte o artigo Responsabilidades partilhadas dos clusters do GKE.

Autenticação e autorização

Autentica-se num cluster de utilizadores do GKE on AWS através de um dos seguintes métodos:

Para configurar um acesso mais detalhado aos recursos do Kubernetes ao nível do cluster ou nos espaços de nomes do Kubernetes, usa o controlo de acesso baseado em funções (CABF) do Kubernetes. O RBAC permite-lhe criar políticas detalhadas para definir as operações e os recursos aos quais permite que os utilizadores e as contas de serviço acedam. Com o RBAC, pode controlar o acesso para qualquer identidade validada fornecida.

Para simplificar e otimizar ainda mais a sua estratégia de autenticação e autorização para o Kubernetes Engine, o GKE on AWS desativa o controlo de acesso baseado em atributos (ABAC) antigo.

Encriptação

Por predefinição, o GKE on AWS encripta dados etcdem repouso, volumes EBS, segredos do Kubernetes e componentes do plano de controlo com o AWS Key Management Service (KMS).

Para encriptar dados confidenciais nos seus clusters de utilizadores, pode usar uma das seguintes opções:

Segredos do Kubernetes

Os recursos Secrets do Kubernetes armazenam dados confidenciais, como palavras-passe, tokens OAuth e chaves SSH, nos seus clusters. O armazenamento de dados confidenciais em Secrets é mais seguro do que o armazenamento em texto simples ConfigMaps ou em especificações de Pod. A utilização de segredos dá-lhe controlo sobre a forma como os dados confidenciais são utilizados e reduz o risco de expor os dados a utilizadores não autorizados.

Hashicorp Vault

O GKE on AWS pode usar o Hashicorp Vault para proteger segredos nos seus clusters de utilizadores. Consulte o artigo Usar o HashiCorp Vault no GKE na AWS para mais informações.

Segurança do plano de controlo

Os componentes do plano de controlo incluem o serviço de gestão e o servidor da API Kubernetes, o programador, os controladores e a base de dados etcd do cluster de utilizadores. No GKE na AWS, os administradores locais gerem os componentes do plano de controlo.

No GKE na AWS, os componentes do plano de controlo são executados na AWS. Pode proteger o servidor da API do GKE no AWS através de grupos de segurança da AWS e ACLs de rede.

Todas as comunicações no GKE on AWS são através de canais Transport Layer Security (TLS) regidos pelas seguintes autoridades de certificação (ACs):

  • A AC etcd protege a comunicação do servidor da API para as réplicas etcd e também o tráfego entre as réplicas etcd. Esta AC é autoassinada.
  • A AC do cluster de utilizadores protege a comunicação entre o servidor da API e todos os clientes da API Kubernetes internos (kubelets, controladores e programadores). Esta CA está encriptada com o KMS.
  • A AC do serviço de gestão está encriptada com o AWS KMS. É criado quando executa o comando anthos-gke init e é armazenado no seu espaço de trabalho do Terraform. Quando usa o terraform apply para criar o serviço de gestão, a chave da AC é transmitida como dados do utilizador do AWS EC2 e desencriptada pelo AWS KMS quando o cluster é iniciado.

Para o serviço de gestão, as chaves do plano de controlo são armazenadas em [nós]{:.external} do plano de controlo. Para clusters de utilizadores, as chaves são armazenadas como segredos do Kubernetes no plano de controlo do serviço de gestão.

A autenticação de clusters no GKE on AWS é processada por certificados e tokens de portador de contas de serviço. Enquanto administrador, autentica-se no plano de controlo com o certificado administrativo no serviço de gestão (que usa para a criação inicial da associação de funções ou para fins de emergência).

A rotação de certificados é processada das seguintes formas:

Segurança do nó

O GKE na AWS implementa as suas cargas de trabalho em conjuntos de nós de instâncias do AWS EC2. As secções seguintes explicam como usar as funcionalidades de segurança ao nível do nó no GKE no AWS.

Ubuntu

O GKE na AWS usa uma versão otimizada do Ubuntu como o sistema operativo no qual executar o plano de controlo e os nós do Kubernetes. O Ubuntu inclui um conjunto abrangente de funcionalidades de segurança modernas e o GKE na AWS implementa várias funcionalidades de melhoria da segurança para clusters, incluindo:

  • Conjunto de pacotes otimizado.
  • Google Cloud-kernel do Linux personalizado.
  • Contas de utilizador limitadas e início de sessão de raiz desativado.

Estão disponíveis guias de segurança adicionais para o Ubuntu, como:

Atualizações de nós

Deve atualizar os seus nós regularmente. Periodicamente, os problemas de segurança no tempo de execução do contentor, no próprio Kubernetes ou no sistema operativo do nó podem exigir que atualize os nós com mais urgência. Quando atualiza o cluster de utilizadores, o software de cada nó é atualizado para as versões mais recentes. Além disso, a atualização dos nós faz a rotação das credenciais de encriptação.

Proteger as suas cargas de trabalho

O Kubernetes permite que os utilizadores aprovisionem, dimensionem e atualizem rapidamente cargas de trabalho baseadas em contentores. Esta secção descreve as táticas que pode usar para limitar os efeitos secundários da execução de contentores no cluster e nos Google Cloud serviços.

Limitar os privilégios do processo do contentor do pod

Limitar os privilégios dos processos contentorizados é importante para a segurança do seu cluster. Pode definir opções relacionadas com a segurança com o contexto de segurança de pods e contentores. Estas definições permitem-lhe alterar as definições de segurança dos seus processos, como:

  • Utilizador e grupo que executam o processo.
  • Capacidades do Linux disponíveis.
  • Escalamento de privilégios.

O sistema operativo do nó do GKE on AWS predefinido, o Ubuntu, aplica as políticas de segurança do Docker AppArmor predefinidas a todos os contentores iniciados pelo Kubernetes. Pode ver o modelo do perfil no GitHub. Entre outras coisas, o perfil nega as seguintes capacidades aos contentores:

  • Escrever diretamente nos ficheiros num diretório de ID do processo (/proc/).
  • Escrever em ficheiros que não estão em /proc/.
  • Escrever em ficheiros em /proc/sys que não sejam /proc/sys/kernel/shm*.
  • Montagem de sistemas de ficheiros.

O que se segue?