Segurança do serviço

Este documento fornece uma visão geral da segurança de serviço com o Cloud Service Mesh. Ele é destinado a usuários do Cloud Service Mesh que querem adicionar autenticação, criptografia e autorização às implantações. Neste documento, presumimos que você esteja familiarizado com a Visão geral da Cloud Service Mesh e com aplicativos gRPC sem proxy.

O Cloud Service Mesh permite proteger comunicações de serviço a serviço na malha. Na malha, cada serviço tem uma identidade. Os recursos a seguir ajudam a oferecer suporte a comunicações seguras:

  • Autenticação e criptografia que usam o Transport Layer Security (TLS) e o TLS mútuo (mTLS) para o Cloud Service Mesh com o Envoy e o Cloud Service Mesh com aplicativos gRPC sem proxy. As políticas de TLS do cliente e as políticas de TLS do servidor controlam se os serviços precisam comprovar as identidades deles e usar canais de comunicação criptografados.
  • Autorização, com base nas características do cliente e da solicitação. As políticas de autorização controlam se um serviço tem permissão para acessar outro serviço e quais ações são permitidas.

Além disso, o uso de certificados e chaves fornecidos por uma autoridade certificadora (CA, na sigla em inglês) particular, o Certificate Authority Service do Google, facilita a manutenção da segurança do serviço. O serviço de CA fornece certificados de malha do GKE. O recurso de certificados de malha do GKE e o Cloud Service Mesh permitem implantar automaticamente esses certificados e fazer com que as cargas de trabalho os usem. Modifique os pods para permitir que as cargas de trabalho recebam e usem credenciais mTLS. No momento, a segurança do serviço do Cloud Service Mesh está disponível apenas para cargas de trabalho baseadas no GKE.

Em arquiteturas modernas baseadas em microsserviços, serviços menores e mais focados substituem aplicativos monolíticos grandes. As chamadas de serviço se comunicam entre si pela rede. Essas chamadas, que eram em processo em aplicativos monolíticos, apresentam desafios de segurança. Portanto, é melhor autenticar, criptografar e autorizar as chamadas. Essas etapas são suportam o princípio de confiança zero, em que todo o tráfego de rede é considerado como estando em risco, independentemente de o tráfego ser originado dentro ou fora da rede.

O padrão de design da malha de serviço separa a complexidade relacionada às comunicações de serviço a serviço da lógica de negócios. Isso fica por conta do plano de dados. Além de reduzir a complexidade do aplicativo, o padrão de design da malha de serviço permite padrões de segurança que podem ser difíceis de implementar e gerenciar.

Neste modelo, os arquivos secundários do gRPC ou do Envoy sem proxy autenticam e criptografam com segurança as comunicações ao receber informações de configuração da Cloud Service Mesh e de certificados de um pool de serviços de AC.

Esses recursos de segurança facilitam o processo de implantação do Cloud Service Mesh fornecendo o seguinte:

  • Provisionamento automático de chaves e certificados para todos os serviços na sua malha.
  • Rotação automática de chaves e certificados para fornecer segurança adicional.
  • Integração com o Google Kubernetes Engine (GKE) para usar todos os recursos, como descritores e rótulos de implantação.
  • Alta disponibilidade dos serviços gerenciados pelo Google, incluindo o Cloud Service Mesh e os pools de autoridades certificadoras particulares gerenciadas pelo serviço de AC.
  • Segurança vinculada ao Google Identity and Access Management (IAM): autorização de serviço com base em contas de serviço autorizadas do Google.
  • Interoperabilidade perfeita com suas cargas de trabalho baseadas em Envoy e sem proxy. Por exemplo, um serviço pode estar atrás de um proxy Envoy, mas o cliente usa segurança de malha de serviço sem proxy do gRPC. Por outro lado, um serviço pode estar por trás da segurança da malha de serviço sem proxy do gRPC, mas o cliente usa um proxy Envoy.

Comunicações seguras entre serviços

O Cloud Service Mesh oferece autorização e segurança de serviço a serviço com criptografia e autenticação que usam TLS. As políticas de TLS do cliente e as políticas de TLS do servidor permitem aos serviços:

  • Declarar e validar as identidades.
  • Criptografar sessões de comunicação usando TLS ou mTLS.

Em uma malha de serviço, o plano de dados cuida desse tipo de segurança para que os aplicativos não precisem fazer provisionamentos especiais para serem seguros.

As políticas de autorização permitem negar ou permitir acesso de acordo com as regras que você definir.

Usar TLS para criptografia

Quando um serviço chama em outro serviço usando o protocolo HTTP, HTTP/2 ou gRPC, o tráfego que transita pela rede está em texto simples. Esse tráfego pode estar sujeito a ataques person-in-the-middle, em que um invasor intercepta o tráfego e inspeciona ou manipula o conteúdo dele.

Para atenuar esse possível problema, use HTTP, HTTP/2 ou gRPC por TLS com a Cloud Service Mesh. Quando você usa esse protocolos em vez TLS, o tráfego entre o cliente e o servidor é criptografado usando TLS baseado no certificado do servidor. O tráfego não está mais em texto simples, reduzindo a probabilidade de um invasor interceptar e inspecionar ou manipular seu conteúdo.

Usar TLS para autenticação

Quando um serviço faz chamadas em outro serviço, considere as seguintes perguntas:

  • Como um cliente sabe que está recebendo uma resposta do servidor correto e não de um impostor? Por exemplo, em uma interação comum de solicitação/resposta com base em HTTP, o cliente não verifica a identidade do servidor.

  • O que acontece se um invasor interceptar esse tráfego? Por exemplo, o tráfego HTTP não é criptografado, então qualquer pessoa que receba o tráfego pode inspecionar o conteúdo. Isso é conhecido como ataque "person-in-the-middle".

Para atenuar esses problemas, use HTTP, HTTP/2 e gRPC em TLS. Nessas trocas entre um cliente e um servidor, o servidor precisa usar um certificado de servidor para provar a identidade dele ao cliente. As solicitações e as respostas são criptografadas usando TLS.

Autenticação TLS mútua

Quando o Cloud Service Mesh configura a rede de aplicativos para o cliente e para o servidor, por exemplo, configurando um proxy Envoy no lado do cliente e outro proxy Envoy no lado do servidor, é possível aproveitar os padrões de autenticação avançada, como a autenticação mútua.

Em uma troca HTTP em vez TLS típica, que não é baseada na autenticação mútua, o servidor tem um certificado que usa para criptografar as comunicações entre o cliente e o servidor. O cliente pode verificar a identidade do servidor verificando a assinatura que o servidor envia de volta durante o handshake de TLS. No entanto, o servidor não verifica a identidade do cliente.

Quando a autenticação mútua está ativada, o cliente também tem um certificado. O cliente verifica a identidade do servidor, conforme descrito no parágrafo anterior, e o servidor também pode verificar a identidade do cliente. Os certificados do cliente e do servidor são usados para criptografar o canal de comunicação. Isso também permite que o servidor autorize clientes com base na identidade verificada do cliente.

Autenticação TLS mútua (mTLS) em uma malha de serviço.
Autenticação TLS mútua (mTLS) em uma malha de serviço (clique para ampliar)

Autorizar chamadas de serviço

Você pode permitir ou negar o acesso ao serviço usando políticas de autorização. Com o Cloud Service Mesh, é possível definir regras de permissão e negação para autorizar o acesso com base nos parâmetros de solicitação. Você pode basear essas regras nos parâmetros da camada 3 e da camada 7, incluindo o ID do cliente, que é derivado do client-cert em uma conexão mTLS, endereço IP de origem, correspondência de host, correspondência de método e correspondência de cabeçalho. O diagrama a seguir mostra a autorização com os proxies do Envoy. O processo é semelhante com os clientes gRPC.

Autorização em uma malha de serviço
Autorização em uma malha de serviço usando o Envoy (clique para ampliar)

Restringir o acesso usando autorização

Uma prática recomendada em uma malha de serviço é seguir o princípio do menor privilégio. É possível aderir a esse princípio restringindo o acesso de serviço apenas aos autores da chamada que dependem do serviço. Quando um autor da chamada tenta acessar um serviço sem autorização, a tentativa é rejeitada.

Com o Cloud Service Mesh, é possível configurar políticas de autorização que permitem que seu plano de dados permita/recuse acesso ao serviço com base nas regras que você definir. Essas políticas consistem em dois componentes:

  • Uma ação: permitir ou negar
  • Uma lista de regras

Quando uma solicitação ou RPC é enviada, o cliente do Cloud Service Mesh no serviço chamado determina se há uma correspondência de regra. Se uma correspondência for encontrada, a solicitação ou a RPC será permitida ou negada. Você pode definir uma regra para corresponder a atributos, como estes:

  • Quando a mTLS for usada, a conta de serviço do Kubernetes do serviço de chamada
  • O endereço IP ou o intervalo de endereços do serviço de chamada
  • Portas de serviço de destino
  • Os atributos HTTP da solicitação, incluindo nomes de host, métodos e cabeçalhos HTTP definidos pelo usuário.

Nomenclatura segura

Como um mecanismo de segurança extra, você pode configurar a nomeação segura com o Cloud Service Mesh. Isso permite que você defina uma lista de nomes permitidos ou identidades do SPIFFE (Secure Production Identity Framework para todos) para um determinado serviço ao qual um cliente está tentando se conectar. Durante a troca de TLS, o back-end do serviço retorna um certificado X.509 para o cliente. Em seguida, o cliente inspeciona o certificado para confirmar se o certificado X.509 corresponde a uma das identidades de nomes/SPIFFE. Para mais informações sobre as identidades do SPIFFE, consulte Framework de identidade de produção segura para todos.

Proteja o tráfego em um gateway

Para configurar os gateways, use o Cloud Service Mesh. Um gateway é um proxy Envoy autônomo que normalmente atua como um dos seguintes:

  • Um gateway de entrada que processe o tráfego que está entrando em uma malha ou outro domínio
  • Um gateway de saída que processa o tráfego que sai de uma malha ou algum outro domínio
  • Um proxy reverso ou proxy intermediário que distribui o tráfego de entrada entre um ou mais serviços.

Os clientes que querem enviar tráfego para a malha ou para fora dela malham no gateway. Em seguida, o gateway processa as solicitações de acordo com as regras que você configurou com o Cloud Service Mesh. Por exemplo, é possível impor que o tráfego entre na malha (pelo gateway de entrada) seja criptografado usando TLS.

Componentes de segurança

A segurança do serviço do Cloud Service Mesh é compatível com políticas de TLS do cliente, do TLS do servidor e de autorização. Crie essas políticas para que a Cloud Service Mesh possa configurar o plano de dados e ativar os recursos de segurança. Para criar ou atualizar essas políticas, não é necessário fazer alterações nos aplicativos.

Modos de criptografia e autenticação compatíveis

Quando um serviço chama outro, a primeira etapa para estabelecer comunicações seguras é fazer com que cada serviço prove sua identidade para o outro serviço. O grau em que um serviço precisa provar a própria identidade é baseado no modo TLS que você configura.

É possível configurar os seguintes níveis de segurança:

  • Não criptografado/não autenticado
  • TLS
  • TLS mútuo (mTLS)
  • Permissivo: mTLS ou não criptografado/não autenticado, dependendo de como o cliente inicia a conexão

Certificados e Autoridades de certificação

Os certificados e uma autoridade de certificação (CA) confiável fornecem a base para a confiança em um sistema distribuído, como uma malha de serviço. Usando certificados, os serviços podem provar as identidades deles e verificar as identidades apresentadas a les das seguintes maneiras:

  • Um serviço que quer provar a identidade para outro serviço apresenta seu certificado a outro serviço. Uma CA em que ambos os serviços confiam assinam e emitem este certificado contando com criptografia.
  • O serviço que recebe esse certificado pode verificar se o certificado foi emitido por uma CA de confiança.

O Cloud Service Mesh não é uma autoridade certificadora. Para ativar as comunicações seguras, configure um mecanismo que:

  • Provisione identidades e certificados
  • Disponibiliza os certificados para clientes do Cloud Service Mesh, como proxies Envoy, que o Cloud Service Mesh configura.

O Cloud Service Mesh é compatível com o serviço de AC do Google. Os guias de configuração do Envoy e do gRPC sem proxy incluem instruções para configurar isso. Para mais detalhes, consulte A seguir.

Arquitetura e recursos

O Cloud Service Mesh inclui o namespace da API Network Security, que consiste em três recursos da API do Google Cloud que permitem especificar as políticas de segurança que precisam ser aplicadas ao plano de dados.

Dois recursos da API do Google Cloud são compatíveis com a autenticação na malha: políticas de TLS do cliente e políticas de TLS do servidor. Um terceiro recurso, a política de autorização, é compatível com a autorização.

O namespace da API Network Services inclui o recurso de política de endpoint, que permite que o Cloud Service Mesh forneça configuração (TLS do servidor, TLS do cliente e políticas de autorização) para endpoints. Os endpoints são os clientes do Cloud Service Mesh que encerram uma comunicação de entrada de outro cliente do Cloud Service Mesh.

Política de TLS do cliente

Uma política de TLS do cliente permite especificar o modo TLS do cliente e as informações do provedor de certificados a serem aplicadas ao plano de dados. As políticas de TLS do cliente são compatíveis com a autenticação TLS e mTLS. As políticas de TLS do cliente precisam ser anexadas a um recurso de serviço de back-end global.

Ao configurar o TLS, é necessário fornecer um mecanismo pelo qual o cliente valide o certificado recebido do servidor durante a troca de TLS usando o campo da API serverValidationCa. O cliente usa essas informações para conseguir um certificado de validação que pode ser usado para validar o certificado do servidor.

Ao configurar o mTLS, você também precisa fornecer um mecanismo pelo qual o cliente receba o certificado e a chave privada usando o campo da API clientCertificate. O cliente usa essas informações para apresentar um certificado ao servidor durante o handshake de TLS.

Nesta versão, o Cloud Service Mesh oferece suporte a uma autoridade certificadora gerenciada, o serviço de AC. A configuração é simples: você especifica o nome do plug-in google_cloud_private_spiffe ao configurar o provedor de certificado. Isso faz com que os clientes xDS carreguem certificados e chaves de um local estático. Como pré-requisitos, configure pools de serviços de CA e ative certificados de malha no cluster do GKE.

Política de TLS do servidor

Uma política de TLS do servidor (recurso ServerTlsPolicy) permite especificar o modo TLS do servidor e as informações do provedor de certificados a serem aplicadas ao plano de dados. As políticas de TLS do servidor são compatíveis com TLS, mTLS e, apenas com o Envoy, autenticação Open_or_mTLS. As políticas de TLS do servidor são anexadas a um recurso de política de endpoint.

Nomes alternativos do requerente

Ao configurar o campo securitySettings de um serviço de back-end global, é possível fornecer uma lista de nomes alternativos do assunto no campo subjectAltNames. Quando um cliente inicia um handshake de TLS com um dos back-ends do serviço, o servidor apresenta o certificado X.509. O cliente inspeciona o campo subjectAltName do certificado. Se o campo contiver um dos valores especificados, a comunicação continuará. Esse mecanismo é descrito anteriormente em Nomenclatura segura.

Política de autorização

Uma política de autorização (recurso AuthorizationPolicy) especifica como um servidor autoriza solicitações de entrada ou RPCs. Ela pode ser configurada para permitir ou negar uma solicitação de entrada ou RPC com base em vários parâmetros, como a identidade do cliente que enviou a solicitação, o host, os cabeçalhos e outros atributos HTTP. Você anexa políticas de autorização a um recurso de política de endpoint.

Uma regra de política de autorização tem os seguintes componentes:

  • from: especifica a identidade do cliente permitida pela regra. A identidade pode ser derivada de um certificado de cliente em uma conexão TLS mútua ou pode ser a identidade do ambiente associada à VM do cliente, como de uma conta de serviço ou uma tag segura.
  • to: especifica as operações permitidas pela regra, como os URLs que podem ser acessados ou os métodos HTTP permitidos.
  • when: permite definir outras restrições que precisam ser atendidas. É possível usar expressões da Common Expression Language (CEL) para definir as restrições.
  • action: especifica a ação da regra. Pode ser ALLOW, DENY ou CUSTOM.

Limitações

A segurança do serviço do Cloud Service Mesh é compatível apenas com o GKE. Não é possível implantar a segurança do serviço com o Compute Engine.

Ao avaliar uma solicitação, uma política de autorização realiza uma das seguintes ações:

  • ALLOW: concede acesso ao recurso solicitado se a solicitação corresponder às regras definidas na política de autorização. A política de autorização bloqueia o acesso ao recurso solicitado se a solicitação não corresponder a nenhuma regra definida na política de autorização. Uma solicitação é negada se não corresponder a uma política ALLOW, mesmo que outras políticas a permitam.

  • DENY: bloqueia o acesso ao recurso se uma solicitação corresponder a qualquer uma das regras especificadas em uma política DENY. A política de autorização concede acesso ao recurso solicitado se a solicitação não corresponder a nenhuma regra definida na política de autorização. Uma solicitação é negada se corresponder a uma política DENY, mesmo que outras políticas a permitam.

  • CUSTOM (não é compatível com o Cloud Service Mesh) permite a integração com sistemas de autorização externos para decisões de autorização complexas. As ações CUSTOM são usadas para políticas que usam extensões de serviço para decisões de autorização.

Ordem de avaliação da política de autorização

Quando várias políticas de autorização são associadas a um único recurso, elas são avaliadas na ordem a seguir para determinar se uma solicitação é permitida ou negada.

  1. Políticas com ações CUSTOM: se a política CUSTOM negar a solicitação, ela será rejeitada imediatamente. As políticas DENY ou ALLOW não são avaliadas, mesmo que estejam configuradas.

  2. Políticas com ações DENY: se alguma política DENY corresponder à solicitação, ela será negada. As políticas ALLOW não são avaliadas, mesmo que estejam configuradas.

  3. Políticas com ações ALLOW: se não houver políticas ALLOW ou se qualquer política ALLOW corresponder à solicitação, ela será permitida. No entanto, se nenhuma política ALLOW corresponder à solicitação, ela será negada.

Limitações com aplicativos gRPC sem proxy

A segurança de serviços gRPC sem proxy tem as seguintes limitações:

  • Esta versão é limitada a Java, Python, C ++ e Go.

Cotas de AuthzPolicy

  • Você tem um limite de 5 políticas de autorização por gateway.
  • Você tem um limite de 20 recursos AuthzPolicy por projeto.
  • Uma única política de autorização pode apontar para até 100 gateways.

A seguir