Segurança

Nesta página, mostramos os recursos de segurança incluídos no GKE na AWS, incluindo cada camada da infraestrutura e como configurar recursos de segurança para atender às suas necessidades.

Visão geral

O GKE na AWS 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.

Responsabilidades compartilhadas

Ao usar o GKE na AWS, você concorda em assumir certas responsabilidades pelos clusters. Para mais informações, consulte Responsabilidades compartilhadas dos clusters do GKE.

Autenticação e autorização

A autenticação em um cluster de usuário do GKE na AWS é feita usando um dos seguintes métodos:

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 para definir quais operações e recursos você permite que usuários e contas de serviço acessem. Ele também possibilita controlar o acesso de qualquer identidade validada fornecida.

Para simplificar e agilizar ainda mais sua estratégia de autenticação e autorização do Kubernetes Engine, o GKE na AWS desativa o Controle de acesso baseado em atributos (ABAC, na sigla em inglês) legado.

Criptografia

Por padrão, o GKE na AWS criptografa dados em etcd em repouso, volumes EBS, secrets do Kubernetes e componentes do plano de controle com o serviço de gerenciamento de chaves da AWS (KMS).

Para criptografar dados confidenciais nos clusters de usuários, use uma das seguintes opções:

Secrets do Kubernetes

Os recursos secrets do Kubernetes armazenam dados confidenciais, como senhas, tokens OAuth e chaves SSH, nos clusters. 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

O GKE na AWS pode usar o Hashicorp Vault (link em inglês) para proteger secrets nos clusters de usuários. Para mais informações, consulte Como usar o HashiCorp Vault no GKE na AWS.

Segurança do plano de controle

Os componentes do plano de controle incluem o serviço de gerenciamento e o servidor da API Kubernetes, o programador, os controladores e o banco de dados etcd do cluster de usuário. No GKE na AWS, os administradores locais gerenciam os componentes do plano de controle.

No GKE na AWS, os componentes do plano de controle são executados na AWS. É possível proteger o servidor de API do GKE na AWS usando grupos de segurança da AWS e ACLs de rede.

Toda a comunicação no GKE na AWS é feita por meio de canais do Transport Layer Security (TLS), que são regidos pelas seguintes autoridades de certificação (CAs, na sigla em inglês):

  • A CA 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 do cluster de usuário protege a comunicação entre o servidor de API e todos os clientes internos da API Kubernetes (kubelets, controladores, programadores). Essa CA é criptografada pelo KMS.
  • A CA do serviço de gerenciamento é criptografada pela AMS KMS. Ele é criado quando você executa anthos-gke init e armazenado no espaço de trabalho do Terraform. Quando você usa terraform apply para criar o serviço de gerenciamento, a chave da CA é transmitida como dados do usuário da AWS EC2 e descriptografada pelo KMS da AWS quando o cluster é iniciado.

Para o serviço de gerenciamento, as chaves do plano de controle são armazenadas no [nodes]{:.external} do plano de controle. Para clusters de usuário, as chaves são armazenadas como secrets do Kubernetes no plano de controle do serviço de gerenciamento.

A autenticação de cluster no GKE na AWS é processada por certificados e tokens de portador da conta de serviço. Como administrador, você faz a autenticação no plano de controle usando o certificado administrativo para o serviço de gerenciamento (que você usa para criar a vinculação de papel inicial ou para fins de emergência).

A rotação de certificados é processada das maneiras a seguir:

Segurança de nós

O GKE na AWS implanta as cargas de trabalho em pools de nós das instâncias do AWS EC2. As seções a seguir explicam como usar os recursos de segurança no nível do nó no GKE na AWS.

Ubuntu

O GKE na AWS usa uma versão otimizada do Ubuntu como o sistema operacional no qual o plano de controle e os nós do Kubernetes são executados. O Ubuntu inclui um conjunto avançado de recursos de segurança modernos, e o GKE na AWS implementa vários recursos de aprimoramento de segurança para clusters, incluindo:

  • Conjunto de pacotes otimizado.
  • Google Cloud-kernel do Linux personalizado.
  • Contas de usuário limitadas e login raiz desativado

Há guias de segurança extras disponíveis para o Ubuntu, como esta (links em inglês):

Upgrades de nós

Atualize seus nós regularmente. Às vezes, talvez seja preciso fazer upgrade dos nós com mais urgência por causa 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 upgrade do cluster de usuário, o software de cada nó é atualizado para as versões mais recentes. Além disso, a atualização de nós alterna as credenciais de criptografia.

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, você vai conhecer as táticas que podem ser usadas para limitar os efeitos colaterais da execução de contêineres no cluster e nos serviços Google Cloud .

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 do cluster. É possível definir opções relacionadas à segurança com o Contexto de segurança de pods e contêineres. Essas configurações permitem alterar as definições de segurança dos seus processos. Veja exemplos abaixo:

  • Usuário e grupo que executa o processo;
  • Recursos disponíveis do Linux;
  • escalonamento de privilégios.

O Ubuntu, sistema operacional padrão do nó do GKE na AWS, aplica as políticas de segurança padrão do AppArmor para Docker 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 diretamente nos arquivos em um diretório de código do processo (/proc/).
  • Gravar em arquivos que não estão em /proc/.
  • Gravar em arquivos em /proc/sys que não sejam /proc/sys/kernel/shm*.
  • Como montar sistemas de arquivos.

A seguir