Este documento descreve as práticas recomendadas para estabelecer e governar Malha de serviço do Cloud em execução no Google Kubernetes Engine (GKE). As orientações na vai além das configurações usadas para configurar e instalar o Cloud Service Mesh e descreve como é possível usar o Cloud Service Mesh com outros e recursos para se proteger contra as ameaças de segurança que os aplicativos em uma malha.
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
- Veículos de ataque e riscos de segurança
- Medidas para proteger uma malha de serviço
- Arquitetura de segurança
- Segurança do cluster
- Segurança de borda da malha
- Segurança para automação e administração de malha
- Segurança da carga de trabalho
- Segurança para credenciais e dados confidenciais do usuário
Introdução
O Cloud Service Mesh oferece recursos e ferramentas que ajudam a observar, gerenciar e serviços seguros 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 oferece controle declarativo sobre a rede comportamento, o que ajuda a dissociar o trabalho das equipes responsáveis entregando e lançando recursos de aplicativos das responsabilidades administradores responsáveis pela segurança e pela rede.
O Cloud Service Mesh é baseado no sistema de gerenciamento Malha de serviço do Istio, 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, configurações personalizadas ou para conceder exceções excluindo determinados aplicativos, portas ou endereços IP de 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 confiança zero, que pressupõe as ameaças à segurança vêm de dentro e de fora do ambiente perímetro de segurança. 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 à política de segurança para determinados tráfegos (internos ou externas) sejam excluídas 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 análise de alto nível da postura de segurança proposta do Cloud Service Mesh é proteger um serviço malha por meio da integração de vários mecanismos de segurança em diferentes camadas, o que para garantir a segurança geral do sistema no modelo de confiança zero. O diagrama a seguir mostra a postura de segurança proposta 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 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 cargas de trabalho internas.
- Autenticação de usuário do Cloud Service Mesh integra-se à infraestrutura do Google para autenticar chamadas externas desde navegadores da Web até serviços que executam aplicativos da Web.
- Gerenciamento de certificados de gateway do Cloud Service Mesh as chaves privadas e os certificados X.509 usados pelo 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 do Cloud Service Mesh (mTLS) aplica o tráfego entre cargas de trabalho criptografia e autenticação.
- CA gerenciada, como a autoridade certificadora do Cloud Service Mesh e Certificate Authority Service, que 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 aos serviços da malha com base na identidade e em 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 sua malha não têm restrições de conhecimento público vulnerabilidades.
- A Identidade da carga de trabalho 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 CNI (interface de rede do contêiner) do Kubernetes impede privilégios ataques de escalonamento, eliminando a necessidade de uma organização Contêiner init 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 os soluções de segurança integradas no Cloud Service Mesh.
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 exfiltração de dados e MitM aplicando Autenticação e criptografia mTLS para todas as partes que se comunicam. 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 | Como aplicar mTLS em toda a malha.
Ativar controles de acesso
Políticas de segurança do Cloud Service Mesh (como autenticação e autorização ) precisam ser aplicadas a todo o tráfego que entra e sai da malha, a menos que haja são justificativas sólidas para excluir um serviço ou pod do Cloud Service Mesh e políticas de segurança da organização. Em alguns casos, os usuários podem ter motivos legítimos para ignorar 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 o Cloud Service Mesh seguro nesses casos de uso, consulte Gerencie com segurança as exceções de políticas do Cloud Service Mesh.
O controle de acesso de serviço é fundamental para evitar acessos não autorizados serviços. A aplicação do mTLS criptografa e autentica uma solicitação, mas uma malha necessidades 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 fornecem uma maneira flexível de configurar o acesso controles de segurança para proteger os serviços contra acesso não autorizado. Malha de serviço do Cloud as políticas de autorização precisam ser aplicadas com base nas identidades autenticadas derivados dos resultados da autenticação: com base em mTLS ou JSON Web Token (JWT) as autenticações precisam ser usadas em conjunto como parte da autorização do Cloud Service Mesh políticas.
Aplique 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 no endpoints do conjunto de chaves da Web JSON (JWKS, na sigla em inglês) configurados. 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
Autenticação de usuário do Cloud Service Mesh é uma solução integrada para autenticação e acesso do usuário final baseado no navegador para as cargas de trabalho. Ele integra uma malha de serviço com os recursos Provedores (IdP) para implementar um login padrão do OpenID Connect (OIDC) baseado na Web e fluxo de consentimento e usa as políticas de autorização do Cloud Service Mesh para acesso controle
As políticas de autorização do Cloud Service Mesh controlam:
- 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 no identidades derivadas dos resultados da autenticação para defesa contra 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 de malha de curta duração
trocada de um token externo) usada 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.
Processar com segurança exceções da 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 de uso, pode ser necessário criar exceções para permitir que determinados tráfego interno ou externo a ser excluído da segurança do Cloud Service Mesh e políticas de segurança, o que cria problemas de segurança.
Você pode ter motivos legítimos para ignorar as políticas de segurança do Cloud Service Mesh por
algumas portas e intervalos de IP. Você pode adicionar
anotações
(por exemplo, excludeInboundPorts
, excludeOutboundPorts
,
excludeOutboundIPRanges
) aos pods para impedir que o tráfego seja processado pelo
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 segurança do sistema. Por exemplo, se o mTLS e as políticas de autorização do Cloud Service Mesh sejam ignorados para uma porta de rede por meio de anotações, não haverá controle do tráfego na porta e espionagem ou modificação do tráfego possíveis. Além disso, ignorar as políticas do Cloud Service Mesh também afeta que não sejam de segurança, como as de rede.
Quando a política de segurança do Cloud Service Mesh é ignorada para uma porta ou IP ( intencionalmente ou não), é preciso haver outras medidas de segurança para proteger a malha e monitorar exceções de segurança, possíveis brechas e o status geral de 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ítica (por exemplo, limitar uma porta com exceções de políticas para permitir apenas serviço no mesmo namespace) ou permitir apenas que o tráfego passe pelo e portas com a política de segurança do Cloud Service Mesh aplicada.
- Aplique o Policy Controller do GKE Enterprise para valide automaticamente as políticas do Cloud Service Mesh. Por exemplo, faça com que os arquivos secundários do Cloud Service Mesh sejam sempre injetados no do Google Cloud.
Aplicar políticas de rede do Kubernetes
O Cloud Service Mesh se baseia na plataforma de base (por exemplo, Kubernetes). Assim, a segurança do Cloud Service Mesh depende da segurança dos componentes de plataforma. 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 forte para uma malha de serviço, os mecanismos de segurança a plataforma subjacente deve ser aplicada para trabalhar em conjunto com o Cloud Service Mesh e políticas de segurança da organização.
Políticas de rede do Kubernetes operar na camada de rede (L3 e L4) para endereços IP e portas pods e namespaces do Kubernetes. As políticas de rede do Kubernetes podem ser aplicadas conjunto com as políticas do Cloud Service Mesh para aumentar a segurança da malha.
Por exemplo, o administrador da malha pode configurar políticas de rede do Kubernetes para só permitir que o tráfego use portas com a política de segurança do Cloud Service Mesh aplicada. Se todo o tráfego precisar ser aplicado com o mTLS do Cloud Service Mesh, o administrador poderá uma política de rede do Kubernetes para permitir apenas o tráfego nas portas configurada com a política 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 os clientes que se conectam. Assim, somente autores de chamadas com credenciais válidas (certificados Kubernetes JWT ou X.509 emitidos por ACs permitidas) podem acessar o plano de controle do Cloud Service Mesh. O TLS criptografa 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, o Kubernetes É possível implantar políticas de rede para isolar o namespace do sistema do Cloud Service Mesh (por padrão, istio-system) de namespaces e clientes não gerenciados fora do e permite 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 pelo Google, 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 controles de acesso.
- Aplicar políticas de rede do Kubernetes. Se os serviços em um namespace não tiverem tráfego fora do namespace, o administrador da malha precisará implantar uma política de rede do Kubernetes que só permita o tráfego dentro do namespace: sem entrada ou saída do namespace.
- Aplicar políticas de RBAC do Kubernetes.
- Os papéis dos administradores de aplicativos precisam estar vinculados a um namespace.
- Permite que apenas administradores da malha tenham o ClusterRole.
Aplicar políticas de RBAC do Kubernetes
Os administradores da malha precisam aplicar Políticas de RBAC do Kubernetes para controlar quem tem permissão para acessar e atualizar os 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 devem ter permissão para 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 Identidade da carga de trabalho, 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 tráfego externo pelo 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 precisar receber tráfego externo, o administrador da malha deve aplicar a segurança de entrada políticas, incluindo o Cloud Service Mesh TLS do gateway e políticas de autorização para autenticar dados externos e verificar se as solicitações externas têm autorização para acessar serviços exposto 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 incorretamente as políticas do Cloud Service Mesh por acidente, o que pode resultar em caso de incidentes de segurança graves. Para evitar erros de configuração e criar validar as políticas do Cloud Service Mesh, os administradores de malha podem usar Policy Controller (link em inglês) para aplicar restrições nas configurações de políticas.
Para evitar confiar demais em indivíduos com permissões para fazer atualizações. Políticas de segurança do Cloud Service Mesh e para automatizar a validação do Cloud Service Mesh os administradores da malha precisam implementar restrições no Cloud Service Mesh políticas usando 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 valida automaticamente a implantação
na malha, por exemplo, ao validar se as anotações em uma implantação
não ignore as políticas do Cloud Service Mesh, validando se essas políticas são
como esperado e validando 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 contra restrições para detectar políticas de configuração.
Veja a seguir alguns exemplos do GKE Enterprise Policy Controller que aplica políticas de segurança:
- Evita que os pods executem contêineres privilegiados.
- Só permite o uso de imagens de repositórios específicos para impedir a execução de imagens de contêiner não autorizadas.
- Proíbe a desativação do TLS para todos os hosts e subconjuntos de hosts no Istio DestinationRules.
- Impede que principais e namespaces nas regras de AuthorizationPolicy do Istio tenham um prefixo de uma lista especificada.
- Proíbe a criação de recursos conhecidos que expõem cargas de trabalho a IPs externos.
- Exige que os recursos do Ingress sejam somente HTTPS.
- Exige um sistema de arquivos raiz somente leitura no contêiner.
A Biblioteca de modelos de restrição fornecidos com o Policy Controller contém um conjunto de modelos de restrição ser usado com a solução pronta para uso 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, a autenticação, a autorização e as políticas de tráfego. Veja a seguir alguns exemplos de restrições incluídos no pacote:
- Aplicar o nível da rede mesh mTLS rigorosa PeerAuthentication.
- A aplicação de todos os PeerAuthentications não pode substituir mTLS rígidos.
- Aplicar o nível da rede mesh negação padrão AuthorizationPolicy.
- Aplicar os padrões seguros da política de autorização.
- aplicar 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:
- Exclua um namespace da aplicação do webhook de admissão do Policy Controller, mas todas as violações ainda serão informadas na auditoria.
- Defina a Constraint.enforcementAction como dryrun. O webhook de admissão não impede alterações, mas as violações ainda são informadas na auditoria.
- Adicione uma lógica de isenção ao modelo de restrição (exemplo).
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:
- Cloud Audit Logging
- Registros de auditoria do Cloud Service Mesh
- Registro de auditoria de restrição de política
- Configuração do Anthos Config
- Registros de acesso
- Métricas de nível de serviço
- Como acessar traces
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 um software de observabilidade de código aberto (por exemplo, Prometheus) pode ser usado com o Cloud Service Mesh, é altamente recomendável usar 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 (CA, na sigla em inglês) 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 init. Redirecionamento de tráfego do iptables para o arquivo secundário. 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 Plug-in CNI do Istio para configurar o redirecionamento de tráfego para arquivos secundários.
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 Cloud Service Mesh gerenciado pelo Google com Plano de dados gerenciado pelo Google, O Google lida automaticamente com a correção de CVEs que afetam as imagens da malha.
Usar a Identidade da carga de trabalho para acessar os serviços do Google com segurança
A Identidade da carga de trabalho é 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
- Revise as práticas recomendadas para usar gateways de saída do Cloud Service Mesh em clusters do GKE
- Configurar a segurança de transporte
- Atualize suas políticas de autorização