Neste documento, explicamos as medidas de segurança integradas ao Connect.
Uma plataforma híbrida eficiente com várias nuvens que oferece gerenciamento centralizado, capacidade de observação e acesso a serviços em vários ambientes. O GKE Enterprise oferece uma experiência uniforme e abrangente em todos esses recursos, independentemente do provedor do Kubernetes que você usar. O Connect é um agente leve que fornece o seguinte em termos de economia no escalonamento em vários provedores:
- Gerenciamento de vários clusters e visibilidade dos clusters
- Implantação de serviços de aplicativos e gerenciamento do ciclo de vida
Neste documento, você verá os seguintes tópicos:
- Como o design do Connect prioriza a segurança
- Práticas recomendadas para a implantação do Connect Agent
- Como melhorar a postura de segurança na implantação do Kubernetes
Arquitetura do Connect
O Connect permite que usuários finais e serviços do Google Cloud acessem servidores da API Kubernetes que não estão na Internet pública. O agente do Connect é executado no cluster do Kubernetes (um agente por cluster) e se conecta a um proxy do Connect. Os serviços do Google Cloud que precisam interagir com o cluster do Kubernetes se conectam ao proxy, que encaminha as solicitações ao agente. O agente, por sua vez, as encaminha para o servidor da API do Kubernetes, como mostrado no diagrama a seguir.
Quando o agente é implantado, ele estabelece uma conexão TLS 1.2+ permanente com o Google Cloud para aguardar solicitações. Os serviços do Google Cloud, quando ativados por administradores, podem gerar solicitações para os clusters do Kubernetes. Essas solicitações também podem vir da interação direta do usuário com o console do Google Cloud, o Connect Gateway ou outros serviços do Google.
O serviço do Google Cloud envia a solicitação ao proxy. Em seguida, o proxy encaminha a solicitação ao agente implantado responsável por um cluster e, por fim, o agente encaminha a solicitação ao servidor da API do Kubernetes. O servidor da API do Kubernetes aplica as políticas de autenticação, autorização e geração de registros de auditoria do Kubernetes e retorna uma resposta. A resposta é enviada por meio do agente e do proxy para o serviço do Google Cloud. Em cada etapa do processo, os componentes fazem autenticação e autorização por conexão e por solicitação.
O servidor da API do Kubernetes aplica as mesmas políticas de autenticação, autorização e geração de registros de auditoria a todas as solicitações, incluindo solicitações do Connect. Esse processo garante que você esteja sempre no controle do acesso ao cluster.
Conexão e defesa em profundidade
A defesa em profundidade (em inglês) é essencial a tudo que o Google Cloud faz na sua infraestrutura e práticas de segurança. Para proteger dados, informações e usuários valiosos, adotamos uma abordagem em camadas para todos os aspectos de segurança da nossa organização e dos nossos clientes. Esse é o mesmo princípio do design do Connect.
Além da estratégia e do design de defesa em profundidade do Google, avalie o conteúdo fornecido aqui junto com sua postura e seus padrões de segurança. Nesta seção, você verá mais medidas que podem ser adotadas para complementar as práticas recomendadas de aumento da proteção do Kubernetes.
Segurança de componente a componente
Cada componente de uma solicitação do Connect autentica os respectivos pares e só compartilha dados com pares autenticados e autorizados para esses dados, conforme ilustrado no diagrama a seguir.
Cada componente de uma solicitação do Connect usa o seguinte para autenticar um ao outro:
- Transport Layer Security (TLS)
- Application Layer Transport Security (ALTS)
- OAuth
Cada componente de uma solicitação do Connect usa o seguinte para autorizar um ao outro:
- Identity and Access Management (IAM)
- Listas de permissões
Cada conexão entre o cluster do Kubernetes e o Google Cloud é criptografada, e pelo menos um par de cada conexão usa a autenticação baseada em certificado. Esse processo ajuda a garantir que todas as credenciais de token sejam criptografadas em trânsito e recebidas apenas por pares autenticados e autorizados.
Autenticação do usuário no Google Cloud
Ao usar o console do Google Cloud, os usuários passam pelo fluxo padrão de login do Google. O Google Cloud fornece um certificado TLS que o navegador do usuário autentica, e o usuário faz login em uma conta do Google Cloud ou do Google Workspace para se autenticar no Google Cloud.
O acesso a um projeto pelo console do Google Cloud ou de outras APIs é controlado pelas permissões do IAM.
Autenticação de serviço a serviço do Google Cloud
O Google Cloud usa o ALTS para autenticação interna de serviço a serviço. O ALTS permite que os serviços do Google Cloud, como o proxy, criem uma conexão autenticada e protegida por integridade.
Os serviços do Google Cloud precisam ter uma autorização interna para usar o proxy para se conectar a uma instância remota do Connect. Isso é feito porque o proxy usa uma lista de permissões de identidades de serviço para limitar o acesso.
Como autenticar o Google Cloud
O agente usa TLS para autenticar e criptografar cada conexão. Para autenticar os certificados TLS do Google Cloud, ele usa um conjunto de certificados raiz integrados ao binário para evitar que os certificados adicionados ao contêiner do agente sejam aceitos como confiáveis sem intenção. O agente só executa chamadas de API em endpoints autenticados corretamente. Esse processo ajuda a garantir que os certificados da conta de serviço e as solicitações da API do Kubernetes sejam enviados pelo Google Cloud e que todas as respostas sejam enviadas apenas ao Google Cloud.
Para a lista de domínios com os quais o agente se comunica durante a operação normal, consulte Garantir a conectividade de rede.
É possível configurar o agente para se conectar ao Google Cloud por meio de um proxy HTTP. Nessa configuração, o agente usa o HTTP/1.1
CONNECT com o proxy HTTP e estabelece uma conexão TLS com o Google Cloud. O proxy HTTP vê somente o tráfego criptografado entre o agente e o Google Cloud. A integridade total e a segurança da conexão entre o agente e o Google Cloud não são afetadas.
Como autenticar o agente
O agente faz a autenticação no Google Cloud usando uma conta de serviço do Google Cloud criada por você. Quando o administrador do cluster implanta o agente, ele fornece uma chave privada para essa conta de serviço e assume a responsabilidade pela privacidade da chave. Quando o agente se conecta ao Google Cloud, ele faz a autenticação com essa conta de serviço e solicita o recebimento de solicitações para o projeto configurado.
O Google Cloud autentica as credenciais da conta de serviço e também verifica se a conta de serviço do Google Cloud tem a permissão do IAM gkehub.endpoints.connect no projeto. Essa permissão geralmente é concedida por meio do papel gkehub.connect. Sem essa permissão, a solicitação do agente é negada e não é possível receber solicitações do Google Cloud.
Servidor da API Kubernetes
O agente usa a biblioteca de cliente do Kubernetes para criar uma conexão TLS com o servidor da API do Kubernetes. O ambiente de execução do Kubernetes fornece ao contêiner do agente um certificado de autoridade de certificação TLS que o agente usa para autenticar o servidor da API.
O servidor de API autentica cada solicitação separadamente, conforme descrito na próxima seção.
Segurança das solicitações
Cada solicitação enviada do Google Cloud pelo Connect inclui credenciais que identificam o remetente da solicitação: o serviço do Google Cloud que a gerou e, quando aplicável, o usuário final para quem a solicitação foi enviada. Essas credenciais permitem que o servidor da API do Kubernetes forneça controles de autorização e auditoria para cada solicitação.
Autenticação do serviço para o agente
Cada solicitação enviada ao agente inclui um token de curta duração que identifica o serviço do Google Cloud que a enviou, conforme ilustrado no diagrama a seguir.
O token é assinado por uma conta de serviço do Google Cloud associada exclusivamente ao serviço. O agente busca as chaves públicas da conta de serviço para validar o token. Esse token não é encaminhado ao servidor da API.
O agente valida certificações do Google Cloud usando raízes de CA incorporadas no binário. Esse processo ajuda a garantir que ele receba solicitações autênticas e inalteradas do Google Cloud.
Autenticação de usuário final
Os serviços do Google Cloud que acessam clusters em nome de um usuário exigem que as credenciais do usuário sejam autenticadas no servidor da API, conforme ilustrado no diagrama a seguir.
Essa política ajuda a garantir que o mesmo conjunto de permissões seja aplicado ao usuário no acesso pelo Connect. Alguns serviços do Google Cloud são autenticados no servidor da API em nome de um usuário. Por exemplo, um usuário pode acessar o console do Google Cloud para ver cargas de trabalho em clusters inscritos pelo Fleet. Quando um usuário acessa esses serviços, ele fornece credenciais que o servidor da API Kubernetes reconhece: qualquer um dos tokens compatíveis com o servidor API Kubernetes.
O console do Google Cloud armazena essas credenciais como parte do perfil de um usuário. Essas credenciais são criptografadas em repouso, são acessíveis apenas com as credenciais do usuário do Google Cloud ou do Google Workspace e são usadas apenas para conexões por meio do Connect. Não é possível fazer o download dessas credenciais novamente. Elas são excluídas quando o usuário sai do cluster, o registro do cluster é excluído do Google Cloud, o projeto é excluído ou a conta de usuário é excluída. Para mais informações, consulte Exclusão de dados no Google Cloud.
Quando um usuário interage com o console do Google Cloud, ele gera solicitações para o servidor da API do Kubernetes. O serviço envia as credenciais do usuário junto com a solicitação pelo Connect. Em seguida, o agente apresenta a solicitação e as credenciais ao servidor da API do Kubernetes.
O servidor da API do Kubernetes autentica as credenciais do usuário, autoriza a identidade dele, produz um evento de auditoria para a ação (se configurado) e retorna o resultado. Como as credenciais fornecidas pelo usuário são usadas para autenticar a solicitação, o servidor da API do Kubernetes aplica às solicitações do Connect a mesma autorização e política de auditoria aplicadas a outras solicitações.
Autenticação do serviço para o Kubernetes
Os serviços do Google Cloud que acessam o servidor da API do Kubernetes fora de um contexto de usuário usam a personificação do Kubernetes para autenticação. Esse método permite que o servidor da API do Kubernetes forneça verificações de autorização por serviço e geração de registros de auditoria, conforme ilustrado no diagrama a seguir.
Os serviços do Google Cloud podem usar o Connect fora do contexto de um usuário. Por exemplo, um serviço de entrada multicluster pode sincronizar automaticamente recursos de entrada entre clusters. Esses serviços não têm credenciais que podem ser autenticadas pelo servidor da API do Kubernetes. A maioria dos servidores de API não está configurada para autenticar as credenciais do serviço do Google Cloud. No entanto, um servidor de API pode delegar privilégios de autenticação limitados a outro serviço por meio da personificação, e o agente pode autenticar solicitações de envio de serviços do Google Cloud por meio do Connect. Juntos, eles permitem que as solicitações feitas pelo agente sejam autenticadas como contas de serviço do Google Cloud.
Quando um serviço do Google Cloud envia uma solicitação em seu próprio nome, e não em um contexto de usuário, o agente adiciona as próprias credenciais do Kubernetes e os cabeçalhos de personificação do Kubernetes que identificam o serviço do Google Cloud para a solicitação. Os cabeçalhos de personificação reivindicam um nome de usuário da conta de serviço do Google Cloud autenticada pelo agente.
O servidor da API do Kubernetes autentica as credenciais do agente e também verifica se ele pode personificar a conta de serviço do Google Cloud. A capacidade de personificação normalmente é controlada por regras de controle de acesso com base em papéis (RBAC, na sigla em inglês) e pode ser limitada a identidades específicas, como contas de serviço do Google Cloud.
Se o agente estiver autorizado a personificar a identidade solicitada, o servidor de API realizará verificações de autorização na conta de serviço do Google Cloud e atenderá à solicitação. O registro de auditoria da solicitação inclui a identidade do agente e a conta de serviço personificada do Google Cloud.
Segurança no cluster
Por fim, o agente envia solicitações da API do Kubernetes para o servidor da API do Kubernetes, conforme ilustrado no diagrama a seguir.
O servidor da API do Kubernetes autentica, autoriza e faz registros de auditoria dessas solicitações, assim como faz com todas as outras solicitações que atende.
Como proxy dessas solicitações, o agente tem acesso a dados confidenciais, como credenciais, solicitações e respostas. O Kubernetes e o ecossistema do Kubernetes fornecem um conjunto de ferramentas para impedir que outros atores tenham esse acesso e para ajudar a garantir que o agente só acesse o que deveria.
Autenticação do Kubernetes
O servidor da API do Kubernetes autentica o remetente de cada solicitação recebida para determinar quais permissões aplicar no estágio de autorização. Conforme descrito anteriormente, a solicitação inclui as credenciais de um usuário ou do Kubernetes e os cabeçalhos de representação.
Os administradores do cluster permanecem no controle dos mecanismos de autenticação reconhecidos pelo servidor da API do Kubernetes. Eles podem revogar as credenciais de um usuário e revogar ou reduzir o privilégio das credenciais do agente.
Autorização do Kubernetes
O servidor da API do Kubernetes verifica se a identidade autenticada está autorizada a executar a ação solicitada no recurso solicitado.
O administrador do cluster pode usar qualquer um dos mecanismos de autorização do Kubernetes para configurar regras de autorização. O Connect não realiza verificações de autorização em nome do cluster.
Segurança do agente
O agente tem acesso às próprias credenciais (Kubernetes e Google Cloud), bem como às credenciais, solicitações e respostas que passam por ele. Dessa forma, o agente ocupa uma posição confiável em um cluster conectado.
O agente foi desenvolvido com os seguintes princípios de segurança:
- O agente é escrito em Go, que fornece gerenciamento de memória de coleta de lixo e evita muitas operações de memória não seguras (links em inglês).
- O agente é implantado em uma imagem de contêiner distroless (em inglês). A imagem do agente não inclui um shell, um libc ou outro código desconhecido ao caminho de execução do agente.
- A imagem do agente é criada pela infraestrutura de compilação compartilhada do Google a partir do código carregado. Somente esse sistema de compilação pode implantar imagens de agentes no Container Registry. Os desenvolvedores do Google Cloud não podem implantar novas imagens por conta própria. Esse processo ajuda a garantir que todas as edições na origem do agente possam ser rastreadas para um autor e revisor para fins de não repúdio.
O agente é executado como uma implantação padrão em um cluster do Kubernetes que implanta no momento em que você registra o cluster.
Como resultado, todas as opções e práticas recomendadas disponíveis para monitoramento e proteção de implantações, ReplicaSets e pods estão disponíveis para o agente.
Esses mecanismos são projetados para dificultar o comprometimento do contêiner do agente. No entanto, o acesso privilegiado ao nó do agente ainda pode comprometer o ambiente do agente. Portanto, é importante que os administradores sigam as diretrizes de segurança padrão do Kubernetes para proteger a infraestrutura do cluster.
Segurança de dados com VPC Service Controls
O VPC Service Controls oferece uma camada adicional de defesa de segurança para serviços do Google Cloud, independente do gerenciamento de identidade e acesso (IAM, na sigla em inglês). Enquanto o IAM permite um controle de acesso baseado em identidade granular, o VPC Service Controls permite uma segurança de perímetro baseada em contexto mais ampla, incluindo o controle da saída de dados em todo o perímetro. Por exemplo, é possível especificar que apenas determinados projetos possam acessar seus dados do BigQuery. Para saber mais sobre como o VPC Service Controls funciona para proteger seus dados, consulte a Visão geral do VPC Service Controls.
É possível usar o VPC Service Controls com o Connect para aumentar a segurança dos dados, garantindo que os serviços necessários para usá-lo possam ser acessados de dentro do perímetro de serviço especificado. Saiba mais nos pré-requisitos do Connect.