BLOG | NGINX

Automatizando o gerenciamento de certificados em um ambiente Kubernetes

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Jason Schmidt
Jason Schmidt
Publicado em 05 de outubro de 2022

Certificados SSL/TLS válidos são um requisito fundamental do cenário de aplicativos modernos. Infelizmente, gerenciar renovações de certificados (ou cert) geralmente é uma reflexão tardia ao implantar um aplicativo. Os certificados têm uma vida útil limitada, variando 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/reemitidos antes de expirarem. Dada a carga de trabalho substancial da maioria das equipes de operações, a renovação de certificados às vezes não é realizada, resultando em confusão à medida que os certificados se aproximam — ou pior, passam — da data de expiração.

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 o Kubernetes usando três tecnologias:

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

Certificados em um ambiente Kubernetes

Antes de entrarmos em detalhes técnicos, precisamos definir alguma terminologia. O termo “certificado TLS” se refere 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 de como os certificados TLS funcionam, consulte a postagem da DigiCert Como funcionam os certificados TLS/SSL .

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

Apresentando o cert-manager

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

Diagrama do Cert Manager

Dois tipos de desafios

Ao usar o Let’s Encrypt, todo o gerenciamento de certificados é feito automaticamente. Embora isso ofereça muita conveniência, 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 usando 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 fornecer. Os desafios assumem uma de duas formas:

  1. HTTP-01 : Esse desafio pode ser respondido tendo 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 seu FQDN for cert.example.com, o mecanismo de desafio exporá um token no servidor em www.xxx.yyy.zzz e os servidores Let's Encrypt tentarão alcançá-lo via cert.example.com. Se for bem-sucedido, o desafio será aprovado e o certificado será emitido.

     

    HTTP-01 é a maneira mais simples de gerar um certificado, pois não requer acesso direto ao provedor de DNS. Esse tipo de desafio é sempre conduzido pela Porta 80 (HTTP). Observe que ao usar desafios HTTP-01, o cert-manager utilizará o controlador Ingress para servir o token de desafio.

Diagrama HTTP 01

  1. DNS-01 : Este desafio cria um registro DNS TXT com um token, que é então verificado pelo emissor. Se o token for reconhecido, você comprovou a propriedade daquele domínio e agora pode emitir certificados para seus registros. 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 mesmo existir). Além disso, o DNS-01 pode ser usado quando a porta 80 estiver bloqueada. A compensação para essa facilidade de uso é a necessidade de fornecer acesso à sua infraestrutura de DNS por meio de token de API para a instalação do cert-manager.

Diagrama DNS 01

Controladores de entrada

Um controlador de entrada é um serviço especializado para Kubernetes que traz tráfego de fora do cluster, equilibra a carga para Pods internos (um grupo de um ou mais contêineres) e gerencia o tráfego de saída. Além disso, o controlador Ingress é controlado pela API do Kubernetes e monitorará e atualizará a configuração de balanceamento de carga conforme os Pods são adicionados, removidos ou falham.

Para saber mais sobre os controladores Ingress, leia os seguintes blogs:

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

Exemplos de gerenciamento de certificados

Esses exemplos pressupõem que você tenha uma instalação funcional do Kubernetes que pode ser testada e que a instalação pode atribuir um endereço IP externo (objeto Kubernetes LoadBalancer). Além disso, ele pressupõe que você pode receber tráfego na Porta 80 e na Porta 443 (se estiver usando o desafio HTTP-01) ou somente na Porta 443 (se estiver usando o desafio DNS-01). Esses exemplos são ilustrados usando Mac OS X, mas também podem ser usados no Linux ou WSL.

Você também precisará de um provedor de DNS e um FQDN para os quais possa ajustar o registro A. Se você estiver usando o desafio HTTP-01, você só precisa adicionar um registro A (ou ter um adicionado para você). Se estiver usando o desafio DNS-01, você precisará de acesso à API para um provedor de DNS ou um provedor de webhook compatível .

Implantar o NGINX Ingress Controller

A maneira mais fácil é implantar via Helm . Esta implantação permite que você use o Kubernetes Ingress e o NGINX Virtual Server CRD.

  1. Adicione o repositório NGINX.
  2. $ helm repo add nginx-stable https://helm.nginx.com/stable "nginx-stable" foi adicionado aos seus repositórios 
  3. Atualize o repositório.
  4. $ helm repo update Aguarde enquanto pegamos as últimas novidades dos seus repositórios de gráficos...
    ...Recebemos com sucesso uma atualização do repositório de gráficos "nginx-stable"
    Atualização concluída. ⎈Feliz Helming!⎈ 
  5. Implante o controlador Ingress.
  6. $ helm install nginx-kic nginx-stable/nginx-ingress \ --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
    --create-namespace  --set controller.enableCertManager=true 
    NOME: nginx-kic
    ÚLTIMA IMPLANTAÇÃO: Qui Set 1 15:58:15 2022
    NAMESPACE: nginx-ingress
    STATUS: implantado
    REVISÃO: 1
    SUÍTE DE TESTES: Nenhum
    NOTAS:
      O NGINX Ingress Controller foi instalado. 
  7. Verifique a implantação e recupere o endereço IP da saída para o controlador Ingress. Observe que você não pode continuar sem um endereço IP válido.
  8. $ kubectl get deployments --namespace nginx-ingress NOME                       PRONTO   ATUALIZADO   DISPONÍVEL   IDADE
    nginx-kic-nginx-ingress   1/1     1            1           23s
    $ kubectl get services --namespace nginx-ingress
    NOME                      TIPO            CLUSTER-IP      EXTERNO-IP    PORTA(S)                       IDADE
    nginx-kic-nginx-ingress   Balanceador de carga   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s 

Adicione seu registro DNS A

O processo aqui dependerá do seu provedor de DNS. Esse nome DNS precisará ser resolvido pelos servidores Let's Encrypt, o que pode exigir que você espere o registro se propagar antes que ele funcione. Para mais informações sobre isso, consulte o artigo do SiteGround O que é propagação de DNS e por que demora tanto?

Depois de resolver o FQDN escolhido, você estará pronto para passar para a próxima etapa.

$ host cert.example.com cert.example.com tem o endereço www.xxx.yyy.zzz

Implantar o cert-manager

O próximo passo é implantar a versão mais recente do cert-manager. Novamente, usaremos o Helm para nossa implantação.

  1. Adicione o repositório Helm.
  2. $ helm repo add jetstack https://charts.jetstack.io "jetstack" foi adicionado aos seus repositórios 
  3. Atualize o repositório.
  4. $ helm repo update Aguarde enquanto pegamos as últimas novidades dos seus repositórios de gráficos...
    ...Recebemos com sucesso uma atualização do repositório de gráficos "nginx-stable"
    ...Recebemos com sucesso uma atualização do repositório de gráficos "jetstack"
    Atualização concluída. ⎈Feliz Helming!⎈ 
  5. Implante o cert-manager.
  6. $ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager --create-namespace \ --version v1.9.1 --set installCRDs=true NOME: cert-manager ÚLTIMA IMPLANTAÇÃO: Qui Set 1 16:01:52 2022 NAMESPACE: cert-manager STATUS: implantado REVISÃO: 1 CONJUNTO DE TESTES: Nenhum NOTAS: cert-manager v1.9.1 foi implantado com sucesso!
    Para começar a emitir certificados, você precisará configurar um recurso ClusterIssuer ou Issuer (por exemplo, criando um emissor 'letsencrypt-staging').
    Mais informações sobre os diferentes tipos de emissores e como configurá-los podem ser encontradas em nossa documentação:
    https://cert-manager.io/docs/configuration/
    Para obter informações sobre como configurar o cert-manager para provisionar automaticamente certificados para recursos do Ingress, consulte a documentação do `ingress-shim`:
    https://cert-manager.io/docs/usage/ingress/
  7. Valide a implantação.
  8. $ kubectl get deployments --namespace cert-manager NOME                       PRONTO   ATUALIZADO   DISPONÍVEL   IDADE
    cert-manager               1/1     1            1           4m30s
    cert-manager-cainjector   1/1     1            1          4m30s
    cert-manager-webhook      1/1     1            1           4m30s 

Implantar o exemplo do NGINX Cafe

Usaremos o exemplo do NGINX Cafe para fornecer nossa implantação de backend e serviços. Este é um exemplo comum usado na documentação fornecida pelo NGINX. Não implementaremos o Ingress como parte disso.

  1. Clone o projeto NGINX Ingress GitHub.
  2. $ git clone https://github.com/nginxinc/kubernetes-ingress.git Clonando em 'kubernetes-ingress'...
    remoto: Enumerando objetos: 44979, feito.
    remoto: Contando objetos: 100% (172/172), concluído.
    remoto: Comprimindo objetos: 100% (108/108), concluído.
    remoto: Total 44979 (delta 87), reutilizado 120 (delta 63), pacote-reutilizado 44807
    Recebendo objetos: 100% (44979/44979), 60,27 MiB | 27,33 MiB/s, concluído.
      Resolução de deltas: 100% (26508/26508), concluído. 
  3. Mude para o diretório de exemplos. Este diretório contém vários exemplos que demonstram várias configurações do controlador Ingress. Estamos usando o exemplo fornecido no diretório complete-example.
  4. $ cd ./kubernetes-ingress/examples/ingress-resources/complete-example 
  5. Implante o exemplo do NGINX Cafe.
  6. $ kubectl apply -f ./cafe.yaml
    implantação.apps/café criado
    serviço/café-svc criado
    implantação.apps/tea criado
    serviço/chá-svc criado
  7. Valide a implantação e os serviços usando o comando kubectl get. Você quer garantir que os Pods estejam aparecendo como PRONTOS e os Serviços estejam aparecendo como em execução . O exemplo abaixo mostra uma amostra representativa do que você está procurando. Observe que o serviço kubernetes é um serviço de sistema executado no mesmo namespace (padrão) do exemplo do NGINX Cafe.
  8. $ kubectl get deployments,services  --namespace default NOME                      PRONTO   ATUALIZADO   DISPONÍVEL   IDADE
    deployment.apps/coffee   2/2     2            2           69s
    deployment.apps/tea      3/3     3            3          68s
    NOME                 TIPO         IP DO CLUSTER       IP EXTERNO   PORTA(S)   IDADE
    service/coffee-svc   ClusterIP   10.128.154.225   <nenhum>        80/TCP    68s
    service/kubernetes   ClusterIP   10.128.0.1       <nenhum>        443/TCP   29m
    serviço/tea-svc      ClusterIP   10.128.96.145    <nenhum>        80/TCP    68s 

Implantar o ClusterIssuer

Dentro do cert-manager, o ClusterIssuer pode ser usado para emitir certificados. Este é 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 certificado definida. Neste exemplo, qualquer solicitação de certificado para certificados Let's Encrypt pode ser manipulada por este ClusterIssuer.

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

Noções básicas sobre o desafio ACME

O protocolo Automated Certificate Management Environment (ACME) é usado para determinar se você possui 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 passados:

  • metadados.nome : O nome do ClusterIssuer, que precisa ser exclusivo na instalação do Kubernetes. Este nome será usado mais tarde no exemplo quando estivermos emitindo um certificado.
  • spec.acme.email : Este é o endereço de e-mail que você está registrando no Let's Encrypt para fins de geração de certificados. Este deve ser seu 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 deixado como está – ele observa o tipo de desafio (ou, como a ACME se refere a ele, solucionador) que você está usando (HTTP-01 ou DNS-01), bem como a qual classe do Ingress ele deve ser aplicado, que neste caso será o nginx.

Usando HTTP-01

Este exemplo mostra como configurar um ClusterIssuer para usar o desafio HTTP-01 para provar a propriedade do domínio e receber um certificado.

  1. Crie o ClusterIssuer usando HTTP-01 para desafios.
  2. $ cat << EOF | kubectl apply -f apiVersão: cert-manager.io/v1
    tipo: ClusterIssuer
    metadados:
      nome: prod-issuer
    spec:
      acme:
        e-mail: example@example.com
        servidor: https://acme-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          nome: prod-issuer-account-key
        solucionadores:
        - http01:
           ingress:
              classe: nginx
    EOF
    clusterissuer.cert-manager.io/prod-issuer criado 
  3. Valide o ClusterIssuer (ele deve aparecer como pronto).
  4. $ kubectl get clusterissuer NOME          PRONTO   IDADE
    prod-issuer   Verdadeiro    34s 

Usando DNS-01

Este exemplo mostra como configurar um ClusterIssuer para usar o desafio DNS-01 para autenticar a propriedade do seu domínio. Dependendo do seu provedor de DNS, você provavelmente precisará usar um Kubernetes Secret para armazenar seu token. Este exemplo usa o Cloudflare . Observe o uso do namespace. O aplicativo cert-manager, que é implantado no namespace cert-manager, precisa ter acesso ao Secret .

Para este exemplo, você precisará de um token da API do Cloudflare , que pode ser criado na sua conta. Isso precisará ser colocado na linha abaixo. Se você não estiver usando o Cloudflare, precisará seguir a documentação do seu provedor .

  1. Crie um segredo para o token da API.
  2. $ cat << EOF | kubectl apply -f apiVersion: v1
    tipo: Segredo
    metadados:
      nome: cloudflare-api-token-secret
      namespace: cert-manager
    tipo: Opaco
    stringData:
      api-token: <API Token> 
    EOF 
  3. Crie o emissor usando DNS-01 para desafios.
  4. $ cat << EOF | kubectl apply -f apiVersão: cert-manager.io/v1
    tipo: ClusterIssuer
    metadados:
      nome: prod-issuer
    especificação:
      acme:
        e-mail: example@example.com
        servidor: https://acme-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          nome: prod-issuer-account-key
        solucionadores:
          - dns01:
              cloudflare:
                 apiTokenSecretRef:
                  nome: cloudflare-api-token-secret
                  chave: api-token
    EOF 
  5. Valide o emissor (ele deve aparecer como pronto).
  6. $ kubectl get clusterissuer NOME          PRONTO   IDADE
    prod-issuer   Verdadeiro    31m 

Implantar o Ingress

Este é o ponto em que estamos construindo – a implantação do recurso Ingress para nosso aplicativo. Isso roteará o tráfego para o aplicativo NGINX Cafe que implantamos anteriormente.

Usando o Ingress do Kubernetes

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

apiVersion: networking.k8s.io/v1 tipo: Ingress
metadados:

nome: cafe-ingress

anotações:

cert-manager.io/cluster-issuer: prod-issuer

acme.cert-manager.io/http01-edit-in-place: "true"

especificação:

ingressClassName: nginx

tls:

- hosts:

cert.example.com

secretName: cafe-secret

regras:

- host: cert.example.com

http:

paths:

path: /tea

Tipo de caminho: Prefixo 
        backend: 
           serviço: 
             nome: tea-svc 
            porta: 
              número: 80 
      - caminho: /café 
        pathType: Prefixo 
        backend: 
           serviço: 
             nome: coffee-svc 
            porta: 
número: 80

Vale a pena rever 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”. Este valor é obrigatório e ajusta a maneira como o desafio é atendido. Para mais informações, consulte o documento Anotações Suportadas . Isso também pode ser resolvido usando uma configuração mestre/servo .
  • O spec.ingressClassName se refere ao controlador NGINX Ingress que instalamos e usaremos.
  • O recurso spec.tls.secret do Kubernetes Secret armazena a chave de certificado que é retornada quando o certificado é emitido pelo Let's Encrypt.
  • Nosso nome de host cert.example.com é especificado para spec.tls.hosts e spec.rules.host . Este é o nome do 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 para a porta 80 no tea-svc .
  1. Modifique o manifesto acima para sua instalação. No mínimo, isso envolverá alterar os valores spec.rules.host e spec.tls.hosts , mas você deve revisar todos os parâmetros na configuração.
  2. Aplique o manifesto.
  3. $  kubectl apply -f ./cafe-virtual-server.yaml virtualserver.k8s.nginx.org/cafe criado 
  4. Aguarde a emissão do certificado. Você está procurando um valor de “True” para o campo READY.
  5. $ kubectl obter certificados NOME                                           PRONTO   SEGREDO        IDADE
    certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m 

Usando o servidor virtual NGINX / rotas virtuais

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

  apiVersion: k8s.nginx.org/v1 
tipo: VirtualServer
metadados:
  nome: cafe
spec:
  host: cert.example.com
  tls:
    segredo: cafe-secret
    cert-manager:
      cluster-issuer: prod-issuer
  upstreams:
  - nome: tea
    serviço: tea-svc
    porta: 80 
  - nome: café 
    serviço: café-svc 
    porta: 80 
  rotas: 
  - caminho: /chá 
    ação: 
      senha: chá 
  - caminho: /café 
    ação: 
senha: café

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

  • A API que está sendo chamada é a k8s.nginx.org/v1 específica do NGINX para o recurso VirtualServer.
  • O recurso spec.tls.secret do Kubernetes Secret armazena a chave de certificado que é retornada quando o certificado é emitido pelo Let's Encrypt.
  • Nosso nome de host cert.example.com é especificado para spec.host . Este é o nome do host para o qual nosso ClusterIssuer emitiu o certificado.
  • Os valores spec.upstreams apontam para nossos serviços de backend, incluindo as portas.
  • O spec.routes define a rota e a ação a ser tomada quando essas rotas são atingidas.
  1. Modifique o manifesto acima para sua instalação. No mínimo, isso envolverá alterar o valor spec.host , mas você deve revisar todos os parâmetros na configuração.
  2. Aplique o manifesto.
  3. $  kubectl apply -f ./cafe-virtual-server.yaml virtualserver.k8s.nginx.org/cafe criado 
  4. Aguarde a emissão do certificado. Você deverá ver o status Válido.
  5. $ kubectl get VirtualServers NOME   ESTADO   HOST                    IP              PORTAS      IDADE
    cafe   Válido   cert.example.com   www.xxx.yyy.zzz   [80.443]   51m 

Ver o Certificado

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

$ kubectl describe secret cafe-secret Nome:         cafe-secret
Espaço para nome:    default
Etiquetas:       <nenhum>
Anotações:  cert-manager.io/nomes-alt: cert.exemplo.com
                cert-manager.io/certificate-name: café-secreto
                cert-manager.io/nome-comum: cert.exemplo.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/emissor-tipo: ClusterIssuer cert-manager.io/issuer-name : prod-issuer cert-manager.io/uri-sans :Tipo: kubernetes.io/tls Dados ==== tls.crt:  5607 bytes tls.key:  1675 bytes 

Se você quiser ver o certificado e a chave reais, pode fazê-lo executando o seguinte comando. (Observação: Isso ilustra uma fraqueza dos segredos do Kubernetes. Ou seja, eles podem ser lidos por qualquer pessoa com as permissões de acesso necessárias.)

$ kubectl obter segredo cafe-secret -o yaml

Teste o Ingress

Teste os certificados. Você pode usar qualquer método que desejar aqui. O exemplo abaixo usa cURL . O sucesso é indicado por um bloco similar ao que é mostrado antes, que inclui o nome do servidor, endereço interno do servidor, data, o URI (rota) escolhido (café ou chá) e o ID da solicitação. Falhas tomarão a forma de códigos de erro HTTP, provavelmente 400 ou 301.

$ curl https://cert.example.com/tea
Endereço do servidor: 10.2.0.6:8080
Nome do servidor: tea-5c457db9-l4pvq
Data: 02/Set/2022:15:21:06 +0000
URI: /tea
ID da solicitação: d736db9f696423c6212ffc70cd7ebecf
$ curl https://cert.example.com/coffee
Endereço do servidor: 10.2.2.6:8080
Nome do servidor: coffee-7c86d7d67c-kjddk
Data: 02/Set/2022:15:21:10 +0000
URI: /coffee
ID da solicitação: 4ea3aa1c87d2f1d80a706dde91f31d54 

Renovações de Certificados

No início, prometemos que essa abordagem eliminaria a necessidade de gerenciar renovações de certificados. No entanto, ainda precisamos explicar como fazer isso. Porquê?Porque esta é uma parte central e integrada do cert-manager. Neste processo automático, quando o cert-manager percebe que um certificado não está presente, expirou, está a 15 dias do vencimento ou se o usuário solicita um novo certificado via CLI, um novo certificado é solicitado automaticamente . Não fica muito mais fácil do que isso.

Perguntas frequentes

E quanto ao NGINX Plus?

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

Que tipo de desafio devo usar?

Isso depende muito do seu caso de uso.

O método de desafio HTTP-01 requer que a porta 80 esteja aberta para a Internet e que o registro DNS A tenha sido configurado corretamente para o endereço IP do controlador Ingress. Essa abordagem não requer acesso ao provedor de DNS além da criação do registro A.

O método de desafio DNS-01 pode ser usado quando você não pode expor a Porta 80 à Internet e requer apenas que o gerenciador de certificados 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 posso solucionar problemas?

Como o Kubernetes é tão complexo, é difícil fornecer informações específicas para solução de problemas. Caso você tenha algum problema, gostaríamos de convidá-lo a nos perguntar no NGINX Community Slack (assinantes do NGINX Plus podem usar suas opções normais 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 sempre gratuito.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."