Práticas recomendadas de segurança do Cloud Service Mesh

Este documento descreve as práticas recomendadas para estabelecer e controlar uma configuração segura do Cloud Service Mesh em execução no Google Kubernetes Engine (GKE). As orientações no documento vão além das configurações usadas para configurar e instalar o Cloud Service Mesh e descrevem como usá-lo com outros produtos e recursos do Google Cloud para se proteger contra as ameaças de segurança que os aplicativos em uma malha podem enfrentar.

O público-alvo deste documento inclui administradores que gerenciam políticas em um Cloud Service Mesh e usuários que executam serviços em um Cloud Service Mesh. As medidas de segurança descritas aqui também são úteis para organizações que precisam melhorar a segurança das malhas de serviço para atender aos requisitos de conformidade.

O documento está organizado da seguinte forma:

Introdução

O Cloud Service Mesh fornece recursos e ferramentas que ajudam a observar, gerenciar e proteger serviços de maneira unificada. Ele usa uma abordagem centrada no aplicativo e usa identidades de aplicativo confiáveis em vez de uma abordagem focada em IP de rede. É possível implantar uma malha de serviço de maneira transparente, sem a necessidade de modificar o código do aplicativo atual. O Cloud Service Mesh fornece controle declarativo sobre o comportamento de rede, o que ajuda a separar o trabalho das equipes responsáveis por fornecer e liberar recursos de aplicativos das responsabilidades de administradores responsáveis por segurança e rede.

O Cloud Service Mesh é baseado na malha de serviço do Istio de código aberto, que permite configurações e topologias sofisticadas. Dependendo da estrutura da sua organização, uma ou mais equipes ou papéis podem ser responsáveis por instalar e configurar uma malha. As configurações padrão do Cloud Service Mesh são escolhidas para proteger aplicativos. No entanto, em alguns casos, você pode precisar de configurações personalizadas ou conceder exceções excluindo determinados aplicativos, portas ou endereços IP da participação em uma malha. Ter controles para controlar as configurações de malha e as exceções de segurança é importante.

Vetores de ataque e riscos de segurança

Vetores de ataque

A segurança do Cloud Service Mesh segue o modelo de segurança de confiança zero, que pressupõe que as ameaças de segurança são originadas de dentro e fora do perímetro de segurança de uma organização. Exemplos de tipos de ataques de segurança que podem ameaçar aplicativos em uma malha de serviço incluem:

  • Ataques de exfiltração de dados; Por exemplo, ataques que enxergam dados confidenciais ou credenciais de tráfego entre serviços.
  • Ataques man-in-the-middle; Por exemplo, um serviço malicioso que se disfarça como um serviço legítimo para receber ou modificar a comunicação entre serviços.
  • Ataques de escalonamento de privilégios Por exemplo, ataques que usam acesso ilícito a privilégios elevados para realizar operações em uma rede.
  • ataques de negação de serviço (DoS);
  • Ataques de botnet que tentam comprometer e manipular os serviços para lançar ataques a outros serviços

Os ataques também podem ser categorizados com base nos alvos do ataque:

  • Ataques internos de rede em malha. Ataques destinados a adulterar, espionar ou spoofing a comunicação interna de serviço a serviço ou de plano de controle de serviço.
  • Ataques do plano de controle Os ataques que causam o mau funcionamento do plano de controle (como um ataque de DoS) ou a exfiltração de dados confidenciais do plano de controle.
  • Ataques de borda da malha. Ataques destinados a adulterar, escutar ou spoofing da comunicação na entrada ou saída da malha.
  • Ataques de operação de malha Ataques direcionados às operações da malha. Os invasores podem tentar conseguir privilégios elevados para realizar operações maliciosas em uma malha, como a modificação de políticas de segurança e de imagens de carga de trabalho.

Riscos de segurança

Além dos ataques de segurança, a malha também enfrenta outros riscos. A lista a seguir descreve alguns possíveis riscos de segurança:

  • Proteção de segurança incompleta. Uma malha de serviço não foi configurada com políticas de autenticação e autorização para proteger a segurança. Por exemplo, nenhuma política de autenticação ou autorização é definida para serviços em uma malha.
  • Exceções à política de segurança. Para acomodar os casos de uso específicos, os usuários podem criar exceções da política de segurança para determinado tráfego (interno ou externo) a ser excluído das políticas de segurança do Cloud Service Mesh. Para lidar com esses casos com segurança, consulte a seção Gerenciar exceções às políticas com segurança.
  • Negligência nos upgrades de imagem. É possível descobrir vulnerabilidades para as imagens usadas em uma malha. É necessário manter o componente da malha e as imagens da carga de trabalho atualizados com as correções de vulnerabilidades mais recentes.
  • Falta de manutenção (sem experiência ou recursos); O software da malha e as configurações da política precisam de manutenção regular para aproveitar os mecanismos de proteção de segurança mais recentes.
  • Falta de visibilidade. Configuração incorreta ou não segura de políticas de malha e tráfego/operações de malha anormal não são atraídos pelos administradores da malha.
  • Deslocamento de configuração. A configuração das políticas em uma malha é diferente da fonte de verdade.

Medidas para proteger uma malha de serviço

Esta seção apresenta um manual operacional para proteger as malhas de serviço.

Arquitetura de segurança

A segurança da malha de serviço depende da segurança dos componentes em diferentes camadas do sistema da malha e dos aplicativos dela. A intenção de alto nível da postura de segurança proposta pelo Cloud Service Mesh é proteger uma malha de serviço pela integração de vários mecanismos de segurança em diferentes camadas, o que junta a segurança geral do sistema com a segurança de confiança zero. O diagrama a seguir mostra a postura de segurança proposta da Cloud Service Mesh.

postura de segurança do Cloud Service Mesh

O Cloud Service Mesh oferece segurança em várias camadas, incluindo:

  • Segurança de borda da malha
    • A segurança de entrada do Cloud Service Mesh fornece controle de acesso para tráfego externo e protege o acesso externo às APIs expostas pelos serviços na malha.
    • A segurança de saída do Cloud Service Mesh regula o tráfego de saída de cargas de trabalho internas.
    • A autenticação de usuário do Cloud Service Mesh é integrada à infraestrutura do Google para autenticar chamadas externas de navegadores da Web para os serviços que executam aplicativos da Web.
    • O gerenciamento de certificados de gateway do Cloud Service Mesh protege e alterna as chaves privadas e os certificados X.509 usados pelos gateways de entrada e saída do Cloud Service Mesh usando o Certificate Authority Service.
    • O Cloud Armor pode se proteger contra ataques de negação de serviço (DDoS) distribuídos e ataques de camada 7 externos. Ele serve como um firewall de aplicativos da Web (WAF) para proteger a malha de ataques de rede. Por exemplo, ataques de injeção e de execução de código remoto.
    • A VPC e o VPC Service Controls protegem a borda da malha por meio dos controles de acesso à rede privada.
  • Segurança do cluster
    • O TLS mútuo (mTLS) do Cloud Service Mesh aplica a criptografia e a autenticação de tráfego de carga de trabalho para carga de trabalho.
    • A AC gerenciada, como a autoridade certificadora do Cloud Service Mesh e Certificate Authority Service, provisiona e gerencia com segurança os certificados usados pelas cargas de trabalho.
    • A autorização do Cloud Service Mesh aplica o controle de acesso para serviços de malha com base em identidades e outros atributos.
    • O painel de segurança do GKE Enterprise oferece monitoramento das configurações de políticas de segurança e políticas de rede do Kubernetes para as cargas de trabalho.
    • A Política de rede do Kubernetes aplica o controle de acesso do pod com base em endereços IP, rótulos de pod, namespaces e muito mais.
    • A segurança do plano de controle protege contra ataques. Essa proteção impede que invasores modifiquem, explorem ou vazem dados de configuração e malha de serviço.
  • Segurança da carga de trabalho
    • Mantenha-se atualizado com as versões de segurança do Cloud Service Mesh para garantir que os binários do Cloud Service Mesh em execução na malha não tenham vulnerabilidades conhecidas publicamente.
    • A federação de identidade da carga de trabalho para o GKE permite que as cargas de trabalho recebam credenciais para chamar os serviços do Google com segurança.
    • O Cloud Key Management Service (Cloud KMS) protege dados confidenciais ou credenciais usando módulos de segurança de hardware (HSM). Por exemplo, as cargas de trabalho podem usar o Cloud KMS para armazenar credenciais ou outros dados confidenciais. O serviço de CA, usado para emitir certificados para cargas de trabalho da malha, é compatível com chaves de assinatura compatíveis com cliente e HSM gerenciadas pelo Cloud KMS.
    • A interface de rede de contêiner (CNI, na sigla em inglês) do Kubernetes evita ataques de escalonamento de privilégios, eliminando a necessidade de um contêiner iniciado privilegiado do Cloud Service Mesh.
  • Segurança do operador
    • O controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes restringe o acesso aos recursos do Kubernetes e limita as permissões do operador para reduzir ataques causados por operadores mal-intencionados ou falsificação de identidade.
    • O GKE Enterprise Policy Controller valida e audita configurações de política na malha para evitar configurações incorretas.
    • A autorização binária do Google Cloud garante que as imagens de carga de trabalho na malha sejam as autorizadas pelos administradores.
    • Os registros de auditoria do Google Cloud auditam operações da malha.

O diagrama abaixo mostra os fluxos de comunicação e configuração com as soluções de segurança integradas no Cloud Service Mesh.

fluxo de tráfego do diagrama de segurança

Segurança do cluster

Ativar o TLS mútuo rigoroso

Um ataque "man-in-the-middle" (MitM) tenta inserir uma entidade mal-intencionada entre duas partes que se comunicam para espionar ou manipular a comunicação. O Cloud Service Mesh protege contra ataques de MitM e exfiltração de dados aplicando a autenticação e criptografia mTLS para todas as partes que estão se comunicando. O modo permissivo usa mTLS quando os dois lados são compatíveis, mas permite conexões sem mTLS. Já o mTLS rigoroso exige que o tráfego seja criptografado e autenticado com mTLS, mas não permite o uso de texto simples.

Para mais informações, consulte Cloud Service Mesh por exemplo: mTLS | Aplicação de mTLS na malha inteira.

Ativar controles de acesso

As políticas de segurança do Cloud Service Mesh (como políticas de autenticação e autorização) precisam ser aplicadas em todo o tráfego dentro e fora da malha, a menos que haja fortes justificativas para excluir um serviço ou pod das políticas de segurança do Cloud Service Mesh. Em alguns casos, os usuários podem ter motivos legítimos para ignorar as políticas de segurança do Cloud Service Mesh para algumas portas e intervalos de IP. Por exemplo, para estabelecer conexões nativas com serviços não gerenciados pelo Cloud Service Mesh. Para proteger o Cloud Service Mesh nesses casos de uso, consulte Gerenciar as exceções de política do Cloud Service Mesh com segurança.

O controle de acesso aos serviços é fundamental para impedir o acesso não autorizado a eles. A aplicação de mTLS criptografa e autentica uma solicitação, mas uma malha ainda precisa de políticas de autorização do Cloud Service Mesh para aplicar o controle de acesso aos serviços. Por exemplo, rejeitando uma solicitação não autorizada proveniente de um cliente autenticado.

As políticas de autorização do Cloud Service Mesh oferecem uma maneira flexível de configurar controles de acesso para proteger seus serviços contra acesso não autorizado. As políticas de autorização do Cloud Service Mesh precisam ser aplicadas com base nas identidades autenticadas derivadas dos resultados da autenticação. As autenticações baseadas em mTLS ou JSON Web Token (JWT) precisam ser usadas juntas como parte das políticas de autorização do Cloud Service Mesh.

Aplicar políticas de autenticação do Cloud Service Mesh

JSON Web Token (JWT)

Além da autenticação mTLS, os administradores da malha podem exigir que um serviço autentique e autorize solicitações com base no JWT. O Cloud Service Mesh não atua como um provedor JWT, mas autentica JWTs com base nos endpoints configurados do conjunto de chaves da Web JSON (JWKS, na sigla em inglês). A autenticação JWT pode ser aplicada a gateways de entrada para tráfego externo ou a serviços internos para tráfego na malha. A autenticação JWT pode ser combinada com a autenticação mTLS quando um JWT é usado como uma credencial para representar o autor da chamada final e o serviço solicitado exige prova de que ele está sendo chamado em nome do autor da chamada final. A aplicação da autenticação JWT protege contra ataques que acessam um serviço sem credenciais válidas e em nome de um usuário final real.

Autenticação de usuário do Cloud Service Mesh

A autenticação do usuário do Cloud Service Mesh é uma solução integrada para autenticação e controle de acesso do usuário final baseada em navegador para as cargas de trabalho. Ele integra uma malha de serviço aos provedores de identidade (IDP) existentes para implementar um fluxo padrão de login e consentimento do OpenID Connect (OIDC) e usa políticas de autorização do Cloud Service Mesh para controle de acesso.

Aplicar políticas de autorização

Controle de políticas de autorização do Cloud Service Mesh:

  • Quem ou o que tem permissão para acessar um serviço.
  • Quais recursos podem ser acessados.
  • Quais operações podem ser realizadas nos recursos permitidos.

As políticas de autorização são uma forma versátil de configurar o controle de acesso com base nas identidades reais usadas pelos serviços, nas propriedades de camada de aplicativo (camada 7) do tráfego (por exemplo, cabeçalhos de solicitação) e na camada de rede (camada 3 e camada 4), como intervalos de IP e portas.

As políticas de autorização do Cloud Service Mesh precisam ser aplicadas com base nas identidades autenticadas derivadas dos resultados da autenticação, para se protegerem contra o acesso não autorizado a serviços ou dados.

Por padrão, o acesso a um serviço é negado, a menos que uma política de autorização seja explicitamente definida para permitir acesso ao serviço. Consulte Práticas recomendadas da política de autorização para ver exemplos de políticas de autorização que negam solicitações de acesso.

As políticas de autorização devem restringir a confiança o máximo possível. Por exemplo, o acesso a um serviço pode ser definido com base em caminhos de URL individuais expostos por um serviço, de modo que somente um serviço A possa acessar o caminho /admin de um serviço B.

As políticas de autorização podem ser usadas com as Políticas de rede do Kubernetes, que operam apenas na camada de rede (camada 3 e Camada 4) e controlam o acesso à rede para endereços IP e portas nos pods e namespaces do Kubernetes.

Aplicar a troca de tokens para acessar serviços de malha

Para se proteger contra ataques de repetição de token que roubam tokens e reutilizam os tokens roubados para acessar serviços de malha, um token em uma solicitação de fora da malha precisa ser trocado por um token interno de malha de curta duração na borda da malha.

Uma solicitação de fora da malha para acessar um serviço de malha precisa incluir um token, como JWT ou cookie, para que ela seja autenticada e autorizada pelo serviço da malha. Um token de fora da malha pode ter longa duração. Para se proteger contra ataques de repetição de token, um token de fora da malha precisa ser trocado por um token interno da malha de curta duração com escopo limitado na entrada da malha. O serviço de malha autentica um token interno da malha e autoriza a solicitação de acesso com base no token interno da malha.

O Cloud Service Mesh oferece suporte à integração com o Identity-Aware Proxy (IAP), que gera um RequestContextToken (um token interno da malha de curta duração trocado de um token externo) usado no Cloud Service Mesh para autorização. Com a troca de tokens, os invasores não podem usar um token roubado na malha para acessar os serviços. O escopo e a vida útil limitados do token trocado reduzem muito a chance de um ataque de repetição do token.

Lidar com segurança com exceções de política do Cloud Service Mesh

Talvez você tenha casos de uso especiais para a malha de serviço. Por exemplo, talvez seja necessário expor uma determinada porta de rede para o tráfego de texto simples. Para acomodar cenários de uso específicos, às vezes pode ser necessário criar exceções para permitir que determinado tráfego interno ou externo seja excluído das políticas de segurança do Cloud Service Mesh, o que cria preocupações de segurança.

Você pode ter motivos legítimos para ignorar as políticas de segurança do Cloud Service Mesh em algumas portas e intervalos de IP. É possível adicionar annotations (como excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) aos pods para excluir o tráfego do processamento do arquivo secundário do Envoy. Além das anotações para excluir o tráfego, é possível ignorar a malha ao implantar um aplicativo com a injeção de arquivo secundário desativada. Por exemplo, adicionando um rótulo sidecar.istio.io/inject="false" ao pod do aplicativo.

Ignorar as políticas de segurança do Cloud Service Mesh tem um impacto negativo na segurança geral do sistema. Por exemplo, se as políticas de autorização e mTLS do Cloud Service Mesh forem ignoradas por uma porta de rede por meio de anotações, não haverá controle de acesso para o tráfego na porta e a espionagem ou modificação do tráfego poderá ser possível. Além disso, ignorar as políticas do Cloud Service Mesh também afeta políticas que não são de segurança, como as políticas de rede.

Quando a política de segurança do Cloud Service Mesh é ignorada para uma porta ou IP (intencionalmente ou não), há outras medidas de segurança em vigor para proteger a malha e monitorar exceções de segurança, possíveis brechas de segurança e o status geral da aplicação da segurança. Para proteger sua malha nesses cenários, faça o seguinte:

  • Verifique se o tráfego que ignora os arquivos secundários é criptografado e autenticado nativamente para evitar ataques de MitM.
  • Aplicar políticas de rede do Kubernetes para limitar a conectividade de portas com exceções de políticas (por exemplo, limitar uma porta com exceções de políticas para permitir apenas o tráfego de outro serviço no mesmo namespace) ou para permitir apenas o tráfego que passa pelas portas com a política de segurança do Cloud Service Mesh aplicada.
  • Aplique o GKE Enterprise Policy Controller para validar automaticamente as políticas do Cloud Service Mesh. Por exemplo, aplique que os arquivos secundários do Cloud Service Mesh sejam sempre injetados em cargas de trabalho.

Aplicar políticas de rede do Kubernetes

O Cloud Service Mesh se baseia na plataforma subjacente (por exemplo, o Kubernetes). Assim, a segurança do Cloud Service Mesh depende da segurança da plataforma subjacente. Por exemplo, sem controle sobre quem pode atualizar os recursos do Kubernetes, um usuário pode alterar a implantação do Kubernetes de um serviço para ignorar o arquivo secundário do serviço.

Para formar uma postura de segurança sólida para uma malha de serviço, é preciso aplicar os mecanismos de segurança da plataforma subjacente para funcionar em conjunto com as políticas de segurança do Cloud Service Mesh.

As políticas de rede do Kubernetes operam na camada de rede (L3 e L4) para endereços IP e portas em pods e namespaces do Kubernetes. As políticas de rede do Kubernetes podem ser aplicadas em conjunto com as políticas do Cloud Service Mesh para aumentar a segurança da malha.

Por exemplo, o administrador da malha pode configurar as políticas de rede do Kubernetes para permitir apenas o tráfego para usar portas com a política de segurança do Cloud Service Mesh aplicada. Se todo o tráfego precisar ser aplicado com a mTLS do Cloud Service Mesh, o administrador vai poder configurar uma política de rede do Kubernetes para permitir apenas o tráfego nas portas que estão configuradas com a política do mTLS do Cloud Service Mesh. O administrador da malha também pode configurar as políticas de rede do Kubernetes para limitar a conectividade das portas com exceções de políticas. Por exemplo, limite a conectividade dessas portas a um namespace.

Proteger o acesso ao plano de controle

O plano de controle do Cloud Service Mesh autentica todos os clientes que se conectam. Assim, somente autores de chamada com credenciais válidas (certificados JWT do Kubernetes ou X.509 emitidos por ACs permitidas) podem acessar o plano de controle do Cloud Service Mesh. O TLS criptografa as conexões entre cargas de trabalho e o plano de controle do Cloud Service Mesh.

Além do mecanismo de autenticação, para o Cloud Service Mesh no cluster, as políticas de rede do Kubernetes podem ser implantadas para isolar o namespace do sistema do Cloud Service Mesh (por padrão, istio-system) de namespaces não gerenciados e clientes fora da malha, permitindo que os planos de dados acessem o plano de controle. As regras de firewall da VPC podem impedir que o tráfego fora de um cluster chegue ao Istiod. Com essas medidas de isolamento de rede, um invasor de fora da malha não poderá acessar o plano de controle, mesmo se ele tiver uma credencial válida. Para planos de controle gerenciados, o Google gerencia a segurança dos planos de controle e essas políticas de isolamento de rede para planos de controle não são necessárias.

Aplicar limites de namespace

Para impedir que um usuário de um namespace acesse/atualize recursos em um namespace não autorizado:

Aplicar políticas de RBAC do Kubernetes

Os administradores da malha precisam aplicar políticas do RBAC do Kubernetes para controlar quem tem permissão para acessar e atualizar recursos do Kubernetes. O controle de acesso do Kubernetes pode reduzir os riscos de segurança na malha. Por exemplo, usuários não autorizados não podem alterar as implantações do Kubernetes e ignorar as restrições da política do Cloud Service Mesh. Os papéis de um usuário precisam estar vinculados a um namespace. Assim, ele não poderá acessar mais namespaces do que precisa. Para guias detalhados e exemplos de como configurar o RBAC, consulte Configurar o controle de acesso baseado em papéis. Depois de ativar a Federação de Identidade da Carga de Trabalho para o GKE, também é possível permitir que uma conta de serviço do Kubernetes atue como uma conta de serviço do IAM.

Segurança de borda da malha

Como a maioria dos ataques também pode se originar de fora de um cluster, é essencial garantir a segurança na borda da malha.

Controle de acesso de entrada do cluster

O Cloud Service Mesh recebe o tráfego externo de entrada por meio do gateway de entrada. Os serviços expostos pelo gateway de entrada podem sofrer ataques de fontes externas. Os administradores de segurança sempre precisam garantir que os serviços expostos ao tráfego externo por meio de gateways de entrada sejam seguros o suficiente para proteger contra ataques.

O recurso de entrada precisa exigir autenticação e autorização para serviços expostos a autores de chamadas externos.

  • Aplicar políticas de segurança de entrada do cluster. Quando o cluster precisa receber tráfego externo, o administrador da malha precisa aplicar políticas de segurança de entrada, incluindo a autenticação e as políticas de autorização do gateway TLS do Cloud Service Mesh, para autenticar solicitações externas e verificar se elas estão autorizadas a acessar os serviços expostos pelo gateway de entrada. A aplicação de políticas de segurança de entrada protege contra ataques de fora da malha que tentam acessar um serviço sem credenciais ou permissões válidas.
  • Use o Cloud Armor para atuar como um firewall de aplicativos da Web (WAF) e se defender de ataques baseados na Web (por exemplo, ataques de injeção e execução remota). Para mais informações, consulte De borda a malha: como expor aplicativos da malha de serviço usando a Entrada do GKE.

Controlar o tráfego de saída do cluster

A segurança de saída do cluster é essencial para a segurança da malha porque as políticas de segurança de saída podem se defender contra ataques de exfiltração de dados, aplicar filtros de tráfego de saída e aplicar o início de TLS ao tráfego de saída. Os administradores de segurança precisam controlar e auditar o tráfego de saída do cluster.

Além de usar paredes de firewall da VPC para restringir o tráfego de saída, os administradores da malha também precisam aplicar políticas de segurança de saída ao cluster e configurar o tráfego de saída para passar por gateways de saída.

As políticas de saída podem atenuar os seguintes ataques:

  • Ataques de exfiltração de dados;
  • Os pods de serviço podem ser explorados por invasores se as CVEs não forem corrigidas. Os pods comprometidos podem se tornar um botnet controlado por invasores para enviar spam ou lançar ataques DoS.

As políticas de autorização aplicadas a gateways de saída podem garantir que apenas serviços autorizados tenham permissão para enviar tráfego para hosts específicos fora da malha. Enquanto isso, para o tráfego que sai da malha, em vez de processar o início de de TLS em arquivos secundários, o TLS pode ser originado em gateways de saída. Isso proporciona uma maneira uniforme e mais segura de originar o tráfego TLS porque os certificados do cliente para mTLS podem ser isolados dos namespaces em que os aplicativos são executados.

Usar o cluster privado ou o VPC Service Control para bloquear acessos externos

Além de aplicar as políticas de segurança de entrada e saída, bloqueie o acesso externo usando o cluster particular ou o VPC Service Controls sempre que possível. Embora as políticas de segurança sejam controladas pelos administradores de segurança da malha, a configuração do cluster particular ou o VPC Service Controls pode ser aplicado pelos administradores de segurança da organização.

O VPC Service Controls pode ser aplicado para definir um perímetro de segurança para os serviços com o objetivo de:

  • Restringir o acesso de serviços a recursos externos.
  • Impedir que usuários externos acessem os serviços em um perímetro de segurança.

O VPC Service Controls ajuda na defesa contra ataques de exfiltração de dados e impede que invasores externos acessem serviços dentro de uma malha.

Defesa contra ataques DDoS externos

Os ataques DDoS externos podem sobrecarregar gateways de entrada e serviços de back-end, impedindo o processamento de solicitações legítimas. O Cloud Armor pode ser usado para proteção contra ataques DDoS. O Cloud Armor se protege não só contra ataques de DDoS de camada de rede (L3 e L4), mas também contra ataques DDoS da camada de aplicativo (L7).

Segurança para administração e automação de malha

É importante considerar a segurança para operações administrativas e qualquer automação criada em torno da malha, por exemplo, CI/CD. As práticas a seguir buscam garantir que a malha possa ser operada com segurança sem o risco de expor serviços a outros ataques.

Segmentar os papéis usados para operações de malha

Seguindo o mesmo princípio do controle de acesso baseado em papéis, os usuários de uma malha precisam ser classificados de acordo com os papéis deles. Cada papel precisa receber apenas o conjunto mínimo de privilégios necessários para ele.

Por exemplo, o conjunto de usuários que fazem implantações de serviço não pode ter privilégios para atualizar políticas de autenticação e autorização.

Há diferentes categorias de operadores. Por exemplo, operadores de cluster e de namespace. É importante evitar o escalonamento de privilégios de um operador, o que pode resultar em acesso ilícito a recursos não autorizados.

As políticas de RBAC do Kubernetes permitem que os administradores da malha limitem o acesso aos recursos apenas para usuários autorizados.

Validar automaticamente as configurações de políticas

Os operadores podem configurar acidentalmente as políticas do Cloud Service Mesh, o que pode resultar em incidentes de segurança graves. Para evitar a configuração incorreta e validar automaticamente as políticas do Cloud Service Mesh, os administradores da malha podem usar o Policy Controller para aplicar restrições às configurações de políticas.

Para evitar muita confiança em indivíduos com permissões para atualizar as políticas de segurança do Cloud Service Mesh e automatizar a validação das políticas do Cloud Service Mesh, os administradores da malha devem implementar restrições nas políticas do Cloud Service Mesh usando o Policy Controller.

O Policy Controller é baseado no projeto de código aberto Gatekeeper e pode ser executado como controlador de admissão do Kubernetes para negar a aplicação de recursos inválidos ou no modo de auditoria para que os administradores possam ser alertados sobre violações. O Policy Controller pode validar automaticamente a implantação de recursos na malha, como validar que as anotações em uma implantação não ignoram as políticas do Cloud Service Mesh, validar que as políticas do Cloud Service Mesh estão conforme o esperado e validar que uma implantação não inclui recursos raiz, como NET_ADMIN e NET_RAW.

O Policy Controller também pode auditar os recursos atuais do Cloud Service Mesh em relação às restrições para detectar configurações incorretas da política.

Veja a seguir alguns exemplos do GKE Enterprise Policy Controller que aplica políticas de segurança:

A biblioteca de modelos de restrição fornecida com o Policy Controller contém um conjunto de modelos de restrição que podem ser usados com o pacote de restrições de segurança do Cloud Service Mesh para aplicar práticas recomendadas de segurança específicas do Cloud Service Mesh, por exemplo, autenticação, autorização e políticas de tráfego. Veja a seguir alguns exemplos de restrições incluídos no pacote:

  • Aplique o PeerAuthentication strict mTLS no nível da malha.
  • A aplicação de todos os PeerAuthentications não pode substituir mTLS rígidos.
  • Aplique a política de negação de autorização padrão no nível da malha.
  • Aplicar os padrões seguros da política de autorização.
  • Aplique os arquivos secundários do Cloud Service Mesh sempre injetados nas cargas de trabalho.

Para gerenciar exceções e casos de acesso imediato, o administrador da malha pode:

Usar uma abordagem de GitOps com o Config Sync para evitar desvios de configuração

O deslocamento de configuração ocorre quando a configuração de políticas em uma malha se desvia da fonte de verdade. O Config Sync pode ser usado para evitar desvios de configuração.

Aplicar o registro de auditoria e o monitoramento

Os administradores da malha devem monitorar o seguinte:

Esses recursos de observabilidade podem ser usados para verificar se a configuração de segurança está funcionando conforme o esperado e monitorar quaisquer exceções à aplicação da política de segurança. Por exemplo, acesso que não passou por arquivos secundários, acesso que não tinha credenciais válidas, mas alcançou um serviço.

Embora o software de observabilidade de código aberto (por exemplo, Prometheus) possa ser usado com o Cloud Service Mesh, é altamente recomendável usar o pacote de operações do Google Cloud (antigo Stackdriver). A solução de observabilidade integrada do Google Cloud fornece geração de registros, coleta de métricas, monitoramento e alertas, que é totalmente gerenciada e fácil de usar.

Proteger a autoridade de certificação para certificados no cluster

Por padrão, o Cloud Service Mesh usa uma autoridade de certificação (AC) gerenciada pelo Google chamada autoridade de certificação do Cloud Service Mesh.

Se você estiver usando a autoridade de certificação (CA, na sigla em inglês) não gerenciada do Istio, que é hospedada como parte do Istiod, a chave de assinatura da CA é armazenada em um secret do Kubernetes e pode ser acessada pelos operadores que têm acesso ao recurso de secret no namespace istio-system. Esse é um risco, já que um operador pode usar a chave da CA de forma independente da CA do Istiod e possivelmente assinar certificados de carga de trabalho de maneira independente. Também há o risco de vazamento acidental de uma chave de assinatura de CA autogerenciada devido a um erro operacional.

Para proteger a chave de assinatura de CA, o administrador da malha pode fazer upgrade da malha para usar a CA da malha ou o serviço de autoridade de certificação (serviço de CA), que são protegidos e gerenciados pelo Google (como o . Rotação de chaves da CA). Em comparação com a CA da malha, o serviço de CA é compatível com chaves de assinatura baseadas em HSM por cliente por meio do Cloud KMS respaldado pelo Cloud HSM.

Segurança de cargas de trabalho

A segurança da carga de trabalho protege contra ataques que comprometem os pods da carga de trabalho e usam os pods comprometidos para iniciar ataques ao cluster (por exemplo, ataques de botnet).

Restringir privilégios do pod

Um pod do Kubernetes pode ter privilégios que afetam outros pods no nó ou no cluster. É importante aplicar restrições de segurança aos pods de carga de trabalho para evitar que um pod comprometido inicie ataques no cluster.

Para aplicar o princípio de privilégio mínimo às cargas de trabalho em um pod, faça o seguinte:

  • Os serviços implantados em uma malha precisam ser executados com o mínimo de privilégios possível.
  • Os pods do Kubernetes em execução no modo privilegiado podem manipular pilhas de rede e outros recursos do kernel no host. O GKE Enterprise Policy Controller pode ser usado para impedir que os pods executem contêineres privilegiados.
  • O Cloud Service Mesh pode ser configurado para usar um contêiner de inicialização para configurar o redirecionamento de tráfego do iptables para o sidecar. Isso exige que o usuário que faz as implantações de carga de trabalho tenha privilégios para implantar contêineres com os recursos NET_ADMIN e NET_RAW. Para evitar o risco de executar contêineres com privilégios elevados, os administradores da malha podem ativar o plug-in CNI do Istio para configurar o redirecionamento de tráfego para sidecars.

Imagens seguras de contêiner

Os invasores podem lançar ataques explorando imagens vulneráveis de contêineres. Os administradores devem aplicar a autorização binária para verificar a integridade das imagens de contêiner e garantir que apenas imagens de contêiner confiáveis sejam implantadas na malha.

Reduza as vulnerabilidades da malha

  • Container Analysis. O Container Analysis pode verificar e mostrar vulnerabilidades nas cargas de trabalho do GKE.
  • Gerenciamento de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). Depois que uma vulnerabilidade é descoberta em uma imagem de contêiner, os administradores da malha precisam corrigir a vulnerabilidade o mais rápido possível. Para o Cloud Service Mesh gerenciado com plano de dados gerenciado, o Google processa automaticamente as CVEs que corrigem as imagens que afetam as imagens da malha.

Usar a federação de identidade da carga de trabalho do GKE para acessar os serviços do Google com segurança

A Federação de identidade da carga de trabalho para GKE é a maneira recomendada para que as cargas de trabalho da malha acessem com segurança os serviços do Google. A alternativa de armazenar uma chave de conta de serviço em um secret do Kubernetes e usar essa chave para acessar os serviços do Google não é tão segura devido aos riscos de: vazamento de credenciais, escalonamento de privilégios, divulgação de informações e não repúdio;

Monitorar o status de segurança com o painel de segurança e a telemetria

Uma malha de serviço pode ter exceções de segurança e possíveis brechas. É importante mostrar e monitorar o status de segurança de uma malha, o que inclui as políticas de segurança aplicadas, exceções de segurança e possíveis brechas de segurança na malha. O painel de segurança do GKE Enterprise e a telemetria podem ser usados para exibir e monitorar o status de segurança da malha.

A telemetria monitora a integridade e o desempenho de serviços em uma malha. Isso permite que os administradores da malha observem os comportamentos dos serviços (como SLOs, tráfego anormal, interrupção de serviço e topologia).

O painel de segurança do GKE Enterprise analisa e visualiza as políticas de segurança aplicadas a uma carga de trabalho em uma malha de serviço, incluindo políticas de controle de acesso (políticas de rede do Kubernetes, políticas de autorização binária e políticas de controle de acesso a serviços) e políticas de autenticação (mTLS).

Segurança para dados e credenciais confidenciais do usuário

Os dados ou credenciais confidenciais do usuário podem estar vulneráveis a ataques de pods ou operações maliciosas se forem armazenados no armazenamento permanente do cluster, como usar secrets do Kubernetes ou diretamente em pods. Elas também se tornarão vulneráveis a ataques de rede se forem transferidas pela rede para autenticação em serviços.

  • Se possível, armazene dados e credenciais confidenciais do usuário em um armazenamento protegido, como o Secret Manager e o Cloud KMS.
  • Designe namespaces separados para pods do Kubernetes que acessam dados confidenciais e definir políticas do Kubernetes para torná-los inacessíveis a partir de outros namespaces. Segmente os papéis usados para operações e aplique limites de namespace.
  • Aplique a troca de tokens para evitar a exfiltração de tokens de longa duração e altamente privilegiados.

A seguir