Anotações para o Application Gateway Ingress Controller

2025-06-13

Você pode anotar o recurso de entrada do Kubernetes com pares arbitrários de chave/valor. O controlador de ingresso do Application Gateway (AGIC) depende de anotações para programar recursos do Azure Application Gateway que não são configuráveis por meio do YAML Ingress. As anotações de ingresso são aplicadas a todas as configurações HTTP, pools de back-end e escutadores derivados de um recurso de ingresso.

Sugestão

Considere o Application Gateway for Containers para sua solução de ingresso do Kubernetes. Para obter mais informações, consulte Guia de início rápido: implantar o Application Gateway for Containers ALB Controller.

Lista de anotações suportadas

Para que a AGIC observe um recurso de entrada, o recurso deve ser anotado com kubernetes.io/ingress.class: azure/application-gateway.

Chave de anotação	Tipo de valor	Valor padrão	Valores permitidos
appgw.ingress.kubernetes.io/backend-path-prefix	`string`	`nil`
appgw.ingress.kubernetes.io/backend-hostname	`string`	`nil`
appgw.ingress.kubernetes.io/health-probe-hostname	`string`	`127.0.0.1`
appgw.ingress.kubernetes.io/health-probe-port	`int32`	`80`
appgw.ingress.kubernetes.io/health-probe-path	`string`	`/`
appgw.ingress.kubernetes.io/health-probe-status-codes	`string`	`200-399`
appgw.ingress.kubernetes.io/health-probe-interval	`int32`	`30` (segundos)
appgw.ingress.kubernetes.io/health-probe-timeout	`int32`	`30` (segundos)
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold	`int32`	`3`
appgw.ingress.kubernetes.io/ssl-redirect	`bool`	`false`
appgw.ingress.kubernetes.io/connection-draining	`bool`	`false`
appgw.ingress.kubernetes.io/connection-draining-timeout	`int32` (segundos)	`30`
appgw.ingress.kubernetes.io/use-private-ip	`bool`	`false`
appgw.ingress.kubernetes.io/override-frontend-port	`bool`	`false`
appgw.ingress.kubernetes.io/cookie-based-affinity	`bool`	`false`
[appgw.ingress.kubernetes.io/request-timeout]
(#request-tempo limite)	`int32` (segundos)	`30`
appgw.ingress.kubernetes.io/use-private-ip	`bool`	`false`
appgw.ingress.kubernetes.io/backend-protocol	`string`	`http`	`http`, `https`
appgw.ingress.kubernetes.io/hostname-extension	`string`	`nil`
appgw.ingress.kubernetes.io/waf-policy-for-path	`string`	`nil`
appgw.ingress.kubernetes.io/appgw-ssl-certificate	`string`	`nil`
appgw.ingress.kubernetes.io/appgw-ssl-profile	`string`	`nil`
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate	`string`	`nil`
appgw.ingress.kubernetes.io/rewrite-rule-set	`string`	`nil`
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
appgw.ingress.kubernetes.io/rule-priority	`int32`	`nil`

Prefixo do caminho de back-end

A seguinte anotação permite reescrever o caminho de backend especificado num recurso de ingress com o prefixo especificado. Use-o para expor serviços cujos pontos de extremidade são diferentes dos nomes de ponto de extremidade que você usa para expor um serviço em um recurso de entrada.

Utilização

appgw.ingress.kubernetes.io/backend-path-prefix: <path prefix>

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-bkprefix
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

O exemplo anterior define um recurso de entrada nomeado go-server-ingress-bkprefix com uma anotação chamada appgw.ingress.kubernetes.io/backend-path-prefix: "/test/". A anotação informa ao Application Gateway que deve criar uma configuração HTTP que substitua o prefixo do caminho de /hello para /test/.

O exemplo define apenas uma regra. No entanto, as anotações se aplicam a todo o recurso de entrada. Portanto, se definires várias regras, configurarás o prefixo do caminho de backend para cada um dos caminhos especificados. Se você quiser regras diferentes com prefixos de caminho diferentes (mesmo para o mesmo serviço), precisará definir recursos de entrada diferentes.

Nome do host de back-end

Use a anotação a seguir para especificar o nome do host que o Application Gateway deve usar ao falar com os pods.

Utilização

appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-timeout
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        backend:
          service:
            name: store-service
            port:
              number: 80
        pathType: Exact

Sonda de Saúde Personalizada

Você pode configurar o Application Gateway para enviar uma verificação de saúde personalizada para o pool de endereços de back-end. Quando as anotações a seguir estão presentes, o controlador de entrada do Kubernetes cria uma sonda personalizada para monitorar o aplicativo de back-end. Em seguida, o controlador aplica as alterações ao Application Gateway.

health-probe-hostname: Esta anotação permite um nome de host personalizado no teste de integridade.
health-probe-port: Esta anotação configura uma porta personalizada para o teste de integridade.
health-probe-path: Esta anotação define um caminho para a sonda de estado.
health-probe-status-codes: Esta anotação permite que o teste de integridade aceite diferentes códigos de status HTTP.
health-probe-interval: Esta anotação define o intervalo no qual a sonda de integridade é executada.
health-probe-timeout: Esta anotação define quanto tempo a sonda de saúde aguarda por uma resposta antes de ser considerada como falhada.
health-probe-unhealthy-threshold: Esta anotação define quantas sondas de saúde devem falhar para que o back-end seja marcado como não saudável.

Utilização

appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 80
appgw.ingress.kubernetes.io/health-probe-path: "/"
appgw.ingress.kubernetes.io/health-probe-status-codes: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 30
appgw.ingress.kubernetes.io/health-probe-timeout: 30
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
    appgw.ingress.kubernetes.io/health-probe-port: 81
    appgw.ingress.kubernetes.io/health-probe-path: "/probepath"
    appgw.ingress.kubernetes.io/health-probe-status-codes: "100-599"
    appgw.ingress.kubernetes.io/health-probe-interval: 31
    appgw.ingress.kubernetes.io/health-probe-timeout: 31
    appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

Redirecionamento TLS

Você pode configurar o Application Gateway para redirecionar automaticamente URLs HTTP para suas contrapartes HTTPS. Quando esta anotação está presente e o TLS está configurado corretamente, o controlador de ingressos do Kubernetes cria uma regra de roteamento com configuração de redirecionamento. Em seguida, o controlador aplica as alterações à sua instância do Application Gateway. O redirecionamento criado é HTTP 301 Moved Permanently.

Utilização

appgw.ingress.kubernetes.io/ssl-redirect: "true"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-redirect
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
   - hosts:
     - www.contoso.com
     secretName: testsecret-tls
  rules:
  - host: www.contoso.com
    http:
      paths:
      - backend:
          service:
            name: websocket-repeater
            port:
              number: 80

Drenagem de conexões

Use as seguintes anotações se quiser usar a drenagem de conexão:

connection-draining: Esta anotação especifica se a drenagem de conexão deve ser habilitada.
connection-draining-timeout: Esta anotação especifica um tempo limite, após o qual o Application Gateway encerra as solicitações para o endpoint de back-end em esvaziamento.

Utilização

appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-drain
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/connection-draining: "true"
    appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

Use a anotação a seguir para habilitar a afinidade baseada em cookies.

Utilização

appgw.ingress.kubernetes.io/cookie-based-affinity: "true"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-affinity
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

Tempo de Espera Esgotado

Use a anotação a seguir para especificar o tempo limite da solicitação em segundos. Após o tempo limite, o Application Gateway falhará uma solicitação se a resposta não for recebida.

Utilização

appgw.ingress.kubernetes.io/request-timeout: "20"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-timeout
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/request-timeout: "20"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

Usar IP privado

Utilize a seguinte anotação para especificar se este endpoint deve ser exposto num endereço IP privado do Gateway de Aplicação.

Para uma instância do Application Gateway que não tem um IP privado, as entradas com appgw.ingress.kubernetes.io/use-private-ip: "true" são ignoradas. Os logs do controlador e os eventos de entrada para essas entradas mostram um NoPrivateIP aviso.

Utilização

appgw.ingress.kubernetes.io/use-private-ip: "true"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-privateip
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 80

Substituir porta do frontend

Utilize a seguinte anotação para configurar um ouvinte de frontend para usar portas diferentes de 80 para HTTP e de 443 para HTTPS.

Se a porta estiver dentro do intervalo autorizado do Application Gateway (1 a 64999), o ouvinte será criado nessa porta específica. Se você definir uma porta inválida ou nenhuma porta na anotação, a configuração usará o padrão de 80 ou 443.

Utilização

appgw.ingress.kubernetes.io/override-frontend-port: "port"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-overridefrontendport
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/override-frontend-port: "8080"
spec:
  rules:
  - http:
      paths:
      - path: /hello/
        backend:
          service:
            name: store-service
            port:
              number: 80
        pathType: Exact

Nota

As solicitações externas precisam ser direcionadas http://somehost:8080 em vez de http://somehost.

Protocolo de back-end

Use o seguinte para especificar o protocolo que o Application Gateway deve usar quando se comunicar com os pods. Os protocolos suportados são HTTP e HTTPS.

Embora os certificados autoassinados sejam suportados no Application Gateway, o AGIC atualmente suporta HTTPS apenas quando os pods usam um certificado assinado por uma autoridade de certificação conhecida.

Não use a porta 80 com HTTPS e a porta 443 com HTTP nos pods.

Utilização

appgw.ingress.kubernetes.io/backend-protocol: "https"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-timeout
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-protocol: "https"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 443

Extensão de Nome do Host

Você pode configurar o Application Gateway para aceitar vários nomes de host. Use a anotação hostname-extension para definir vários nomes de host, incluindo nomes de host coringa. Essa ação acrescenta os nomes de host ao FQDN definido nas informações de entrada spec.rules.host no ouvinte frontend, portanto, ele é configurado como um ouvinte multissite.

Utilização

appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-multisite
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
spec:
  rules:
  - host: contoso.com
    http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 443

O exemplo anterior configura o ouvinte para aceitar tráfego para os nomes de anfitrião hostname1.contoso.com e hostname2.contoso.com.

Política do WAF para o Path

Use a anotação a seguir para anexar uma política de firewall de aplicativo Web (WAF) existente aos caminhos de lista para um host dentro de um recurso de entrada do Kubernetes que está sendo anotado. A política WAF é aplicada a ambas as /ad-server e /auth URLs.

Utilização

appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/SampleRG/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/AGICWAFPolcy"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ad-server-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/abcd/resourceGroups/rg/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/adserver"
spec:
  rules:
  - http:
      paths:
      - path: /ad-server
        backend:
          service:
            name: ad-server
            port:
              number: 80
        pathType: Exact
      - path: /auth
        backend:
          service:
            name: auth-server
            port:
              number: 80
        pathType: Exact

Certificado SSL do Application Gateway

Você pode configurar o certificado SSL no Application Gateway a partir de um arquivo de certificado PFX local ou de uma referência a uma ID secreta não versionada do Azure Key Vault. Quando a anotação está presente com um nome de certificado e o certificado é pré-instalado no Application Gateway, o controlador de ingressos do Kubernetes cria uma regra de roteamento com um ouvinte de HTTPS e aplica as alterações à sua instância do Application Gateway. Você também pode usar a anotação appgw-ssl-certificate junto com a anotação ssl-redirect no caso de um redirecionamento SSL.

Nota

A appgw-ssl-certificate anotação é ignorada quando a especificação TLS é definida em ingresso ao mesmo tempo. Se você quiser certificados diferentes com hosts diferentes (terminação de vários certificados TLS), precisará definir recursos de entrada diferentes.

Utilização

appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-certificate
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
spec:
  rules:
  - host: www.contoso.com
    http:
      paths:
      - backend:
          service:
            name: websocket-repeater
            port:
              number: 80

Perfil SSL do Application Gateway

Você pode configurar um perfil SSL na instância do Application Gateway por ouvinte. Quando a anotação está presente com um nome de perfil e o perfil é pré-instalado no Application Gateway, o controlador de ingressos do Kubernetes cria uma regra de roteamento com um listener HTTPS e aplica as alterações na sua instância do Application Gateway.

Utilização

appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-certificate
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
    appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
spec:
  rules:
  - host: www.contoso.com
    http:
      paths:
      - backend:
          service:
            name: websocket-repeater
            port:
              number: 80

Certificado raiz confiável do Application Gateway

Agora você pode configurar seus próprios certificados raiz para o Application Gateway para serem confiáveis via AGIC. Você pode usar a appgw-trusted-root-certificate anotação junto com a backend-protocol anotação para indicar criptografia SSL de ponta a ponta. Se você especificar vários certificados raiz, separe-os com uma vírgula; por exemplo, name-of-my-root-cert1,name-of-my-root-cert2.

Utilização

appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-certificate
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-protocol: "https"
    appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
spec:
  rules:
  - host: www.contoso.com
    http:
      paths:
      - backend:
          service:
            name: websocket-repeater
            port:
              number: 80

Reescrever conjunto de regras

Use a anotação a seguir para atribuir um conjunto de regras de regravação existente à regra de roteamento de solicitação correspondente.

Utilização

appgw.ingress.kubernetes.io/rewrite-rule-set: <rewrite rule set name>

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-bkprefix
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/rewrite-rule-set: add-custom-response-header
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 8080

Reescrever recurso personalizado do conjunto de regras

Nota

O lançamento do Application Gateway for Containers introduz inúmeras alterações de desempenho, resiliência e recursos. Considere o uso do Application Gateway for Containers para sua próxima implantação.

Você pode encontrar regras de reconfiguração de URL para o Application Gateway for Containers neste artigo sobre a API de Gateway e neste artigo sobre a API de Ingresso. Você pode encontrar regras de reconfiguração de cabeçalho para o Application Gateway for Containers neste artigo sobre a API do Gateway.

O Application Gateway permite reescrever conteúdos selecionados de solicitações e respostas. Com esse recurso, você pode traduzir URLs, alterar parâmetros de cadeia de caracteres de consulta e modificar cabeçalhos de solicitação e resposta. Você também pode usar esse recurso para adicionar condições para garantir que a URL ou os cabeçalhos especificados sejam reescritos somente quando determinadas condições forem atendidas. Reescrever recurso personalizado do conjunto de regras traz esse recurso para o AGIC.

Os cabeçalhos HTTP permitem que um cliente e um servidor passem informações adicionais com uma solicitação ou resposta. Ao reescrever esses cabeçalhos, você pode realizar tarefas importantes, como adicionar campos de cabeçalho relacionados à segurança (por exemplo, HSTS ou X-XSS-Protection), remover campos de cabeçalho de resposta que podem revelar informações confidenciais e remover informações de porta de X-Forwarded-For cabeçalhos.

Com o recurso de regravação de URL, você pode:

Reescreva o nome do host, o caminho e a cadeia de caracteres de consulta da URL da solicitação.
Opte por reescrever o URL de todos os pedidos ou apenas pedidos que correspondam a uma ou mais das condições que definiu. Essas condições são baseadas nas propriedades de solicitação e resposta (cabeçalho da solicitação, cabeçalho da resposta e variáveis de servidor).
Escolha encaminhar a solicitação com base no URL original ou no URL reescrito.

Nota

Este recurso é suportado desde 1.6.0-rc1. Use appgw.ingress.kubernetes.io/rewrite-rule-set, que permite usar um conjunto de regras de reescrita existente no Application Gateway.

Utilização

appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource

Exemplo

apiVersion: appgw.ingress.azure.io/v1beta1 
kind: AzureApplicationGatewayRewrite 
metadata: 
  name: my-rewrite-rule-set-custom-resource 
spec: 
  rewriteRules: 
  - name: rule1 
    ruleSequence: 21
    conditions:
  - ignoreCase: false
    negate: false
    variable: http_req_Host
    pattern: example.com
  actions:
    requestHeaderConfigurations:
    - actionType: set
      headerName: incoming-test-header
      headerValue: incoming-test-value
    responseHeaderConfigurations:
    - actionType: set
      headerName: outgoing-test-header
      headerValue: outgoing-test-value
    urlConfiguration:
      modifiedPath: "/api/"
      modifiedQueryString: "query=test-value"
      reroute: false

Prioridade das Regras

A anotação a seguir permite que o controlador de entrada do Application Gateway defina explicitamente a prioridade das regras de roteamento de solicitação associadas.

Utilização

appgw.ingress.kubernetes.io/rule-priority:

Exemplo

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-server-ingress-rulepriority
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/rule-priority: 10
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Exact
        backend:
          service:
            name: go-server-service
            port:
              number: 8080

O exemplo anterior define uma prioridade de 10 para a regra de roteamento de solicitação.

Partilhar via

Anotações para o Application Gateway Ingress Controller

Lista de anotações suportadas

Prefixo do caminho de back-end

Utilização

Exemplo

Nome do host de back-end

Utilização

Exemplo

Sonda de Saúde Personalizada

Utilização

Exemplo

Redirecionamento TLS

Utilização

Exemplo

Drenagem de conexões

Utilização

Exemplo

Afinidade baseada em cookies

Utilização

Exemplo

Tempo de Espera Esgotado

Utilização

Exemplo

Usar IP privado

Utilização

Exemplo

Substituir porta do frontend

Utilização

Exemplo

Protocolo de back-end

Utilização

Exemplo

Extensão de Nome do Host

Utilização

Exemplo

Política do WAF para o Path

Utilização

Exemplo

Certificado SSL do Application Gateway

Utilização

Exemplo

Perfil SSL do Application Gateway

Utilização

Exemplo

Certificado raiz confiável do Application Gateway

Utilização

Exemplo

Reescrever conjunto de regras

Utilização

Exemplo

Reescrever recurso personalizado do conjunto de regras

Utilização

Exemplo

Prioridade das Regras

Utilização

Exemplo

Próximos passos

Comentários

Recursos adicionais