Segurança

Esta página descreve os recursos de segurança incluídos no GKE na AWS, incluindo cada camada de sua infraestrutura, e como você pode configurar os 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 tempo 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 seus clusters e cargas de trabalho. Você pode aplicar o princípio do privilégio mínimo ao nível de acesso que fornece aos seus usuários e cargas de trabalho. Pode ser necessário fazer concessões para garantir o nível adequado de flexibilidade e segurança.

Responsabilidades compartilhadas

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

Autenticação e autorização

Você se autentica em um cluster de usuários do GKE na AWS por meio de um dos seguintes métodos:

Para configurar um acesso mais granular aos recursos do Kubernetes no nível do cluster ou dentro dos namespaces do Kubernetes, use o Controle de Acesso Baseado em Funções (RBAC) 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. Com o RBAC, você pode controlar o acesso de qualquer identidade validada fornecida.

Para simplificar e otimizar ainda mais sua estratégia de autenticação e autorização para o Kubernetes Engine, o GKE na AWS desabilita o Controle de acesso baseado em atributos herdados (ABAC) .

Criptografia

Por padrão, o GKE na AWS criptografa dados em etcd em repouso , volumes do EBS, segredos do Kubernetes e componentes do plano de controle com o AWS Key Management Service (KMS) .

Para criptografar dados confidenciais em seus clusters de usuários, você pode usar um dos seguintes:

Segredos do Kubernetes

Os recursos do Kubernetes Secrets armazenam dados confidenciais, como senhas, tokens OAuth e chaves SSH, em seus clusters. Armazenar dados confidenciais em Secrets é mais seguro do que armazená-los em ConfigMaps de texto simples ou em especificações de Pod. O uso de Secrets permite que você controle como os dados confidenciais são usados ​​e reduz o risco de exposição dos dados a usuários não autorizados.

Cofre Hashicorp

O GKE na AWS pode usar o Hashicorp Vault para proteger segredos em seus clusters de usuários. Consulte Usando o HashiCorp Vault no GKE na AWS para obter mais informações.

Segurança do plano de controle

Os componentes do plano de controle incluem o serviço de gerenciamento e o servidor da API do Kubernetes do cluster de usuários, o planejador, os controladores e o banco de dados etcd . 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. Você pode proteger o GKE no servidor de API da AWS usando grupos de segurança e ACLs de rede da AWS.

Toda a comunicação no GKE na AWS ocorre por canais de Segurança da Camada de Transporte (TLS) governados pelas seguintes autoridades de certificação (CAs):

  • A CA do etcd protege a comunicação do servidor de API com as réplicas do etcd e também o tráfego entre as réplicas do etcd. Esta CA é autoassinada.
  • A CA do cluster de usuários protege a comunicação entre o servidor da API e todos os clientes internos da API do Kubernetes (kubelets, controladores, agendadores). Essa CA é criptografada por KMS.
  • A CA do serviço de gerenciamento é criptografada pelo AWS KMS. Ela é criada quando você executa anthos-gke init e armazenada no seu espaço de trabalho do Terraform. Ao usar terraform apply para criar o serviço de gerenciamento, a chave da CA é passada como dados do usuário do AWS EC2 e descriptografada pelo AWS KMS quando o cluster é iniciado.

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

A autenticação de cluster no GKE na AWS é gerenciada por certificados e tokens de portador de conta de serviço. Como administrador, você se autentica no plano de controle usando o certificado administrativo para o serviço de gerenciamento (que você usa para a criação inicial de vinculação de função ou para fins emergenciais).

A rotação de certificados é tratada das seguintes maneiras:

Segurança do nó

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

Ubuntu

O GKE na AWS usa uma versão otimizada do Ubuntu como sistema operacional para executar o plano de controle e os nós do Kubernetes. O Ubuntu inclui um amplo conjunto de recursos de segurança modernos, e o GKE na AWS implementa diversos recursos de aprimoramento de segurança para clusters, incluindo:

  • Conjunto de pacotes otimizado.
  • Google Cloud-kernel Linux personalizado.
  • Contas de usuários limitadas e login root desabilitado.

Guias de segurança adicionais estão disponíveis para o Ubuntu, como:

Atualizações de nós

Você deve atualizar seus nós regularmente. De tempos em tempos, problemas de segurança no ambiente de execução do contêiner, no próprio Kubernetes ou no sistema operacional do nó podem exigir que você atualize seus nós com mais urgência. Ao atualizar seu cluster de usuários, o software de cada nó é atualizado para as versões mais recentes. Além disso, a atualização dos nós rotaciona as credenciais de criptografia .

Protegendo suas cargas de trabalho

O Kubernetes permite que os usuários provisionem, escalem e atualizem rapidamente cargas de trabalho baseadas em contêineres. Esta seção descreve táticas que você pode usar para limitar os efeitos colaterais da execução de contêineres no cluster e no Google Cloud serviços.

Limitando privilégios de processo do contêiner Pod

Limitar os privilégios de processos em contêineres é importante para a segurança do seu cluster. Você pode definir opções relacionadas à segurança com o Contexto de Segurança de Pods e contêineres. Essas configurações permitem alterar as configurações de segurança dos seus processos, como:

  • Usuário e grupo executando o processo.
  • Recursos Linux disponíveis.
  • Escalonamento de privilégios.

O sistema operacional padrão do nó GKE on AWS, Ubuntu, aplica as políticas de segurança padrão do Docker AppArmor a todos os contêineres iniciados pelo Kubernetes. Você pode visualizar o modelo do perfil no GitHub . Entre outras coisas, o perfil nega as seguintes capacidades aos contêineres:

  • Escrevendo em arquivos diretamente em um diretório de ID de processo ( /proc/ ).
  • Escrevendo em arquivos que não estão em /proc/ .
  • Escrevendo em arquivos em /proc/sys diferentes de /proc/sys/kernel/shm* .
  • Montagem de sistemas de arquivos.

O que vem a seguir