Automatizando o gerenciamento de certificados em um ambiente Kubernetes

Jason Schmidt

Certificados SSL/TLS válidos são um requisito essencial no cenário moderno de aplicações. Infelizmente, o gerenciamento da renovação de certificados costuma ser deixado em segundo plano durante a implantação de uma aplicação. Os certificados têm uma validade limitada, que varia de aproximadamente 13 meses para certificados da DigiCert a 90 dias para certificados da Let’s Encrypt. Para manter o acesso seguro, esses certificados precisam ser renovados ou reemitidos antes de expirarem. Dada a grande carga de trabalho da maioria das equipes de Operações, a renovação de certificados às vezes acaba sendo esquecida, levando a uma corrida contra o tempo quando eles se aproximam da data de expiração — ou, pior ainda, quando já expiraram.

Não precisa ser assim. Com algum planejamento e preparação, o gerenciamento de certificados pode ser automatizado e simplificado. Aqui, veremos uma solução para Kubernetes que utiliza três tecnologias:

• O cert-manager da Jetstack
• Let’s Encrypt
• Controlador de Ingress NGINX

Neste blog, você aprenderá a simplificar o gerenciamento de certificados fornecendo certificados exclusivos, renovados e atualizados automaticamente, aos seus endpoints.

Certificados em um ambiente Kubernetes

Antes de entrarmos nos detalhes técnicos, precisamos definir alguns termos. O termo “certificado TLS” refere-se a dois componentes necessários para habilitar conexões HTTPS em nosso controlador Ingress:

• O certificado
• A chave privada

Tanto o certificado quanto a chave privada são emitidos pela Let’s Encrypt. Para uma explicação completa sobre como os certificados TLS funcionam, consulte o artigo da DigiCert Como funcionam os certificados TLS/SSL.

No Kubernetes, esses dois componentes são armazenados como Secrets. As cargas de trabalho do Kubernetes, como o NGINX Ingress Controller e o cert-manager, podem gravar e ler esses Secrets, que também podem ser gerenciados por usuários com acesso à instalação do Kubernetes.

Apresentando o cert-manager

O projeto cert-manager é um controlador de certificados que funciona com Kubernetes e OpenShift. Quando implantado no Kubernetes, o cert-manager emitirá automaticamente os certificados exigidos pelos controladores Ingress e garantirá que eles sejam válidos e estejam atualizados. Além disso, ele acompanhará as datas de expiração dos certificados e tentará renová-los em um intervalo de tempo configurado. Embora funcione com diversos emissores públicos e privados, mostraremos sua integração com o Let’s Encrypt.

Dois tipos de desafio

Ao usar o Let’s Encrypt, todo o gerenciamento de certificados é feito automaticamente. Embora isso ofereça muita praticidade, também apresenta um problema: como o serviço garante que você é o proprietário do nome de domínio totalmente qualificado (FQDN) em questão?

Esse problema é resolvido por meio de um desafio, que exige que você responda a uma solicitação de verificação que somente alguém com acesso aos registros DNS do domínio específico pode atender. Os desafios podem assumir uma de duas formas:

1. HTTP-01: Esse desafio pode ser respondido por meio de um registro DNS para o FQDN para o qual você está emitindo um certificado. Por exemplo, se o seu servidor estiver no IP www.xxx.yyy.zzz e o seu FQDN for cert.example.com, o mecanismo de desafio disponibilizará um token no servidor em www.xxx.yyy.zzz e os servidores do Let’s Encrypt tentarão acessá-lo por meio de cert.example.com. Se a tentativa for bem-sucedida, o desafio será concluído e o certificado será emitido. O HTTP-01 é a maneira mais simples de gerar um certificado, pois não exige acesso direto ao provedor de DNS. Esse tipo de desafio é sempre realizado pela porta 80 (HTTP). Observe que, ao usar desafios HTTP-01, o cert-manager utilizará o controlador Ingress para disponibilizar o token do desafio.

1. DNS-01: esse desafio cria um registro DNS TXT com um token, que é então verificado pelo emissor. Se o token for reconhecido, você terá comprovado a propriedade desse domínio e poderá emitir certificados para os registros dele. Ao contrário do desafio HTTP-01, ao usar o desafio DNS-01, o FQDN não precisa ser resolvido para o endereço IP do seu servidor (nem sequer existir). Além disso, o DNS-01 pode ser usado quando a porta 80 está bloqueada. Em contrapartida a essa facilidade de uso, é necessário fornecer à instalação do cert-manager acesso à sua infraestrutura de DNS por meio de um token de API.

Controladores de Ingress

Um controlador de Ingress é um serviço especializado para Kubernetes que recebe tráfego externo ao cluster, faz o balanceamento de carga para os Pods internos (um grupo de um ou mais contêineres) e gerencia o tráfego de saída. Além disso, o controlador de Ingress é controlado por meio da API do Kubernetes e monitora e atualiza a configuração de balanceamento de carga à medida que Pods são adicionados, removidos ou apresentam falhas.

Para saber mais sobre os controladores de Ingress, leia os seguintes artigos:

• Introdução às redes no Kubernetes
• Guia para escolher um controlador de Ingress, parte 4: opções de controladores de Ingress NGINX

Nos exemplos abaixo, usaremos o NGINX Ingress Controller, desenvolvido e mantido pela F5 NGINX.

Exemplos de gerenciamento de certificados

Estes exemplos pressupõem que você tenha uma instalação funcional do Kubernetes com a qual possa realizar testes e que ela possa atribuir um endereço IP externo (objeto LoadBalancer do Kubernetes). Além disso, pressupõem que você possa receber tráfego nas portas 80 e 443 (se estiver usando o desafio HTTP-01) ou somente na porta 443 (se estiver usando o desafio DNS-01). Estes exemplos são apresentados usando o Mac OS X, mas também podem ser usados no Linux ou no WSL.

Você também precisará de um provedor de DNS e de um FQDN cujo registro A possa ser alterado. Se estiver usando o desafio HTTP-01, você só precisará conseguir adicionar um registro A (ou solicitar que alguém o adicione para você). Se estiver usando o desafio DNS-01, você precisará de acesso via API a um provedor de DNS compatível ou a um provedor de webhook compatível.

Implantar o NGINX Ingress Controller

A maneira mais fácil é fazer a implantação via Helm. Essa implantação permite usar tanto o Ingress do Kubernetes quanto o CRD VirtualServer do NGINX.

1. Adicione o repositório do NGINX.

$ helm repo add nginx-stable https://helm.nginx.com/stable  "nginx-stable" has been added to your repositories 

1. Atualize o repositório.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  Update Complete. ⎈Happy Helming!⎈ 

1. Implante o controlador de Ingress.

$ helm install nginx-kic nginx-stable/nginx-ingress \  --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
  --create-namespace  --set controller.enableCertManager=true 
  NAME: nginx-kic
  LAST DEPLOYED: Thu Sep  1 15:58:15 2022
  NAMESPACE: nginx-ingress
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The NGINX Ingress Controller has been installed. 

1. Verifique a implantação e obtenha o endereço IP de saída do controlador de Ingress. Observe que não é possível continuar sem um endereço IP válido.

$ kubectl get deployments --namespace nginx-ingress  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-kic-nginx-ingress   1/1     1            1           23s
  $ kubectl get services --namespace nginx-ingress
  NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
  nginx-kic-nginx-ingress   LoadBalancer   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s 

Adicione seu registro A de DNS

O processo dependerá do seu provedor de DNS. Esse nome DNS precisará ser resolvido pelos servidores do Let’s Encrypt, o que pode exigir que você aguarde a propagação do registro antes que ele funcione. Para obter mais informações, consulte o artigo da SiteGround O que é propagação de DNS e por que ela demora tanto?

Assim que o FQDN escolhido puder ser resolvido, você estará pronto para avançar para a próxima etapa.

$ host cert.example.com  cert.example.com has address www.xxx.yyy.zzz

Implantar o cert-manager

A próxima etapa é implantar a versão mais recente do cert-manager. Novamente, usaremos o Helm para a implantação.

1. Adicione o repositório do Helm.

$ helm repo add jetstack https://charts.jetstack.io  "jetstack" has been added to your repositories 

1. Atualize o repositório.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  ...Successfully got an update from the "jetstack" chart repository
  Update Complete. ⎈Happy Helming!⎈ 

1. Implante o cert-manager.

$ helm install cert-manager jetstack/cert-manager \  --namespace cert-manager --create-namespace \
  --version v1.9.1  --set installCRDs=true 
  NAME: cert-manager
  LAST DEPLOYED: Thu Sep  1 16:01:52 2022 
  NAMESPACE: cert-manager
  STATUS: deployed
  REVISION: 1 
  TEST SUITE: None
  NOTES:
  cert-manager v1.9.1 has been deployed successfully!
  In order to begin issuing certificates, you will need to set up a ClusterIssuer
  or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
  More information on the different types of issuers and how to configure them
  can be found in our documentation:
  https://cert-manager.io/docs/configuration/ For information on how to configure cert-manager to automatically provision
  Certificates for Ingress resources, take a look at the `ingress-shim`
  documentation:
  https://cert-manager.io/docs/usage/ingress/

1. Valide a implantação.

$ kubectl get deployments --namespace cert-manager  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  cert-manager              1/1     1            1           4m30s
  cert-manager-cainjector   1/1     1            1           4m30s
  cert-manager-webhook      1/1     1            1           4m30s 

Implante o exemplo NGINX Cafe

Usaremos o exemplo NGINX Cafe para disponibilizar nossa implantação de backend e nossos Serviços. Esse é um exemplo comum na documentação fornecida pela NGINX. Não implantaremos o Ingress como parte deste processo.

1. Clone o projeto NGINX Ingress do GitHub.

$ git clone https://github.com/nginxinc/kubernetes-ingress.git  Cloning into 'kubernetes-ingress'...
  remote: Enumerating objects: 44979, done.
  remote: Counting objects: 100% (172/172), done.
  remote: Compressing objects: 100% (108/108), done.
  remote: Total 44979 (delta 87), reused 120 (delta 63), pack-reused 44807
  Receiving objects: 100% (44979/44979), 60.27 MiB | 27.33 MiB/s, done.
  Resolving deltas: 100% (26508/26508), done. 

1. Acesse o diretório examples. Esse diretório contém vários exemplos que demonstram diferentes configurações do controlador Ingress. Usaremos o exemplo fornecido no diretório complete-example.

$ cd ./kubernetes-ingress/examples/ingress-resources/complete-example 

1. Implante o exemplo NGINX Cafe.

$ kubectl apply -f ./cafe.yaml
  deployment.apps/coffee created
  service/coffee-svc created
  deployment.apps/tea created
  service/tea-svc created

1. Valide a implantação e os Serviços usando o comando kubectl get. Verifique se os Pods aparecem como READY e se os Serviços aparecem como running. O exemplo abaixo mostra uma amostra representativa do resultado esperado. Observe que o serviço kubernetes é um serviço do sistema executado no mesmo namespace (default) que o exemplo do NGINX Cafe.

$ kubectl get deployments,services  --namespace default  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/coffee   2/2     2            2           69s
  deployment.apps/tea      3/3     3            3           68s
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
  service/coffee-svc   ClusterIP   10.128.154.225   <none>        80/TCP    68s
  service/kubernetes   ClusterIP   10.128.0.1       <none>        443/TCP   29m
	service/tea-svc      ClusterIP   10.128.96.145    <none>        80/TCP    68s 

Implante o ClusterIssuer

No cert-manager, o ClusterIssuer pode ser usado para emitir certificados. Esse é um objeto com escopo de cluster que pode ser referenciado por qualquer namespace e usado por qualquer solicitação de certificado com a autoridade emissora de certificados definida. Neste exemplo, qualquer solicitação de certificados da Let’s Encrypt pode ser processada por esse ClusterIssuer.

Implante o ClusterIssuer para o tipo de desafio selecionado. Embora esteja fora do escopo deste artigo, há opções avançadas de configuração que permitem especificar vários resolvedores (escolhidos com base nos campos do seletor) no seu ClusterIssuer.

Noções básicas dos desafios ACME

O protocolo Automated Certificate Management Environment (ACME) é usado para determinar se você é o proprietário de um nome de domínio e, portanto, pode receber um certificado Let’s Encrypt. Para este desafio, estes são os parâmetros que precisam ser informados:

• metadata.name: o nome do ClusterIssuer, que deve ser exclusivo na instalação do Kubernetes. Esse nome será usado posteriormente no exemplo, quando emitirmos um certificado.
• spec.acme.email: Este é o endereço de e-mail que você está cadastrando no Let’s Encrypt para gerar certificados. Use o seu próprio e-mail.
• spec.acme.privateKeySecretRef: Este é o nome do segredo do Kubernetes que você usará para armazenar sua chave privada.
• spec.acme.solvers: Isso deve ser mantido como está – indica o tipo de desafio (ou, como o ACME o denomina, solucionador) que você está usando (HTTP-01 ou DNS-01), bem como a classe Ingress à qual ele deve ser aplicado, que, neste caso, será nginx.

Usando HTTP-01

Este exemplo mostra como configurar um ClusterIssuer para usar o desafio HTTP-01 a fim de comprovar a propriedade do domínio e obter um certificado.

1. Crie o ClusterIssuer usando HTTP-01 para os desafios.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
      - http01:
         ingress:
           class: nginx
  EOF
  clusterissuer.cert-manager.io/prod-issuer created 

1. Valide o ClusterIssuer (ele deve aparecer como pronto).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    34s 

Usando DNS-01

Este exemplo mostra como configurar um ClusterIssuer para usar o desafio DNS-01 a fim de autenticar a propriedade do seu domínio. Dependendo do seu provedor de DNS, provavelmente será necessário usar um Secret do Kubernetes para armazenar seu token. Este exemplo usa a Cloudflare. Observe o uso do namespace. A aplicação cert-manager, implantada no namespace cert-manager, precisa ter acesso ao Secret.

Para este exemplo, você precisará de um token de API da Cloudflare, que pode ser criado na sua conta. Ele deverá ser inserido na linha <API Token> abaixo. Se você não estiver usando a Cloudflare, será necessário seguir a documentação do seu provedor.

1. Crie um Secret para o token da API.

$ cat << EOF | kubectl apply -f   apiVersion: v1
  kind: Secret
  metadata:
    name: cloudflare-api-token-secret
    namespace: cert-manager
  type: Opaque
  stringData:
    api-token: <API Token> 
  EOF 

1. Crie o emissor usando DNS-01 para os desafios.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
        - dns01:
            cloudflare:
              apiTokenSecretRef:
                name: cloudflare-api-token-secret
                key: api-token
  EOF 

1. Valide o emissor (ele deve aparecer como pronto).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    31m 

Implante o Ingress

Este é o momento para o qual estávamos nos preparando: a implantação do recurso Ingress para nossa aplicação. Isso encaminhará o tráfego para a aplicação NGINX Cafe que implantamos anteriormente.

Usando o Ingress do Kubernetes

Se você estiver usando o recurso padrão Ingress do Kubernetes, use o seguinte YAML de implantação para configurar o Ingress e solicitar um certificado.

apiVersion: networking.k8s.io/v1   kind: Ingress 
  metadata: 
    name: cafe-ingress 
    annotations: 
      cert-manager.io/cluster-issuer: prod-issuer 
      acme.cert-manager.io/http01-edit-in-place: "true" 
  spec: 
    ingressClassName: nginx 
    tls: 
    - hosts: 
      - cert.example.com 
      secretName: cafe-secret 
    rules: 
    - host: cert.example.com 
      http: 
        paths: 
        - path: /tea 
          pathType: Prefix 
          backend: 
            service: 
              name: tea-svc 
              port: 
                number: 80 
        - path: /coffee 
          pathType: Prefix 
          backend: 
            service: 
              name: coffee-svc 
              port: 
number: 80 

Vale a pena revisar algumas partes importantes do manifesto:

• A API chamada é o Ingress padrão do Kubernetes.
• Uma parte fundamental dessa configuração está em metadata.annotations, onde definimos acme.cert-manager.io/http01-edit-in-place como “true”. Esse valor é obrigatório e ajusta a forma como o desafio é disponibilizado. Para obter mais informações, consulte o documento Anotações compatíveis. Isso também pode ser feito usando uma configuração mestre/minion.
• O spec.ingressClassName refere-se ao controlador NGINX Ingress que instalamos e usaremos.
• O recurso Secret do Kubernetes spec.tls.secret armazena a chave do certificado retornada quando o certificado é emitido pelo Let’s Encrypt.
• Nosso nome de host cert.example.com está especificado em spec.tls.hosts e spec.rules.host. Esse é o nome de host para o qual nosso ClusterIssuer emitiu o certificado.
• A seção spec.rules.http define os caminhos e os Serviços de backend que atenderão às solicitações nesses caminhos. Por exemplo, o tráfego para /tea será direcionado à porta 80 no tea-svc.

1. Modifique o manifesto acima de acordo com a sua instalação. No mínimo, isso envolverá alterar os valores de spec.rules.host e spec.tls.hosts, mas você deve revisar todos os parâmetros da configuração.
2. Aplique o manifesto.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created 

1. Aguarde a emissão do certificado. O campo READY deve apresentar o valor “True”.

$ kubectl get certificates  NAME                                      READY   SECRET        AGE
  certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m 

Usando o Servidor Virtual / as Rotas Virtuais do NGINX

Se você estiver usando as CRDs do NGINX, precisará usar o seguinte YAML de implantação para configurar seu Ingress.

  apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata: 
    name: cafe 
  spec: 
    host: cert.example.com 
    tls: 
      secret: cafe-secret 
      cert-manager: 
        cluster-issuer: prod-issuer 
    upstreams: 
      - name: tea 
        service: tea-svc 
        port: 80 
      - name: coffee 
        service: coffee-svc 
        port: 80 
    routes: 
      - path: /tea 
        action: 
          pass: tea 
      - path: /coffee 
        action: 
          pass: coffee

Mais uma vez, vale a pena revisar algumas partes importantes do manifesto:

• A API chamada é a k8s.nginx.org/v1, específica do NGINX, para o recurso VirtualServer.
• O recurso Secret do Kubernetes spec.tls.secret armazena a chave do certificado que é retornada quando o certificado é emitido pelo Let’s Encrypt.
• Nosso nome de host cert.example.com é especificado em spec.host. Esse é o nome de host para o qual nosso ClusterIssuer emitiu o certificado.
• Os valores de spec.upstreams apontam para nossos Serviços de backend, incluindo as portas.
• O campo spec.routes define tanto a rota quanto a ação a ser executada quando essas rotas forem acessadas.

1. Modifique o manifesto acima de acordo com a sua instalação. No mínimo, será necessário alterar o valor de spec.host, mas você deve revisar todos os parâmetros da configuração.
2. Aplique o manifesto.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

1. Aguarde a emissão do certificado. O status exibido deverá ser Válido.

$ kubectl get VirtualServers  NAME   STATE   HOST                    IP             PORTS      AGE
  cafe   Valid   cert.example.com   www.xxx.yyy.zzz   [80,443]   51m 

Visualizar o certificado

Você pode visualizar o certificado por meio da API do Kubernetes. Isso exibirá detalhes sobre o certificado, incluindo seu tamanho e a chave privada associada.

$ kubectl describe secret cafe-secret  Name:         cafe-secret
  Namespace:    default
  Labels:       <none>
  Annotations:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: cafe-secret
                cert-manager.io/common-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/issuer-kind: ClusterIssuer
                cert-manager.io/issuer-name: prod-issuer
                cert-manager.io/uri-sans:Type:  kubernetes.io/tlsData
  ====
  tls.crt:  5607 bytes
  tls.key:  1675 bytes 

Se quiser ver o certificado e a chave propriamente ditos, execute o comando a seguir. (Observação: isso evidencia uma fragilidade dos Secrets do Kubernetes: eles podem ser lidos por qualquer pessoa que tenha as permissões de acesso necessárias.)

$ kubectl get secret cafe-secret -o yaml

Teste o Ingress

Teste os certificados. Você pode usar o método que preferir. O exemplo abaixo usa o cURL. O sucesso é indicado por um bloco semelhante ao mostrado anteriormente, que inclui o nome do servidor, o endereço interno do servidor, a data, o URI (rota) escolhido (café ou chá) e o ID da solicitação. As falhas serão apresentadas na forma de códigos de erro HTTP, provavelmente 400 ou 301.

$ curl https://cert.example.com/tea
  Server address: 10.2.0.6:8080
  Server name: tea-5c457db9-l4pvq
  Date: 02/Sep/2022:15:21:06 +0000
  URI: /tea
  Request ID: d736db9f696423c6212ffc70cd7ebecf
  $ curl https://cert.example.com/coffee
  Server address: 10.2.2.6:8080
  Server name: coffee-7c86d7d67c-kjddk
  Date: 02/Sep/2022:15:21:10 +0000
  URI: /coffee
Request ID: 4ea3aa1c87d2f1d80a706dde91f31d54 

Renovações de certificados

No início, prometemos que essa abordagem eliminaria a necessidade de gerenciar as renovações de certificados. No entanto, ainda não explicamos como isso é feito. Por quê? Porque esse é um recurso essencial e integrado do cert-manager. Nesse processo automático, quando o cert-manager detecta que um certificado não está presente, expirou, está a menos de 15 dias do vencimento ou quando o usuário solicita um novo certificado pela CLI, então um novo certificado é solicitado automaticamente. Não poderia ser mais fácil.

Perguntas frequentes

E quanto ao NGINX Plus?

Se você é assinante do NGINX Plus, a única diferença será na instalação do NGINX Ingress Controller. Consulte a seção Instalação com Helm da documentação do NGINX para obter instruções sobre como modificar o comando Helm fornecido acima para fazer isso.

Qual tipo de desafio devo usar?

Isso depende muito do seu caso de uso.

O método de desafio HTTP-01 exige que a porta 80 esteja aberta para a Internet e que o registro A do DNS esteja configurado corretamente para o endereço IP do controlador de Ingress. Essa abordagem não exige acesso ao provedor de DNS, exceto para criar o registro A.

O método de desafio DNS-01 pode ser usado quando não é possível expor a porta 80 à Internet e requer apenas que o cert-manager tenha acesso de saída ao provedor de DNS. No entanto, esse método exige que você tenha acesso à API do seu provedor de DNS, embora o nível de acesso necessário varie de acordo com o provedor específico.

Como solucionar problemas?

Como o Kubernetes é muito complexo, é difícil fornecer informações específicas para a solução de problemas. Caso você enfrente algum problema, convidamos você a entrar em contato conosco pelo Slack da comunidade NGINX (os assinantes do NGINX Plus podem usar suas opções habituais de suporte).

Comece hoje mesmo

Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS e baixe o NGINX Service Mesh, que é sempre gratuito.

Sobre o autor

Jason Schmidt

Mais publicações de Jason Schmidt