How to restrict specific IP addresses from accessing applications in an ASM instance - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Pré-requisitos

Instância do ASM versão v1.15.3.25 ou posterior com um cluster adicionado. Consulte Adicionar um cluster a uma instância do ASM.
Injeção automática de proxy sidecar ativada. Consulte Ativar a injeção automática de proxy sidecar.
Aplicação HTTPBin implantada e acessível. Consulte Implantar a aplicação HTTPBin.

Como funciona

Uma AuthorizationPolicy com a ação DENY bloqueia requisições correspondentes aos endereços IP especificados. Dois campos de origem determinam qual IP é avaliado:

**ipBlocks**: Compara com o endereço IP do par que estabelece diretamente a conexão TCP com o proxy (downstream_remote_address).
**remoteIpBlocks**: Compara com o IP original do cliente, geralmente extraído do cabeçalho X-Forwarded-For.

Escolha entre ipBlocks ou remoteIpBlocks

O campo correto depende de como o IP do cliente chega ao proxy:

Caminho do tráfego	Origem do IP do cliente	Campo a ser usado
Cliente conectado diretamente ao gateway do ASM (sem proxy de camada 7)	Endereço de origem do pacote	`ipBlocks` ou `remoteIpBlocks` (ambos funcionam)
Proxy de camada 7 entre o cliente e o gateway do ASM	Cabeçalho `X-Forwarded-For`	`remoteIpBlocks`

Aplicação no gateway versus sidecar

As políticas aplicadas no gateway e no proxy sidecar comportam-se de maneira diferente, pois cada proxy vê um valor distinto para downstream_remote_address:

Ponto de aplicação	Valor de `downstream_remote_address`	Comportamento de `ipBlocks`
Gateway (namespace `istio-system`, seletor `istio: ingressgateway`)	IP real do cliente (com porta válida)	Corresponde ao IP real do cliente
Proxy sidecar (namespace `default`, seletor `app: <workload>`)	IP do cliente inferido de `X-Forwarded-For` (a porta é `0`)	Não corresponde ao IP do cliente, pois a origem TCP real é o IP do pod do gateway

Como o proxy sidecar recebe tráfego do pod do gateway e não diretamente do cliente, ipBlocks no sidecar corresponde ao IP do pod do gateway. Para filtrar pelo IP do cliente no nível do sidecar, use remoteIpBlocks.

Observações de uso

Os exemplos a seguir definem o campo externalTrafficPolicy do gateway como Local. Se externalTrafficPolicy estiver definido como Cluster, os endereços IP de origem não serão preservados e o controle de acesso baseado em IP não funcionará conforme o esperado.

Negar um IP no gateway (sem proxy de camada 7)

Quando o cliente se conecta diretamente ao gateway do ASM sem um proxy intermediário de camada 7, os campos downstream_remote_address e x_forwarded_for nos logs do gateway refletem o IP real do cliente. Tanto ipBlocks quanto remoteIpBlocks funcionam para controle de acesso baseado em IP.

Execute o comando a seguir para verificar a conectividade com a aplicação HTTPBin:

curl <gateway-external-ip>:80/ -I

Exemplo de log do gateway

{
    "downstream_remote_address": "106.XX.XX.1:58656",
    "x_forwarded_for": "106.11.XX.X",
    "response_code": "200",
    "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local",
    "user_agent": "curl/7.88.1"
}

Os campos downstream_remote_address e x_forwarded_for contêm o IP real do cliente (106.11.XX.X).

Exemplo de log do proxy sidecar

{
    "downstream_remote_address": "106.11.XX.X:0",
    "x_forwarded_for": "106.11.XX.X",
    "response_code": "200",
    "upstream_cluster": "inbound|80||",
    "user_agent": "curl/7.88.1"
}

O campo x_forwarded_for exibe o IP real do cliente. O campo downstream_remote_address também mostra o IP do cliente, mas a porta é 0 porque as informações de porta são perdidas no nível do sidecar.

Negar um IP usando ipBlocks

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy. Substitua <client-ip> pelo endereço IP a ser bloqueado.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test
      namespace: istio-system
    spec:
      action: DENY
      rules:
        - from:
            - source:
                ipBlocks:
                  - <client-ip>  # Example: 106.11.XX.X
      selector:
        matchLabels:
          istio: ingressgateway

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```

Verifique a política enviando uma requisição. Saída esperada: Uma resposta 403 Forbidden confirma que o IP está bloqueado.

    curl <gateway-external-ip>:80/ -I

    HTTP/1.1 403 Forbidden
    content-length: 19
    content-type: text/plain
    server: istio-envoy

Negar um IP usando remoteIpBlocks

A única diferença em relação à abordagem com ipBlocks é o campo de origem na AuthorizationPolicy. O campo remoteIpBlocks avalia o cabeçalho X-Forwarded-For em vez da origem direta da conexão TCP.

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test
      namespace: istio-system
    spec:
      action: DENY
      rules:
        - from:
            - source:
                remoteIpBlocks:
                  - <client-ip>  # Example: 106.11.XX.X
      selector:
        matchLabels:
          istio: ingressgateway

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```

Verifique a política. Saída esperada:

    curl <gateway-external-ip>:80/ -I

    HTTP/1.1 403 Forbidden
    content-length: 19
    content-type: text/plain
    server: istio-envoy

Negar um IP no proxy sidecar

Quando a política tem como alvo o proxy sidecar em vez do gateway, ipBlocks e remoteIpBlocks apresentam comportamentos diferentes.

Por que ipBlocks não corresponde ao IP do cliente no sidecar

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy:

Nota

O namespace é default e o seletor tem como alvo a carga de trabalho httpbin, não o gateway de entrada.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test
      namespace: default
    spec:
      action: DENY
      rules:
        - from:
            - source:
                ipBlocks:
                  - <client-ip>  # Example: 106.11.XX.X
      selector:
        matchLabels:
          app: httpbin

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```
Verifique a política. Saída esperada: A requisição é bem-sucedida com 200 OK porque o proxy sidecar vê o IP do pod do gateway em downstream_remote_address, e não o IP do cliente. O campo ipBlocks compara com a origem da conexão TCP direta, que é o pod do gateway. Para bloquear tráfego no nível do sidecar usando ipBlocks, especifique o IP do pod do gateway em vez do IP do cliente. Para filtragem por IP do cliente no sidecar, use remoteIpBlocks.
```
    curl <gateway-external-ip>:80/ -I
```
```
    HTTP/1.1 200 OK
    server: istio-envoy
    content-type: text/html; charset=utf-8
```

Negar um IP no sidecar usando remoteIpBlocks

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test
      namespace: default
    spec:
      action: DENY
      rules:
        - from:
            - source:
                remoteIpBlocks:
                  - <client-ip>  # Example: 106.11.XX.X
      selector:
        matchLabels:
          app: httpbin

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```
Verifique a política. Saída esperada: A configuração remoteIpBlocks bloqueia a requisição porque avalia o cabeçalho X-Forwarded-For, que contém o IP real do cliente.
```
    curl <gateway-external-ip>:80/ -I
```
```
    HTTP/1.1 403 Forbidden
    content-length: 19
    content-type: text/plain
    server: istio-envoy
```

Negar um IP quando há um proxy de camada 7 entre o cliente e o gateway

Quando um ou mais proxies de camada 7 (como um balanceador de carga ou CDN) estão entre o cliente e o gateway do ASM, o cabeçalho X-Forwarded-For contém vários endereços IP. Cada proxy anexa o IP do salto anterior.

Nesse cenário, apenas remoteIpBlocks é relevante para o controle de acesso baseado em IP. O campo ipBlocks corresponde ao IP físico do par, que é o proxy de camada 7, e não o cliente.

Exemplo de log do gateway

{
    "downstream_remote_address": "106.11.XX.X:62232",
    "x_forwarded_for": "56.5.X.X, 72.9.X.X, 98.1.X.X, 106.11.XX.X",
    "response_code": "200",
    "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local"
}

O cabeçalho x_forwarded_for contém quatro endereços IP:

56.5.X.X, 72.9.X.X, 98.1.X.X -- definidos pelos proxies de camada 7 upstream antes de chegar ao gateway do ASM.
106.11.XX.X -- anexado pelo próprio gateway do ASM.

O campo downstream_remote_address (106.11.XX.X:62232) mostra o IP do par que se conecta diretamente ao gateway (o último proxy de camada 7).

Exemplo de log do proxy sidecar

{
    "downstream_remote_address": "106.11.XX.X:0",
    "x_forwarded_for": "56.5.X.X, 72.9.X.X, 98.1.X.X, 106.11.XX.X",
    "response_code": "200",
    "upstream_cluster": "inbound|80||"
}

O valor de x_forwarded_for é idêntico ao do log do gateway. O campo downstream_remote_address corresponde ao último IP na cadeia x_forwarded_for (a porta é 0 porque as informações de porta não são preservadas no nível do sidecar).

Negar o último IP em X-Forwarded-For no gateway

Por padrão (numTrustedProxies = 0), remoteIpBlocks avalia o último endereço IP anexado ao cabeçalho X-Forwarded-For pelo gateway. Este é o IP do par que se conecta diretamente ao gateway.

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test-ap-wg-gateway-test-istio-system-gateway-ingressgateway
      namespace: istio-system
    spec:
      action: DENY
      rules:
        - from:
            - source:
                remoteIpBlocks:
                  - <last-proxy-ip>  # Example: 106.11.XX.X
      selector:
        matchLabels:
          istio: ingressgateway

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```

Verifique a política. Saída esperada:

    curl <gateway-external-ip>:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

    HTTP/1.1 403 Forbidden
    content-length: 19
    content-type: text/plain
    server: istio-envoy

Usar numTrustedProxies para atingir um IP específico na cadeia X-Forwarded-For

A configuração numTrustedProxies controla qual endereço IP na cadeia X-Forwarded-For será avaliado por remoteIpBlocks. Quando definido como N, o gateway trata os N proxies mais próximos dele como confiáveis e avalia o IP do (N+1)º proxy a partir da direita.

Por exemplo, com X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X e o gateway anexando 106.11.XX.X:

numTrustedProxies	Proxies confiáveis (da direita)	IP avaliado por remoteIpBlocks
0 (padrão)	Nenhum	`106.11.XX.X` (último IP, anexado pelo gateway)
2	`106.11.XX.X`, `98.1.X.X`	`72.9.X.X` (terceiro a partir da direita)

Defina numTrustedProxies no gateway de entrada

Adicione a anotação a seguir ao campo spec do arquivo YAML do gateway de entrada. Para obter instruções sobre como editar a configuração do gateway de entrada, consulte Gerenciar o gateway de entrada no console do ASM.

podAnnotations:
    proxy.istio.io/config: '{"gatewayTopology" : { "numTrustedProxies": 2 } }'

Aviso

Esta configuração reinicia os pods do gateway.

Após a reinicialização do gateway, verifique o efeito:

curl <gateway-external-ip>:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

Saída esperada:

HTTP/1.1 200 OK
server: istio-envoy
content-type: text/html; charset=utf-8

A requisição é bem-sucedida porque numTrustedProxies: 2 faz com que remoteIpBlocks avalie 72.9.X.X (o terceiro IP a partir da direita) em vez de 106.11.XX.X. Como 72.9.X.X não está na lista de negação, a requisição é permitida.

Negar o IP avaliado após definir numTrustedProxies

Com numTrustedProxies definido como 2, crie uma política que negue o IP avaliado por remoteIpBlocks:

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test-ap-wg-gateway-test-istio-system-gateway-ingressgateway
      namespace: istio-system
    spec:
      action: DENY
      rules:
        - from:
            - source:
                remoteIpBlocks:
                  - 72.9.X.X
      selector:
        matchLabels:
          istio: ingressgateway

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```

Verifique a política. Saída esperada:

    curl <gateway-external-ip>:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

    HTTP/1.1 403 Forbidden
    content-length: 19
    content-type: text/plain
    server: istio-envoy

Aplicar a política ao proxy sidecar em vez do gateway

A configuração numTrustedProxies definida no gateway não se aplica aos proxies sidecar. Os proxies sidecar usam o valor padrão de numTrustedProxies igual a 0, o que significa que remoteIpBlocks avalia o último IP na cadeia X-Forwarded-For recebida pelo sidecar.

Crie um arquivo chamado gateway-test.yaml com a seguinte AuthorizationPolicy direcionada ao sidecar do HTTPBin:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: gateway-test
      namespace: default
    spec:
      action: DENY
      rules:
        - from:
            - source:
                remoteIpBlocks:
                  - 72.9.X.X
      selector:
        matchLabels:
          app: httpbin

Implante a política de autorização:
```
    kubectl apply -f gateway-test.yaml
```
Verifique a política. Saída esperada: A requisição é bem-sucedida porque o numTrustedProxies do sidecar é 0, então remoteIpBlocks avalia o último IP na cadeia X-Forwarded-For (106.11.XX.X). Como 72.9.X.X não é o último IP, a regra de negação não é acionada. Para negar 72.9.X.X no nível do sidecar, defina numTrustedProxies também no proxy sidecar ou altere o valor de remoteIpBlocks para corresponder ao IP que o sidecar avalia (o último IP no cabeçalho X-Forwarded-For).
```
    curl <gateway-external-ip>:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I
```
```
    HTTP/1.1 200 OK
    server: istio-envoy
    content-type: text/html; charset=utf-8
```

Próximos passos

Criar um gateway de entrada -- Configure e gerencie gateways de entrada do ASM.
Políticas de segurança do ASM -- Explore opções adicionais de controle de acesso, incluindo políticas de segurança gerenciadas pelo ASM que simplificam a configuração da AuthorizationPolicy.