Alibaba Cloud Service Mesh:Visão geral da segurança zero trust

Contexto

Os microsserviços oferecem diversos benefícios, incluindo escalabilidade, agilidade, dimensionamento independente, isolamento de lógica de negócios, gerenciamento de ciclo de vida independente e desenvolvimento distribuído simplificado. No entanto, essa arquitetura distribuída também introduz desafios de segurança, pois cada microsserviço se torna um alvo potencial de ataque. O Kubernetes fornece uma excelente plataforma para hospedar e orquestrar microsserviços. Porém, por padrão, toda a comunicação entre eles é insegura. A troca de dados ocorre via HTTP em texto simples, o que não atende aos requisitos modernos de segurança. Confiar apenas no perímetro de rede para proteção é insuficiente. Se um serviço interno for comprometido, um invasor poderá se mover lateralmente para atacar outros serviços dentro da rede. Portanto, o tráfego interno também deve ser protegido. Esse é o valor da segurança zero trust. Um modelo zero trust exige verificação explícita para cada solicitação e aplica o princípio do menor privilégio para restringir o acesso aos recursos.

Um benefício essencial da tecnologia de Service Mesh é sua capacidade de proteger ambientes de produção sem reduzir a produtividade dos desenvolvedores. O Service Mesh fornece a base para adotar uma abordagem de segurança zero trust para microsserviços. Essa abordagem ajuda você a alcançar objetivos de segurança, como autenticação forte de identidade, autorização baseada em contexto e registro e monitoramento abrangentes para todos os acessos. Ao utilizar esses recursos do mesh, é possível aplicar controles de segurança a todas as aplicações dentro dele. Por exemplo, garanta que todo o tráfego seja criptografado e que todo o tráfego de entrada nas aplicações seja verificado por um ponto de aplicação de política (PEP).

Além das políticas de rede do Kubernetes para segurança na Camada 3, o ASM fornece autenticação de pares, autenticação de solicitações, políticas de autorização do Istio e políticas refinadas da OPA. Essas capacidades de segurança zero trust no ASM ajudam você a atingir seus objetivos de segurança.

Por que usar o ASM para implementar zero trust

Com o ASM, use um único plano de controle para implementar gerenciamento forte de identidade e acesso, criptografia TLS transparente, autenticação, autorização e logs de auditoria. Sua instalação e gerenciamento simples permitem que desenvolvedores, administradores de sistemas e equipes de segurança protejam suas aplicações de microsserviços.

Uso do sistema zero trust do ASM

O ASM reduz a superfície de ataque em ambientes nativos da nuvem e fornece a estrutura fundamental para uma rede de aplicações zero trust. Ao gerenciar a segurança de serviço para serviço, o ASM garante criptografia de ponta a ponta, autenticação no nível de serviço e políticas de autorização refinadas.

O ASM fornece capacidades fundamentais de segurança zero trust, incluindo identidade de carga de trabalho, autenticação de pares, autenticação de solicitações, políticas de autorização e políticas da OPA.

Identidade da carga de trabalho

Quando uma aplicação é executada em um ambiente ASM, o ASM fornece uma identidade exclusiva para cada serviço. Essa identidade de serviço pode ser usada para autenticação mútua, verificação de acesso entre serviços e em políticas de autorização.

Ao usar o ASM para gerenciar cargas de trabalho em execução no Kubernetes, o ASM fornece uma identidade de serviço para cada carga de trabalho. Essa identidade é baseada no token da conta de serviço da carga de trabalho.

As identidades de serviço no ASM estão em conformidade com o padrão SPIFFE e usam o seguinte formato: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

Faça login no console do ASM para visualizar os serviços conectados a partir de um cluster Kubernetes.

1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

2. Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha Mesh Security Center > Workload Identity.

3. Na página Workload Identity, defina Data Plane como o ID do cluster e selecione um Namespaces para visualizar as identidades de carga de trabalho dos serviços do cluster Kubernetes adicionados ao service mesh.

Autenticação de pares

O ASM fornece dois tipos de autenticação: autenticação de pares e autenticação de solicitações. A autenticação de pares usa TLS mútuo para autenticar os pares quando dois microsserviços interagem.

• Se tanto o cliente quanto o servidor tiverem um proxy sidecar injetado, a comunicação mTLS será habilitada por padrão no ASM.

• Se apenas o cliente tiver um proxy sidecar injetado, o cliente decide se deve usar comunicação mTLS com base na configuração do servidor.

• Se apenas o servidor tiver um proxy sidecar injetado, o modo mTLS padrão será PERMISSIVE, que aceita tráfego em texto simples e criptografado. Se você configurar uma política PeerAuthentication para o servidor e definir o modo mTLS como STRICT, as solicitações falharão.

Autenticação de solicitações

A autenticação de solicitações permite que usuários finais e sistemas interajam com microsserviços. Isso geralmente é feito usando um JSON Web Token (JWT).

Quando um microsserviço recebe uma solicitação, crie uma política de autenticação de solicitações para validar JWT nas solicitações recebidas. A política valida solicitações que contêm um JWT. Apenas solicitações com um JWT válido podem acessar o serviço com sucesso. Solicitações sem JWT não são validadas e podem acessar o serviço sem restrições.

1. Implante a aplicação bookinfo que receberá as solicitações. Para obter mais informações, consulte Implantar uma aplicação em um cluster associado a uma instância do ASM.

2. Implante a aplicação sleep que enviará as solicitações.

   1. No ambiente KubeConfig do seu cluster ACK, crie um arquivo sleep.yaml.

      Arquivo Sleep.yaml

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: sleep
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: sleep
        labels:
          app: sleep
          service: sleep
      spec:
        ports:
        - port: 80
          name: http
        selector:
          app: sleep
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sleep
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: sleep
        template:
          metadata:
            labels:
              app: sleep
          spec:
            terminationGracePeriodSeconds: 0
            serviceAccountName: sleep
            containers:
            - name: sleep
              image: curlimages/curl
              command: ["/bin/sleep", "3650d"]
              imagePullPolicy: IfNotPresent
              volumeMounts:
              - mountPath: /etc/sleep/tls
                name: secret-volume
            volumes:
            - name: secret-volume
              secret:
                secretName: sleep-secret
                optional: true
      ---

   2. Execute o comando a seguir para implantar a aplicação sleep.

      kubectl apply -f sleep.yaml -n default 

3. Crie uma política de autenticação de solicitações para impor a autenticação JWT para solicitações de entrada no serviço details.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha Mesh Security Center > RequestAuthentication. Na página exibida, clique em Create.

   3. Na página de criação, defina os seguintes parâmetros e clique em Create para definir uma regra JWT para a carga de trabalho details.

      Selecione o namespace default, defina o nome como test e adicione um seletor de rótulos com o nome app e o valor details.

      A descrição a seguir detalha alguns dos parâmetros:

      • issuer: O emissor do JWT. Para este exemplo, defina como testing@secure.istio.io.

      • audiences: Uma lista de públicos-alvo para o JWT. Isso especifica quais serviços podem usar o JWT para acessar o serviço de destino. Para este exemplo, deixe em branco, significando que o acesso não é restrito a nenhum serviço específico.

      • jwks: O JSON Web Key Set (JWKS) para o JWT. Para este exemplo, use o seguinte JWKS. Para obter mais informações, consulte jwks.json.

        { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

4. Para gerar o token usado na próxima etapa, utilize uma ferramenta JWT. O token deve ser criado usando uma chave privada que corresponda à chave pública no JWKS e incluir o emissor testing@secure.istio.io.

   { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

   O token esperado é:

   eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

5. Verifique se a política de autenticação de solicitações está em vigor.

   1. Execute o comando a seguir para acessar o serviço details usando o JWT codificado.

      export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'        

      Um código de status 200 é retornado, indicando acesso bem-sucedido.

   2. Execute o comando a seguir para acessar o serviço details usando um JWT inválido.

      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'                              

      Um código de status 403 é retornado, indicando que o acesso falhou.

   3. Execute o comando a seguir para acessar o serviço details sem um JWT.

      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

      Um código de status 200 é retornado, indicando acesso bem-sucedido.

      Esses resultados mostram que solicitações com um JWT válido têm sucesso, solicitações com um JWT inválido falham e solicitações sem JWT têm sucesso. Isso confirma que a política de autenticação de solicitações está funcionando conforme o esperado.

Política de autorização

Quando um microsserviço recebe uma solicitação, use uma política de autorização para restringir o acesso com base na porta da solicitação, endereço IP, origem, entre outros. Apenas solicitações que atendem aos requisitos podem acessar o serviço. A política de autorização a seguir restringe o acesso com base na origem da solicitação, exigindo que a solicitação contenha um JWT de um emissor específico.

1. Implante a aplicação bookinfo que receberá as solicitações. Para obter mais informações, consulte Implantar uma aplicação em um cluster associado a uma instância do ASM.

2. Implante a aplicação sleep que enviará as solicitações.

   1. Crie um arquivo sleep.yaml com o seguinte conteúdo.

      Arquivo Sleep.yaml

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: sleep
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: sleep
        labels:
          app: sleep
          service: sleep
      spec:
        ports:
        - port: 80
          name: http
        selector:
          app: sleep
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sleep
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: sleep
        template:
          metadata:
            labels:
              app: sleep
          spec:
            terminationGracePeriodSeconds: 0
            serviceAccountName: sleep
            containers:
            - name: sleep
              image: curlimages/curl
              command: ["/bin/sleep", "3650d"]
              imagePullPolicy: IfNotPresent
              volumeMounts:
              - mountPath: /etc/sleep/tls
                name: secret-volume
            volumes:
            - name: secret-volume
              secret:
                secretName: sleep-secret
                optional: true
      ---

   2. No ambiente KubeConfig do seu cluster ACK, execute o comando a seguir para implantar a aplicação sleep.

      kubectl apply -f sleep.yaml -n default 

3. Crie uma política de autorização.

   1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

   2. Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha Mesh Security Center > AuthorizationPolicy. Na página exibida, clique em Create from YAML.

4. Na página Create, selecione o namespace default, insira o YAML a seguir e clique em Create.

   Para obter mais informações sobre os campos, consulte Política de Autorização.

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: default
   spec:
     action: ALLOW
     rules:
       - from:
           - source:
               requestPrincipals:
                 - testing@secure.istio.io/testing@secure.istio.io
     selector:
       matchLabels:
         app: details

5. Execute o comando a seguir para enviar uma solicitação sem JWT para acessar o serviço.

    kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

   Saída esperada:

   403

   A solicitação para o serviço details sem JWT falha, o que confirma que a política de autorização está em vigor. A política exige que todas as solicitações contenham um JWT emitido por testing@secure.istio.io para acessar o serviço com sucesso.

Política da OPA

A OPA é um mecanismo de políticas que permite o controle de acesso refinado para suas aplicações. Como um mecanismo de políticas de uso geral, a OPA pode ser implantada como um serviço independente ao lado dos seus microsserviços. Para proteger uma aplicação, cada solicitação a um microsserviço deve ser autorizada antes de ser processada. O microsserviço consulta a API da OPA para determinar se a solicitação deve ser permitida. Para obter mais informações, consulte OPA.

O ASM integra um plug-in da OPA, que permite definir políticas de controle de acesso usando a OPA para obter controle de acesso refinado para suas aplicações. Essas políticas da OPA também podem ser atualizadas dinamicamente. Para obter mais informações, consulte Atualizar dinamicamente políticas da OPA no ASM.

Resumo e casos de uso

Em resumo, o ASM fornece os seguintes componentes de aprimoramento de segurança:

• Uma infraestrutura de certificados gerenciada com gerenciamento completo do ciclo de vida de certificados que simplifica a emissão de certificados e a rotação de CA.

• APIs de plano de controle gerenciadas para distribuir políticas de autenticação, políticas de autorização e informações de nomenclatura segura para proxies Envoy.

• Proxies sidecar que atuam como um ponto de aplicação de política (PEP) para ajudar a proteger o mesh.

• Extensões de proxy Envoy que habilitam a coleta de telemetria e auditoria.

Cada carga de trabalho usa um certificado X.509 TLS para estabelecer sua identidade. Esse certificado é então usado pelo proxy sidecar da carga de trabalho. O ASM fornece e rotaciona periodicamente esses certificados e chaves privadas. Se uma chave privada for comprometida, o ASM poderá substituí-la rapidamente por uma nova, reduzindo significativamente a superfície de ataque.

Casos de uso

• Utilize uma política de autorização em um gateway de entrada para implementar controle de acesso baseado em IP ou controle de acesso baseado em um autorizador externo personalizado.

• Um cliente do setor financeiro precisava gerenciar permissões de acesso para aplicações multilíngues em vários clusters. Eles usaram políticas de autorização do ASM para isolar zonas voltadas para o exterior das zonas internas de aplicações. Em combinação com um gateway de saída para auditar o tráfego do mesh, eles também usaram políticas de autorização para controlar o acesso das aplicações a serviços de terceiros.