Alibaba Cloud Service Mesh:Negar tráfego de saída de um namespace para um site externo

Casos de uso

• Auditoria centralizada de saída: Roteie todo o tráfego de saída por um único gateway de saída para registro em log e aplicação de políticas.

• Controle de acesso no escopo do namespace: Permita ou negue acesso a sites externos com base no namespace de origem ou na identidade do serviço.

• Defesa em profundidade: Adicione autorização no nível da aplicação sobre o Kubernetes NetworkPolicy para garantir segurança de saída com confiança zero.

Como funciona

O tráfego flui por três componentes:

1. Proxy sidecar -- Intercepta requisições de saída das cargas de trabalho e as encaminha para o gateway de saída.

2. Gateway de saída -- Funciona como ponto de saída centralizado onde as políticas de autorização são avaliadas.

3. Política de autorização -- Regra DENY no gateway de saída que bloqueia requisições originadas no namespace demo-frontend.

Workload (demo-frontend) --> Sidecar proxy --> Egress gateway --> External website
                                                    |
                                          Authorization policy
                                            (DENY applied here)

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster adicionado à instância ASM. Para mais informações, consulte Adicionar um cluster a uma instância ASM

• Um namespace chamado demo-frontend com injeção automática de proxy sidecar ativada. Para mais informações, consulte Gerencie namespaces globais

Etapa 1: Implantar um serviço de teste

Implante um serviço sleep no namespace demo-frontend como carga de trabalho de teste para verificar o controle de tráfego de saída.

1. Obtenha o arquivo kubeconfig e conecte-se ao cluster com kubectl. Para mais informações, consulte Obter o arquivo kubeconfig de um cluster e usar kubectl para conectar-se ao cluster.

2. Crie um arquivo chamado sleep.yaml com o seguinte conteúdo:

   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

3. Aplique o arquivo:

      kubectl apply -f sleep.yaml -n demo-frontend

4. Verifique se um proxy sidecar foi injetado no pod sleep:

   1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

   2. Na página Clusters, clique no nome do cluster desejado. No painel de navegação à esquerda, escolha Workloads > Pods.

   3. Na página Pods, selecione demo-frontend na lista suspensa Namespace e clique no nome do pod do serviço sleep.

   4. Na aba Container, confirme a presença de um contêiner chamado istio-proxy. Isso confirma a injeção do proxy sidecar.

Etapa 2: Crie um gateway de saída

Um gateway de saída centraliza o tráfego de saída para que as políticas de autorização possam controlar quais namespaces ou serviços acessam endpoints externos.

Crie um gateway de saída chamado egressgateway. Para obter instruções, consulte Criar um gateway de saída.

Etapa 3: Restringir o tráfego de saída apenas a serviços registrados

Por padrão, os serviços em uma instância ASM podem acessar todos os endpoints externos. Para impor controle de saída, altere a política de tráfego de saída para REGISTRY_ONLY. Após essa alteração, apenas os serviços externos registrados como entradas de serviço estarão acessíveis.

Etapa 4: Roteare o tráfego pelo gateway de saída

Crie um gateway Istio, uma regra de destino e um serviço virtual para rotear o tráfego do namespace demo-frontend pelo gateway de saída até www.aliyun.com.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTPS
      tls:
        mode: ISTIO_MUTUAL
      hosts:
        - '*'

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: demo-frontend
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
    - name: target-egress-gateway-mTLS
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
        tls:
          mode: ISTIO_MUTUAL

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: demo-frontend
spec:
  exportTo:
    - istio-system
    - demo-frontend
  gateways:
    - mesh
    - istio-system/istio-egressgateway
  hosts:
    - www.aliyun.com
  http:
    - match:
        - gateways:
            - mesh
          port: 80
      route:
        - destination:
            host: istio-egressgateway.istio-system.svc.cluster.local
            port:
              number: 80
            subset: target-egress-gateway-mTLS
          weight: 100
    - match:
        - gateways:
            - istio-system/istio-egressgateway
          port: 80
      route:
        - destination:
            host: www.aliyun.com
            port:
              number: 80
          weight: 100

Etapa 5: Crie uma política de autorização

Aplique uma política de autorização DENY no gateway de saída para bloquear todo o tráfego do namespace demo-frontend.

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

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

3. Na página Create, configure os seguintes parâmetros:

   Parâmetro	Valor
   Name	Um nome para a política de autorização
   Policy Type	DENY
   ASM Gateway	Na aba Gateway Scope, selecione egressgateway
   Request Matching Rules	Na seção Add Request Source, ative Namespaces e defina o valor como demo-frontend

4. Clique em Create.

Quando várias políticas de autorização têm como alvo a mesma carga de trabalho, o Istio as avalia nesta ordem: CUSTOM > DENY > ALLOW. Uma requisição que corresponda a uma política DENY é rejeitada independentemente de quaisquer políticas ALLOW. Se não existirem políticas ALLOW, todas as requisições não negadas são permitidas por padrão.

Etapa 6: Verifique a política de autorização

Confirme que os serviços no namespace demo-frontend não conseguem mais acessar www.aliyun.com.

1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do cluster desejado. No painel de navegação à esquerda, escolha Workloads > Pods.

3. Na página Pods, selecione demo-frontend na lista suspensa Namespace. Localize o nome do pod do serviço sleep e clique em Terminal > sleep na coluna Actions.

4. Execute o comando a seguir. Saída esperada: A resposta 403 Forbidden confirma que a política de autorização bloqueia o tráfego de saída do namespace demo-frontend para www.aliyun.com. O cabeçalho server: envoy confirma a aplicação pelo proxy Envoy do gateway de saída.

      curl -I http://www.aliyun.com

      HTTP/1.1 403 Forbidden
      content-length: 19
      content-type: text/plain
      date: Thu, 12 Oct 2023 07:14:09 GMT
      server: envoy
      x-envoy-upstream-service-time: 4

Considerações de segurança

As políticas de autorização impõem controle de saída por meio de proxies sidecar e do gateway de saída. Observe as seguintes limitações:

• Desvio do sidecar: Se uma carga de trabalho contornar seu proxy sidecar (por exemplo, um pod privilegiado sem injeção de sidecar), ela poderá acessar serviços externos diretamente sem passar pelo gateway de saída. A política de autorização não se aplica ao tráfego desviado.

• Medidas complementares: Para impedir que o tráfego saia do mesh sem passar pelo gateway de saída, adicione imposição no nível de infraestrutura. Use objetos Kubernetes NetworkPolicy ou regras de firewall para negar todo o tráfego de saída que não se origine do gateway de saída.

Tópicos relacionados

• Criar um gateway de saída

• Gerencie gateways Istio

• Gerencie regras de destino

• Gerencie serviços virtuais

• Gerencie namespaces globais