Este documento explica as medidas de segurança integradas no Connect.
Uma plataforma híbrida e multinuvem eficaz oferece gestão centralizada, observabilidade e acesso a serviços em todos os ambientes. O GKE Enterprise oferece uma experiência uniforme e abrangente nessas capacidades, independentemente do fornecedor do Kubernetes que usar. O Connect é um agente simples que oferece o seguinte à escala e em vários fornecedores:
- Gestão de vários clusters e visibilidade do cluster
- Implementação de serviços de aplicações e gestão do ciclo de vida
Este documento aborda o seguinte:
- Como o design do Connect dá prioridade à segurança
- Práticas recomendadas para a implementação do agente do Connect
- Como melhorar a postura de segurança da sua implementação do Kubernetes
Arquitetura do Connect
O Connect permite que os utilizadores finais e os serviços acedam a servidores da API Kubernetes que não estão na Internet pública. Google CloudO agente Connect é executado no cluster do Kubernetes (um agente por cluster) e liga-se a um proxy Connect. Google Cloud Os serviços que precisam de interagir com o cluster do Kubernetes ligam-se ao proxy, que encaminha os pedidos para o agente. Por sua vez, o agente encaminha-os para o servidor da API Kubernetes, conforme representado no diagrama seguinte.
Quando o agente é implementado, estabelece uma ligação TLS 1.2+ persistente aos serviços Google Cloud para aguardar pedidos. Google Cloud Quando ativados pelos administradores, os serviços podem gerar pedidos para os seus clusters do Kubernetes. Estas solicitações também podem resultar da interação direta do utilizador com a Google Cloud consola, o Connect Gateway ou outros serviços Google.
O Google Cloud serviço envia o pedido ao proxy. Em seguida, o proxy encaminha o pedido para o agente implementado responsável por um cluster e, finalmente, o agente encaminha o pedido para o servidor da API Kubernetes. O servidor da API Kubernetes aplica políticas de autenticação, autorização e registo de auditoria do Kubernetes e devolve uma resposta. A resposta é transmitida novamente através do agente e do proxy para o serviço Google Cloud . Em cada passo do processo, os componentes realizam a autenticação e a autorização por ligação e por pedido.
O servidor da API Kubernetes aplica as mesmas políticas de autenticação, autorização e registo de auditoria a todos os pedidos, incluindo pedidos através do Connect. Este processo garante que tem sempre o controlo do acesso ao seu cluster.
Ligação e defesa em profundidade
A defesa em profundidade é intrínseca a tudo o que a Google Cloud faz na sua infraestrutura e práticas de segurança. Adotamos uma abordagem em camadas a todos os aspetos da segurança da nossa organização e dos nossos clientes para proteger dados, informações e utilizadores valiosos. Este é o mesmo princípio pelo qual criámos a Saúde Connect.
Além da estratégia e do design de defesa em profundidade da Google, deve avaliar o conteúdo fornecido aqui juntamente com a sua postura e normas de segurança. Esta secção destaca medidas adicionais que pode tomar e que complementam as práticas recomendadas de reforço da segurança do Kubernetes.
Segurança de componente para componente
Cada componente de um pedido Connect autentica os respetivos pares e partilha apenas dados com pares que estão autenticados e autorizados para esses dados, conforme ilustrado no diagrama seguinte.
Cada componente de um pedido Connect usa o seguinte para autenticar-se mutuamente:
- Segurança da camada de transporte (TLS, Transport Layer Security)
- Application Layer Transport Security (ALTS)
- OAuth
Cada componente de um pedido Connect usa o seguinte para autorizar-se mutuamente:
- Gestão de identidade e de acesso (IAM)
- Listas de autorizações
Cada ligação entre o cluster do Kubernetes e o Google Cloud está encriptada e, pelo menos, um par de cada ligação usa a autenticação baseada em certificados. Este processo ajuda a garantir que todas as credenciais de tokens são encriptadas em trânsito e apenas recebidas por pares autenticados e autorizados.
Autenticação de utilizador para Google Cloud
Quando usam a Google Cloud consola, os utilizadores passam pelo fluxo de início de sessão padrão da Google. Google Cloud fornece um certificado TLS que o navegador do utilizador autentica, e o utilizador inicia sessão numa Google Cloud ou conta do Google Workspace para autenticar no Google Cloud.
O acesso a um projeto através da Google Cloud consola ou de outras APIs é controlado pelas autorizações IAM.
Google Cloud autenticação de serviço para serviço
Google Cloud usa o ALTS para a autenticação interna de serviço para serviço. O ALTS permite que os serviços Google Cloud , como o proxy, criem uma ligação autenticada e protegida contra adulteração.
OsGoogle Cloud serviços têm de ser autorizados internamente para usar o proxy para se ligarem a uma instância remota do Connect, porque o proxy usa uma lista de autorizações de identidades de serviço para limitar o acesso.
A autenticar Google Cloud
O agente usa o TLS para autenticar e encriptar cada ligação. O agente autentica os certificados TLS através de um conjunto de certificados de raiz incorporados no ficheiro binário, para evitar confiar inadvertidamente em certificados adicionados ao contentor do agente. Google Cloud O agente apenas executa chamadas da API em relação a pontos finais autenticados corretamente. Este processo ajuda a garantir que os certificados da conta de serviço e os pedidos da API Kubernetes são enviados porGoogle Cloud, e que as respostas são enviadas apenas para Google Cloud.
Para ver a lista de domínios com os quais o agente comunica durante o funcionamento normal, consulte o artigo Garantir a conetividade de rede.
Pode configurar o agente para estabelecer ligação Google Cloud através de um proxy HTTP. Nesta configuração, o agente usa o HTTP/1.1
CONNECT contra o proxy HTTP e estabelece uma ligação TLS a
Google Cloud. O proxy HTTP só vê o tráfego encriptado entre o agente e Google Cloud. A integridade e a segurança ponto a ponto da ligação entre o agente e Google Cloud não são afetadas.
Autenticar o agente
O agente efetua a autenticação no Google Cloud através da federação de identidade da carga de trabalho da frota. A federação do Workload Identity da frota permite-lhe autenticar a partir de cargas de trabalho da frota para Google Cloud APIs através de mecanismos de autenticação Google Cloud incorporados e do Kubernetes. Quando o agente quer autenticar-se no Google Cloud, troca o respetivo token da conta de serviço do Kubernetes por um token de acesso que representa a respetiva identidade da carga de trabalho.
Servidor da API Kubernetes
O agente usa a biblioteca cliente do Kubernetes para criar uma ligação TLS ao servidor da API Kubernetes. O tempo de execução do Kubernetes fornece ao contentor do agente um certificado da autoridade de certificação (AC) TLS que o agente usa para autenticar o servidor da API.
O servidor da API autentica cada pedido separadamente, conforme descrito na secção seguinte.
Solicite segurança
Cada pedido enviado a partir de Google Cloud através do Connect inclui credenciais que identificam o remetente do pedido: o serviçoGoogle Cloud que gerou o pedido e (quando aplicável) o utilizador final para quem o pedido é enviado. Estas credenciais permitem que o servidor da API Kubernetes forneça autorização e controlos de auditoria para cada pedido.
Autenticação de serviço para agente
Cada pedido enviado para o agente inclui um token de curta duração que identifica o Google Cloud serviço que enviou o pedido, conforme ilustrado no seguinte diagrama.
O token é assinado por uma Google Cloud conta de serviço associada exclusivamente ao serviço Google Cloud . O agente obtém as chaves públicas da conta de serviço para validar o token. Este token não é encaminhado para o servidor da API.
O agente valida os certificados Google Cloud através de raízes de AC incorporadas no ficheiro binário. Este processo ajuda a garantir que está a receber pedidos autênticos e inalterados de Google Cloud.
Autenticação do utilizador final
Google Cloud Os serviços que acedem a clusters em nome de um utilizador requerem as credenciais desse utilizador para autenticação no servidor da API, conforme ilustrado no seguinte diagrama.
Esta política ajuda a garantir que o mesmo conjunto de autorizações é aplicado ao utilizador quando acede através do Connect. Alguns Google Cloud serviços autenticam-se no servidor da API em nome de um utilizador. Por exemplo, um utilizador pode aceder à Google Cloud consola para ver cargas de trabalho em clusters inscritos na frota. Quando um utilizador acede a estes serviços, fornece credenciais que o servidor da API Kubernetes reconhece: qualquer um dos tokens que o servidor da API Kubernetes suporta.
A Google Cloud consola armazena estas credenciais como parte do perfil de um utilizador. Estas credenciais são encriptadas em repouso, só são acessíveis com as credenciais do utilizador Google Cloud ou do Google Workspace e só são usadas para ligações através do Connect. Não é possível transferir novamente estas credenciais. As credenciais são eliminadas quando o utilizador termina sessão no cluster, quando o registo do cluster é eliminado no Google Cloud, quando o projeto é eliminado ou quando a conta de utilizador é eliminada. Para mais informações, consulte Eliminação de dados no Google Cloud.
Quando um utilizador interage com a Google Cloud consola, esta gera pedidos para o servidor da API Kubernetes. O serviço envia as credenciais do utilizador juntamente com o pedido através do Connect. Em seguida, o agente apresenta o pedido e as credenciais ao servidor da API Kubernetes.
O servidor da API Kubernetes autentica as credenciais do utilizador, realiza a autorização na identidade do utilizador, produz um evento de auditoria para a ação (se configurado) e devolve o resultado. Uma vez que as credenciais fornecidas pelo utilizador são usadas para autenticar o pedido, o servidor da API Kubernetes aplica a mesma política de autorização e auditoria para pedidos do Connect que aplica a outros pedidos.
Autenticação de serviço para Kubernetes
Google Cloud Os serviços que acedem ao servidor da API Kubernetes fora do contexto de um utilizador usam a representação do Kubernetes para fazer a autenticação no servidor da API Kubernetes. Este método permite que o servidor da API Kubernetes forneça verificações de autorização por serviço e registo de auditoria, conforme ilustrado no diagrama seguinte.
Os serviços em Google Cloud podem usar o Connect fora do contexto de um utilizador. Por exemplo, um serviço de entrada de vários clusters pode sincronizar automaticamente os recursos de entrada entre clusters. Estes serviços não têm credenciais que o servidor da API Kubernetes possa autenticar: a maioria dos servidores da API não está configurada para autenticar as credenciais do Google Cloud serviço. No entanto, um servidor de API pode delegar privilégios de autenticação limitados a outro serviço através da representação, e o agente pode autenticar os serviços que enviam pedidos através do Connect. Google Cloud Em conjunto, estes permitem que os pedidos através do agente sejam autenticados como contas de serviço. Google Cloud
Quando um Google Cloud serviço envia um pedido em seu próprio nome (em vez de no contexto de um utilizador), o agente adiciona as suas próprias credenciais do Kubernetes, e cabeçalhos de roubo de identidade do Kubernetes que identificam o Google Cloud serviço, ao pedido. Os cabeçalhos de roubo de identidade reivindicam um nome de utilizador da Google Cloud conta de serviço autenticada pelo agente.
O servidor da API Kubernetes autentica as credenciais do agente e também verifica se o agente se pode fazer passar por a conta de serviço Google Cloud . Normalmente, a capacidade de roubar a identidade é controlada por regras de controlo de acesso baseado em funções (CABF) e pode ser limitada a identidades específicas, como contas de serviço. Google Cloud
Se o agente estiver autorizado a roubar a identidade pedida, o servidor da API faz verificações de autorização para a conta de serviço e processa o pedido. Google Cloud O registo de auditoria do pedido inclui a identidade do agente e a conta de serviço Google Cloud roubada.
Segurança no cluster
Em última análise, o agente envia pedidos da API Kubernetes para o servidor da API Kubernetes, conforme ilustrado no diagrama seguinte.
O servidor da API Kubernetes autentica, autoriza e regista em registos de auditoria estes pedidos, tal como faz para todos os outros pedidos que serve.
Como um proxy para estas solicitações, o agente tem acesso a dados confidenciais, como credenciais, solicitações e respostas. O Kubernetes e o ecossistema do Kubernetes oferecem um conjunto de ferramentas para impedir que outros intervenientes obtenham esse acesso e para ajudar a garantir que o agente só acede ao que deve.
Autenticação do Kubernetes
O servidor da API Kubernetes autentica o remetente de cada pedido recebido para determinar que autorizações aplicar na fase de autorização. Conforme descrito anteriormente, o pedido inclui as credenciais de um utilizador ou inclui as credenciais do Kubernetes do agente e os cabeçalhos de roubo de identidade.
Os administradores do cluster mantêm o controlo dos mecanismos de autenticação reconhecidos pelo servidor da API Kubernetes. Os administradores podem revogar as credenciais de um utilizador e podem revogar ou reduzir o privilégio das credenciais do agente.
Autorização do Kubernetes
O servidor da API Kubernetes verifica se a identidade autenticada tem autorização para realizar a ação pedida no recurso pedido.
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 dos agentes
O agente tem acesso às suas próprias credenciais (Kubernetes e Google Cloud), bem como às credenciais, aos pedidos e às respostas que passam por ele. Como tal, o agente ocupa uma posição fidedigna num cluster ligado.
O agente foi concebido com os seguintes fundamentos de segurança:
- O agente é escrito em Go, que oferece gestão de memória com recolha de lixo e evita muitas operações de memória inseguras.
- O agente é implementado numa imagem de contentor distroless. A imagem do agente não inclui um shell, libc> ou outro código estranho ao caminho de execução do agente.
- A imagem do agente é criada pela infraestrutura de criação partilhada da Google a partir de código validado. Apenas este sistema de compilação pode implementar imagens de agentes no Container Registry. Google Cloud Os programadores não podem implementar novas imagens por conta própria. Este processo ajuda a garantir que todas as edições à origem do agente podem ser rastreadas até um autor e um revisor para não repúdio.
O agente é executado como uma implementação padrão num cluster do Kubernetes que é implementado no momento em que regista o cluster.
Como resultado, todas as opções e práticas recomendadas disponíveis para monitorizar e proteger implementações, ReplicaSets e pods estão disponíveis para o agente.
Estes mecanismos foram concebidos para dificultar a comprometer o contentor do agente. No entanto, o acesso privilegiado ao nó do agente ainda pode comprometer o ambiente do agente. Por conseguinte, é 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 os VPC Service Controls
Os VPC Service Controls oferecem uma camada adicional de defesa de segurança para Google Cloud serviços que é independente da gestão de identidade e de acesso (IAM). Embora a IAM permita um controlo de acesso baseado na identidade detalhado, os VPC Service Controls permitem uma segurança de perímetro baseada no contexto mais ampla, incluindo o controlo da saída de dados no perímetro. Por exemplo, pode especificar que apenas determinados projetos podem aceder aos seus dados do BigQuery. Pode saber mais sobre como o VPC Service Controls funciona para proteger os seus dados na vista geral do VPC Service Controls.
Pode usar os VPC Service Controls com o Connect para ter segurança de dados adicional, depois de garantir que os serviços necessários para usar o Connect podem ser acedidos a partir do perímetro de serviço especificado.
Se quiser usar os VPC Service Controls, tem de ativar as seguintes APIs:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
Também tem de configurar a conetividade privada para aceder às APIs relevantes. Pode saber como fazê-lo em Configure a conetividade privada.