Automatización de la gestión de certificados en un entorno de Kubernetes

NGINX | 05 de octubre de 2022

Los certificados SSL/TLS válidos son un requisito fundamental en el panorama actual de las aplicaciones. Por desgracia, la gestión de la renovación de certificados suele dejarse para más adelante al implementar una aplicación. Los certificados tienen una vida útil limitada, que oscila entre aproximadamente 13 meses para los certificados de DigiCert y 90 días para los certificados de Let’s Encrypt. Para mantener un acceso seguro, estos certificados deben renovarse o volver a emitirse antes de que caduquen. Dada la considerable carga de trabajo de la mayoría de los equipos de Operaciones, a veces la renovación de certificados se pasa por alto, lo que obliga a actuar a contrarreloj cuando se acerca su fecha de caducidad o, peor aún, cuando ya ha pasado.

No tiene por qué ser así. Con algo de planificación y preparación, la gestión de certificados puede automatizarse y simplificarse. A continuación, veremos una solución para Kubernetes que utiliza tres tecnologías:

En este blog, aprenderás a simplificar la gestión de certificados proporcionando a tus endpoints certificados únicos que se renuevan y actualizan automáticamente.

Certificados en un entorno de Kubernetes

Antes de entrar en detalles técnicos, debemos definir algunos términos. El término «certificado TLS» hace referencia a dos componentes necesarios para habilitar las conexiones HTTPS en nuestro controlador Ingress:

El certificado
La clave privada

Tanto el certificado como la clave privada son emitidos por Let’s Encrypt. Para obtener una explicación completa sobre cómo funcionan los certificados TLS, consulte el artículo de DigiCert «Cómo funcionan los certificados TLS/SSL».

En Kubernetes, estos dos componentes se almacenan como Secretos. Las cargas de trabajo de Kubernetes, como el controlador de entrada NGINX y cert-manager, pueden escribir y leer estos Secretos, que también pueden gestionar los usuarios que tengan acceso a la instalación de Kubernetes.

Presentación de cert-manager

El proyecto cert-manager es un controlador de certificados compatible con Kubernetes y OpenShift. Cuando se implementa en Kubernetes, cert-manager emite automáticamente los certificados que necesitan los controladores Ingress y garantiza que sean válidos y estén actualizados. Además, realiza un seguimiento de las fechas de caducidad de los certificados e intenta renovarlos en el intervalo de tiempo configurado. Aunque funciona con numerosos emisores públicos y privados, mostraremos su integración con Let’s Encrypt.

Dos tipos de desafío

Al utilizar Let’s Encrypt, toda la gestión de los certificados se realiza automáticamente. Aunque esto resulta muy práctico, también plantea un problema: ¿cómo se asegura el servicio de que usted es el propietario del nombre de dominio completo (FQDN) en cuestión?

Este problema se resuelve mediante un desafío, que requiere responder a una solicitud de verificación que solo puede atender alguien con acceso a los registros DNS del dominio específico. Los desafíos pueden adoptar una de estas dos formas:

HTTP-01: Este desafío se puede superar si se dispone de un registro DNS para el FQDN para el que se está emitiendo un certificado. Por ejemplo, si su servidor se encuentra en la dirección IP www.xxx.yyy.zzz y su FQDN es cert.example.com, el mecanismo del desafío expondrá un token en el servidor ubicado en www.xxx.yyy.zzz y los servidores de Let’s Encrypt intentarán acceder a él a través de cert.example.com. Si lo consiguen, el desafío se supera y se emite el certificado. HTTP-01 es la forma más sencilla de generar un certificado, ya que no requiere acceso directo al proveedor de DNS. Este tipo de desafío siempre se lleva a cabo a través del puerto 80 (HTTP). Tenga en cuenta que, al utilizar desafíos HTTP-01, cert-manager empleará el controlador Ingress para servir el token del desafío.

DNS-01: Este desafío crea un registro TXT de DNS con un token que, a continuación, verifica el emisor. Si se reconoce el token, habrá demostrado que es el propietario de ese dominio y podrá emitir certificados para sus registros. A diferencia del desafío HTTP-01, al utilizar el desafío DNS-01, no es necesario que el FQDN se resuelva en la dirección IP de su servidor (ni siquiera que exista). Además, DNS-01 puede utilizarse cuando el puerto 80 está bloqueado. La contrapartida de esta facilidad de uso es la necesidad de proporcionar a la instalación de cert-manager acceso a su infraestructura DNS mediante un token de API.

Controladores de ingreso

Un controlador de Ingress es un servicio especializado para Kubernetes que recibe tráfico del exterior del clúster, lo distribuye entre los pods internos (un grupo de uno o más contenedores) y gestiona el tráfico saliente. Además, el controlador de Ingress se controla mediante la API de Kubernetes y supervisa y actualiza la configuración del balanceo de carga a medida que se añaden o eliminan pods, o cuando estos fallan.

Para obtener más información sobre los controladores de Ingress, consulta los siguientes blogs:

En los siguientes ejemplos, utilizaremos NGINX Ingress Controller, desarrollado y mantenido por F5 NGINX.

Ejemplos de gestión de certificados

Estos ejemplos presuponen que dispone de una instalación operativa de Kubernetes con la que puede realizar pruebas y que dicha instalación puede asignar una dirección IP externa (objeto LoadBalancer de Kubernetes). Además, se presupone que puede recibir tráfico tanto en el puerto 80 como en el puerto 443 (si utiliza el desafío HTTP-01), o únicamente en el puerto 443 (si utiliza el desafío DNS-01). Estos ejemplos se muestran utilizando Mac OS X, pero también pueden usarse en Linux o WSL.

También necesitará un proveedor de DNS y un FQDN cuyo registro A pueda modificar. Si utiliza el desafío HTTP-01, solo necesita poder añadir un registro A (o que alguien lo añada por usted). Si utiliza el desafío DNS-01, necesitará acceso mediante API a un proveedor de DNS compatible o a un proveedor de webhooks compatible.

Desplegar NGINX Ingress Controller

La forma más sencilla es realizar el despliegue mediante Helm. Este despliegue permite utilizar tanto el Ingress de Kubernetes como el CRD VirtualServer de NGINX.

Añade el repositorio de NGINX.

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

Actualiza el repositorio.

$ 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!⎈

Despliega el 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.

Compruebe el despliegue y obtenga la dirección IP de salida del controlador Ingress. Tenga en cuenta que no puede continuar sin una dirección IP válida.

$ 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

Añade tu registro A de DNS

El proceso dependerá de su proveedor de DNS. Este nombre DNS deberá poder resolverse desde los servidores de Let’s Encrypt, por lo que es posible que tenga que esperar a que el registro se propague antes de que funcione. Para obtener más información al respecto, consulte el artículo de SiteGround ¿Qué es la propagación de DNS y por qué tarda tanto?

Una vez que pueda resolver el FQDN elegido, estará listo para continuar con el siguiente paso.

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

Desplegar cert-manager

El siguiente paso es desplegar la versión más reciente de cert-manager. De nuevo, utilizaremos Helm para el despliegue.

Añade el repositorio de Helm.

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

Actualiza el repositorio.

$ 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!⎈

Despliega 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/

Valida la implementación.

$ 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

Implementar el ejemplo NGINX Cafe

Vamos a utilizar el ejemplo NGINX Cafe para proporcionar el despliegue y los servicios de nuestro backend. Se trata de un ejemplo habitual en la documentación de NGINX. No desplegaremos Ingress como parte de este proceso.

Clona el proyecto NGINX Ingress de 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.

Cambie al directorio examples. Este directorio contiene varios ejemplos que muestran distintas configuraciones del controlador Ingress. Utilizaremos el ejemplo incluido en el directorio complete-example.

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

Despliega el ejemplo de NGINX Cafe.

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

Valide el despliegue y los servicios mediante el comando kubectl get. Asegúrese de que los pods aparezcan como READY y los servicios como running. El siguiente ejemplo muestra una muestra representativa de lo que debe comprobar. Tenga en cuenta que el servicio kubernetes es un servicio del sistema que se ejecuta en el mismo espacio de nombres (default) que el ejemplo de 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

Desplegar el ClusterIssuer

En cert-manager, el ClusterIssuer se puede utilizar para emitir certificados. Se trata de un objeto con ámbito de clúster al que se puede hacer referencia desde cualquier espacio de nombres y que puede utilizarse en cualquier solicitud de certificado con la autoridad emisora de certificados definida. En este ejemplo, este ClusterIssuer puede gestionar cualquier solicitud de certificados de Let’s Encrypt.

Despliega el ClusterIssuer para el tipo de desafío que hayas seleccionado. Aunque queda fuera del alcance de este artículo, existen opciones de configuración avanzadas que permiten especificar varios resolutores (elegidos en función de los campos de selector) en tu ClusterIssuer.

Conceptos básicos de los desafíos ACME

El protocolo Automated Certificate Management Environment (ACME) se utiliza para determinar si eres el propietario de un nombre de dominio y, por tanto, si se te puede emitir un certificado de Let’s Encrypt. Para este desafío, deben proporcionarse los siguientes parámetros:

metadata.name: el nombre del ClusterIssuer, que debe ser único dentro de la instalación de Kubernetes. Este nombre se utilizará más adelante en el ejemplo cuando emitamos un certificado.
spec.acme.email: Esta es la dirección de correo electrónico que va a registrar en Let’s Encrypt para generar certificados. Debe ser su dirección de correo electrónico.
spec.acme.privateKeySecretRef: Este es el nombre del secreto de Kubernetes que utilizará para almacenar su clave privada.
spec.acme.solvers: Debe dejarse tal cual, ya que indica el tipo de desafío (o «solucionador», como lo denomina ACME) que se está utilizando (HTTP-01 o DNS-01), así como la clase de Ingress a la que debe aplicarse, que en este caso será nginx.

Uso de HTTP-01

Este ejemplo muestra cómo configurar un ClusterIssuer para que utilice el desafío HTTP-01 a fin de demostrar la propiedad del dominio y obtener un certificado.

Crea el ClusterIssuer utilizando HTTP-01 para los desafíos.

$ 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

Valida el ClusterIssuer (debería aparecer como listo).

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

Uso de DNS-01

Este ejemplo muestra cómo configurar un ClusterIssuer para que utilice el desafío DNS-01 a fin de verificar que el dominio es de su propiedad. Según su proveedor de DNS, probablemente tendrá que usar un Secret de Kubernetes para almacenar su token. En este ejemplo se utiliza Cloudflare. Tenga en cuenta el uso del espacio de nombres. La aplicación cert-manager, que está desplegada en el espacio de nombres cert-manager, debe tener acceso al Secret.

Para este ejemplo, necesitarás un token de API de Cloudflare, que puedes crear desde tu cuenta. Deberás introducirlo en la línea <API Token> que aparece a continuación. Si no utilizas Cloudflare, deberás seguir la documentación de tu proveedor.

Crea un secreto para el token de 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

Crea el emisor utilizando DNS-01 para los desafíos.

$ 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

Valida el emisor (debería aparecer como listo).

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

Desplegar el Ingress

Este es el momento para el que nos hemos estado preparando: el despliegue del recurso Ingress para nuestra aplicación. Este dirigirá el tráfico a la aplicación NGINX Cafe que desplegamos anteriormente.

Uso del Ingress de Kubernetes

Si utiliza el recurso Ingress estándar de Kubernetes, deberá usar el siguiente YAML de despliegue para configurar el Ingress y solicitar un 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

Conviene revisar algunas partes clave del manifiesto:

La API a la que se llama es la API Ingress estándar de Kubernetes.
Una parte clave de esta configuración se encuentra en metadata.annotations, donde establecemos acme.cert-manager.io/http01-edit-in-place en «true». Este valor es obligatorio y modifica la forma en que se presenta el desafío. Para obtener más información, consulte el documento sobre anotaciones compatibles. Esto también se puede gestionar mediante una configuración maestro/minion.
El campo spec.ingressClassName hace referencia al controlador NGINX Ingress que hemos instalado y que utilizaremos.
El recurso Secret de Kubernetes spec.tls.secret almacena la clave del certificado que se devuelve cuando Let’s Encrypt emite el certificado.
Nuestro nombre de host cert.example.com se especifica en spec.tls.hosts y spec.rules.host. Este es el nombre de host para el que nuestro ClusterIssuer emitió el certificado.
La sección spec.rules.http define las rutas y los servicios de backend que atenderán las solicitudes en dichas rutas. Por ejemplo, el tráfico dirigido a /tea se enviará al puerto 80 de tea-svc.

Modifique el manifiesto anterior para adaptarlo a su instalación. Como mínimo, deberá cambiar los valores de spec.rules.host y spec.tls.hosts, pero debería revisar todos los parámetros de la configuración.
Aplique el manifiesto.

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

Espera a que se emita el certificado. El campo READY debe tener el valor «True».

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

Uso del servidor virtual y las rutas virtuales de NGINX

Si utiliza los CRD de NGINX, deberá usar el siguiente YAML de despliegue para configurar su 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

Una vez más, conviene repasar algunas partes clave del manifiesto:

La API a la que se llama es k8s.nginx.org/v1, específica de NGINX, para el recurso VirtualServer.
El recurso Secret de Kubernetes spec.tls.secret almacena la clave del certificado que se devuelve cuando Let’s Encrypt emite el certificado.
Nuestro nombre de host cert.example.com se especifica en spec.host. Este es el nombre de host para el que nuestro ClusterIssuer emitió el certificado.
Los valores de spec.upstreams apuntan a nuestros servicios de backend, incluidos los puertos.
El campo spec.routes define tanto la ruta como la acción que se debe realizar cuando se accede a dichas rutas.

Modifique el manifiesto anterior para adaptarlo a su instalación. Como mínimo, deberá cambiar el valor de spec.host, pero conviene revisar todos los parámetros de la configuración.
Aplica el manifiesto.

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

Espera a que se emita el certificado. Deberías ver el estado Válido.

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

Ver el certificado

Puedes consultar el certificado a través de la API de Kubernetes. Esto te mostrará información detallada sobre el certificado, incluido su tamaño y la clave privada asociada.

$ 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

Si quieres ver el certificado y la clave reales, puedes hacerlo ejecutando el siguiente comando. (Nota: Esto pone de manifiesto una debilidad de los secretos de Kubernetes: cualquiera que disponga de los permisos de acceso necesarios puede leerlos).

$ kubectl get secret cafe-secret -o yaml

Prueba el Ingress

Pruebe los certificados. Puede utilizar el método que prefiera. El siguiente ejemplo utiliza cURL. Si la prueba se realiza correctamente, se mostrará un bloque similar al anterior, que incluye el nombre del servidor, su dirección interna, la fecha, el URI (ruta) elegido (café o té) y el ID de la solicitud. Los fallos se mostrarán como códigos de error HTTP, probablemente 400 o 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

Renovaciones de certificados

Al principio, prometimos que este enfoque eliminaría la necesidad de gestionar las renovaciones de certificados. Sin embargo, aún no hemos explicado cómo se consigue. ¿Por qué? Porque se trata de una función esencial integrada en cert-manager. En este proceso automático, cuando cert-manager detecta que no hay ningún certificado, que ha caducado, que faltan 15 días o menos para que caduque, o que el usuario solicita uno nuevo mediante la CLI, se solicita automáticamente un nuevo certificado. No puede ser mucho más sencillo.

Preguntas frecuentes

¿Y NGINX Plus?

Si es suscriptor de NGINX Plus, la única diferencia en su caso estará relacionada con la instalación de NGINX Ingress Controller. Consulte la sección Instalación con Helm de la documentación de NGINX para obtener instrucciones sobre cómo modificar el comando de Helm indicado anteriormente para hacerlo.

¿Qué tipo de desafío debo usar?

Esto depende en gran medida de tu caso de uso.

El método de desafío HTTP-01 requiere que el puerto 80 esté abierto a Internet y que el registro A de DNS esté correctamente configurado para la dirección IP del controlador Ingress. Este enfoque no requiere acceso al proveedor de DNS, salvo para crear el registro A.

El método de desafío DNS-01 se puede utilizar cuando no es posible exponer el puerto 80 a Internet y solo requiere que cert-manager tenga acceso saliente al proveedor de DNS. Sin embargo, este método sí requiere acceso a la API del proveedor de DNS, aunque el nivel de acceso necesario varía según el proveedor.

¿Cómo puedo solucionar problemas?

Dada la complejidad de Kubernetes, es difícil proporcionar información específica para solucionar problemas. Si tiene algún problema, le invitamos a consultarnos en el Slack de la comunidad de NGINX (los suscriptores de NGINX Plus pueden utilizar sus opciones de soporte habituales).

Empieza hoy mismo

Empieza solicitando tu prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS, y descarga NGINX Service Mesh, que es gratuito para siempre.