One place for hosting & domains

      CertManager

      What is Kubernetes cert-manager?


      Updated by Linode Contributed by Linode

      What is cert manager?

      Cert-manager is a Kubernetes add-on designed to assist with the creation and management of TLS certificates. Similar to Certbot, cert-manager can automate the process of creating and renewing self-signed and signed certificates for a large number of use cases, with a specific focus on container orchestration tools like Kubernetes.

      Note

      This guide assumes a working knowledge of Kubernetes key concepts, including master and worker nodes, Pods, Deployments, and Services. For more information on Kubernetes, see our Beginner’s Guide to Kubernetes series.

      Understanding Cert Manager Concepts

      Cert-Manager is divided into a number of components and microservices that are each designed to perform specific tasks necessary for the certificate lifecycle.

      Issuers and ClusterIssuers

      Certificate creation begins with Issuers and ClusterIssuers, resources that represent certificate authorities and are able to generate signed certificates using a specific issuer type. An issuer type represents the method used to create your certificate, such as SelfSigned for a Self-Signed Certificate and ACME for requests for certificates from ACME servers, typically used by tools like Let’s Encrypt. All supported issuer types are listed in Cert-Manager’s Documentation.

      While Issuers resources are only able to create certificates in the namespace they were created in, ClusterIssuers can create certificates for all namespaces. This guide provides an example that demonstrates how ClusterIssuers creates certificates for all namespaces in the cluster.

      Certificates and CertificateRequests

      Although Issuers are responsible for defining the method used to create a certificate, a Certificate resource must also be created to define how a certificate is renewed and kept up to date.

      After a Certificate resource is created, changed, or a certificate referenced needs renewal, cert-manager creates a corresponding CertificateRequest resource, which contains the base64 encoded string of an x509 certificate request (CSR). Additionally, if successful, it contains the signed certificate where one is successfully returned and updates the Ready condition status to True.

      Note

      A CertificateRequest resource is not designed to interact with a user directly, and instead is utilized through controllers or similar methods where needed.

      ACME Orders and Challenges

      For external certificates from ACME servers, cert-manager must be able to solve ACME challenges in order to prove ownership of DNS names and addresses being requested.

      An Order resource represents and encapsulates the multiple ACME challenges the certificate request requires for domain validation. The Order resource is created automatically when a CertificateRequest referencing an ACME Issuer or has been created.

      Challenge resources represent all of the steps in an ACME challenge that must be completed for domain validation. Although defined by the Order, a separate Challenge resource is created for each DNS name that is being validated, and each are scheduled separately.

      ACME Order and Challenge resources are only created for Issuers and ClusterIssuers with a type of ACME.

      Note

      An order or challenge resource is never manually created directly by a user and are instead defined through CertificateRequest resources and the Issuers type. After it is issued, order and challenge resources cannot be changed.

      This feature includes the ability to request certificates through Let’s Encrypt.

      Installing Cert-Manager

      Cert-Manager can be easily installed through a single command as follows:

      kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.yaml
      

      As the installation completes, you should see a number of required resources created, including a cert-manager namespace, RBAC rules, CRD’s, and a webhook component. To confirm that the installation was a success, enter the following:

      kubectl get pods --namespace cert-manager
      

      The output is similar to the following:

        
      NAME                                       READY   STATUS    RESTARTS   AGE
      cert-manager-766d5c494b-l9sdb              1/1     Running   0          19m
      cert-manager-cainjector-6649bbb695-bz999   1/1     Running   0          19m
      cert-manager-webhook-68d464c8b-86tqw       1/1     Running   0          19m
      
      

      Next Steps

      To learn how to apply some of the concepts learned in this guide, see the Configuring Load Balancing with TLS Encryption on a Kubernetes Cluster guide.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      Deploy and Manage Cert-Manager on Kubernetes


      Updated by Linode Contributed by Linode

      Marquee image for Deploy and Manage Cert-Manager on Kubernetes

      What is cert manager

      Cert-manager is a Kubernetes add-on designed to assist with the creation and management of TLS certificates. Similar to Certbot, cert-manager can automate the process of creating and renewing self-signed and signed certificates for a large number of use cases, with a specific focus on container orchestration tools like Kubernetes.

      In This Guide

      In this guide, you will learn about how cert-manager works to create certificates, the options available for creating certificates, and then use cert-manager to create two public signed certificates using only Kubernetes and cert-manager tooling.

      Before you Begin

      • Follow our guide to Deploying an Ingress. The final example of this guide uses the same configuration, cluster, and domains.
      • You should have a working knowledge of Kubernetes’ key concepts, including master and worker nodes, Pods, Deployments, and Services. For more information on Kubernetes, see our Beginner’s Guide to Kubernetes series.

      Understanding Cert Manager Concepts

      Cert-Manager is divided into a number of components and microservices that are each designed to perform specific tasks necessary for the certificate lifecycle.

      Issuers and ClusterIssuers

      Certificate creation begins with Issuers and ClusterIssuers, resources that represent certificate authorities and are able to generate signed certificates using a specific issuer type. An issuer type represents the method used to create your certificate, such as SelfSigned for a Self-Signed Certificate and ACME for requests for certificates from ACME servers, typically used by tools like Let’s Encrypt. All supported issuer types are listed in Cert-Manager’s Documentation.

      While Issuers resources are only able to create certificates in the namespace they were created in, ClusterIssuers can create certificates for all namespaces. This guide provides an example that demonstrates how ClusterIssuers creates certificates for all namespaces in the cluster.

      Certificates and CertificateRequests

      Although Issuers are responsible for defining the method used to create a certificate, a Certificate resource must also be created to define how a certificate is renewed and kept up to date.

      After a Certificate resource is created, changed, or a certificate referenced needs renewal, cert-manager creates a corresponding CertificateRequest resource, which contains the base64 encoded string of an x509 certificate request (CSR). Additionally, if successful, it contains the signed certificate where one is successfully returned and updates the Ready condition status to True.

      Note

      A CertificateRequest resource is not designed to interact with a user directly, and instead is utilized through controllers or similar methods where needed.

      ACME Orders and Challenges

      For external certificates from ACME servers, cert-manager must be able to solve ACME challenges in order to prove ownership of DNS names and addresses being requested.

      An Order resource represents and encapsulates the multiple ACME challenges the certificate request requires for domain validation. The Order resource is created automatically when a CertificateRequest referencing an ACME Issuer or has been created.

      Challenge resources represent all of the steps in an ACME challenge that must be completed for domain validation. Although defined by the Order, a separate Challenge resource is created for each DNS name that is being validated, and each are scheduled separately.

      ACME Order and Challenge resources are only created for Issuers and ClusterIssuers with a type of ACME.

      Note

      An order or challenge resource is never manually created directly by a user and are instead defined through CertificateRequest resources and the Issuers type. After it is issued, order and challenge resources cannot be changed.

      This feature includes the ability to request certificates through Let’s Encrypt.

      Installing Cert-Manager

      Cert-Manager can be easily installed through a single command as follows:

      kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.yaml
      

      As the installation completes, you should see a number of required resources created, including a cert-manager namespace, RBAC rules, CRD’s, and a webhook component. To confirm that the installation was a success, enter the following:

      kubectl get pods --namespace cert-manager
      

      The output is similar to the following:

        
      NAME                                       READY   STATUS    RESTARTS   AGE
      cert-manager-766d5c494b-l9sdb              1/1     Running   0          19m
      cert-manager-cainjector-6649bbb695-bz999   1/1     Running   0          19m
      cert-manager-webhook-68d464c8b-86tqw       1/1     Running   0          19m
      
      

      Using Cert-Manager to Create Certificates

      The following example creates an ACME certificate signed using Let’s Encrypt.

      To begin, define a ClusterIssuer resource manually, replacing [email protected] with your own personal email address which is used for ACME registration:

      my-new-issuer.yaml
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      
      apiVersion: cert-manager.io/v1alpha2
      kind: ClusterIssuer
      metadata:
        name: letsencrypt-certmanager
      spec:
        acme:
          # Replace this e-mail with your own to be used for ACME registration
          email: [email protected]
          server: https://acme-v02.api.letsencrypt.org/directory
          privateKeySecretRef:
            name: letsencrypt-private-key
          # Add a single challenge solver, HTTP01 using nginx
          solvers:
          - http01:
              ingress:
                class: nginx

      In the above example, note that privateKeySecretRef attribute creates a secret resource using the specified name for storing the private key of the account.

      Then enter the following to create the resource:

      kubectl create -f my-new-issuer.yaml
      

      You should see a confirmation message that the resource was successfully created.

      Finally, edit your Ingress to include the annotation for the cert-manager resource, add the tls block to define the domains that need certificates, and the name of the privateKeySecretRef in the secretName field.

      my-new-ingress.yaml
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      
      metadata:
        name: my-new-ingress
        annotations:
          kubernetes.io/ingress.class: nginx
          cert-manager.io/cluster-issuer: letsencrypt-certmanager
      spec:
        tls:
        - hosts:
          - shop.example.com
          - blog.example.com
          secretName: letsencrypt-private-key
        rules:
        - host: shop.example.com
          http:
            paths:
            - backend:
                serviceName: hello-one
                servicePort: 80
        - host: blog.example.com
          http:
            paths:
            - backend:
                serviceName: hello-two
                servicePort: 80

      After you have completed the configuration, apply it with the following:

      kubectl apply -f my-new-ingress.yaml
      

      Note

      In the my-new-issuer.yaml the http01 stanza specifies that the ACME challenge is performed through the HTTP-01 challenge type. For more information on how this works, see Let’s Encrypt’s documentation

      Now that the resource has been applied, you may now navigate to your subdomains https://blog.example.com and https://shop.example.com to see them resolve using SSL/TLS encryption.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      Cómo configurar un Ingress de Nginx con Cert-Manager en Kubernetes de DigitalOcean


      Introducción

      Los Ingress de Kubernetes le permiten dirigir de manera flexible el tráfico del exterior de su clúster de Kubernetes a servicios dentro de su clúster. Esto se realiza usando recursos de Ingress, que definen reglas para dirigir el tráfico HTTP y HTTPS a servicios de Kubernetes, y controladores de Ingress, que implementan las reglas equilibrando la carga de tráfico y dirigiéndola a los servicios de backend correspondientes. Entre los controladores populares de Ingress se incluyen Nginx, Contour, HAProxy y Traefik. Los Ingress ofrecen una alternativa más eficiente y flexible para configurar varios servicios de LoadBalancer, cada uno de los cuales utiliza su propio equilibrador de cargas dedicado.

      En esta guía, configuraremos el controlador de Ingress de Nginx mantenido por Kubernetes y crearemos algunos recursos de Ingress para dirigir el tráfico a varios servicios de backend ficticios. Una vez que configuremos el Ingress, instalaremos cert-manager en nuestro clúster para administrar y proporcionar certificados TLS, a fin de cifrar el tráfico de HTTP en el Ingress.

      Requisitos previos

      Antes de comenzar con esta guía, asegúrese de contar con lo siguiente:

      • Un clúster de Kubernetes 1.10, o una versión posterior, con control de acceso basado en roles (RBCA) activado
      • La herramienta de línea de comandos kubectl instalada en su equipo local y configurada para conectarse a su clúster. Puede leer más sobre la instalación de kubectl en la documentación oficial.
      • Un nombre de dominio y registros DNS A que puede orientar al equilibrador de cargas de DigitalOcean utilizado por el Ingress. Si usa DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros A.
      • El administrador de paquetes de Helm instalado en su computadora local y Tiller instalado en su clúster, como se detalla en Cómo instalar software en clústeres de Kubernetes con el administrador de paquetes de Helm. Asegúrese de utilizar Helm v2.12.1 o una versión posterior. De lo contrario, podría experimentar problemas al instalar el chart de Helm de cert-manager. Para comprobar la versión de Helm que instaló, ejecute helm version en su máquina local.
      • La utilidad de línea de comandos wget instalada en su equipo local. Puede instalar wget usando el administrador de paquetes incorporado en su sistema operativo.

      Cuando tenga estos componentes configurados, estará listo para comenzar con esta guía.

      Paso 1: Configurar servicios de backend ficticios

      Antes de implementar el controlador de Ingress, crearemos e implementaremos primero dos servicios echo ficticios a los que dirigiremos el tráfico externo usando el Ingress. Los servicios echo ejecutan el contenedor del servidor web hashicorp/http-echo, el cual muestra una página que contiene una cadena de texto transmitida cuando se inicia el servidor web. Para obtener más información sobre http-echo, consulte su repositorio de GitHub y para obtener más información sobre los Servicios de Kubernetes, consulte Servicios en los documentos oficiales de Kubernetes.

      En su equipo local, cree y edite un archivo llamado echo1.yaml usando nano o su editor favorito:

      Pegue el siguiente manifiesto de servicio e implementación:

      echo1.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: echo1
      spec:
        ports:
        - port: 80
          targetPort: 5678
        selector:
          app: echo1
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: echo1
      spec:
        selector:
          matchLabels:
            app: echo1
        replicas: 2
        template:
          metadata:
            labels:
              app: echo1
          spec:
            containers:
            - name: echo1
              image: hashicorp/http-echo
              args:
              - "-text=echo1"
              ports:
              - containerPort: 5678
      

      En este archivo, definimos un servicio llamado echo1 que dirige el tráfico hacia los Pods con el selector de etiquetas app: echo1. Acepta el tráfico de TCP en el puerto 80 y lo dirige al puerto 5678, el predeterminado de http-echo.

      A continuación, definimos una implementación, también llamada echo1, que administra los Pods con el selector de etiquetas app: echo1. Especificamos que la implementación debe tener 2 réplicas de Pods y que los Pods deben iniciar un contenedor llamado echo1 ejecutando la imagen hashicorp/http-echo. Especificamos el parámetro text y lo fijamos en echo1, para que el servidor web http-echo muestre echo1. Por último, abrimos el puerto 5678 en el contenedor de Pods.

      Una vez que esté satisfecho con su servicio ficticio y manifiesto de implementación, guarde y cierre el archivo.

      A continuación, cree los recursos de Kubernetes usando kubectl create con el indicador -f y especificando el archivo que acaba de guardar como un parámetro:

      • kubectl create -f echo1.yaml

      Debería ver el siguiente resultado:

      Output

      service/echo1 created deployment.apps/echo1 created

      Verifique que el servicio se haya iniciado de manera correcta confirmando que este tenga un ClusterIP, el IP interno en el que se expone el servicio:

      Debería ver el siguiente resultado:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echo1 ClusterIP 10.245.222.129 <none> 80/TCP 60s

      Esto indica que el servicio echo1 ahora se encuentra disponible de manera interna en 10.245.222.129 en el puerto 80. Reenviará el tráfico al containerPort 5678 en los Pods que seleccione.

      Ahora que el servicio echo1 está activo y en ejecución, repita este proceso para el servicio echo2.

      Cree y abra un archivo llamado echo2.yaml:

      echo2.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: echo2
      spec:
        ports:
        - port: 80
          targetPort: 5678
        selector:
          app: echo2
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: echo2
      spec:
        selector:
          matchLabels:
            app: echo2
        replicas: 1
        template:
          metadata:
            labels:
              app: echo2
          spec:
            containers:
            - name: echo2
              image: hashicorp/http-echo
              args:
              - "-text=echo2"
              ports:
              - containerPort: 5678
      

      Aquí, básicamente utilizamos el mismo manifiesto de servicio e implementación de arriba, pero asignamos el nombre y la nueva etiqueta echo2 al servicio y a la implementación. Además, para proporcionar variedad, creamos solo una réplica de Pod. Nos aseguramos de fijar el parámetro de text en echo2 para que el servidor web muestre el texto echo2.

      Guarde y cierre el archivo, y cree los recursos de Kubernetes usando kubectl:

      • kubectl create -f echo2.yaml

      Debería ver el siguiente resultado:

      Output

      service/echo2 created deployment.apps/echo2 created

      Una vez más, compruebe que el servicio esté activo y en ejecución:

      Debería ver ambos servicios echo1 y echo2 con ClusterIP asignados:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echo1 ClusterIP 10.245.222.129 <none> 80/TCP 6m6s echo2 ClusterIP 10.245.128.224 <none> 80/TCP 6m3s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 4d21h

      Ahora que nuestros servicios web ficticios de echo están activos y en ejecución, podemos implementar el controlador de Ingress de Nginx.

      Paso 2: Configurar el controlador de Ingress de Nginx en Kubernetes

      En este paso, implementaremos v0.24.1 del controlador de Ingress de Nginx mantenido por Kubernetes. Tenga en cuenta que hay varios controladores de Ingress de Nginx; la comunidad de Kubernetes mantiene el que utilizamos en esta guía y Nginx Inc. mantiene kubernetes-ingress. Las instrucciones de este tutorial están basadas en las de la Guía de instalación oficial del controlador de Ingress de Nginx en Kubernetes.

      El controlador de Ingress de Nginx consta de un Pod que ejecuta el servidor web de Nginx y verifica el panel de control de Kubernetes en busca de objetos de recursos de Ingress nuevos y actualizados. Un recurso de Ingress es esencialmente una lista de reglas de enrutamiento de tráfico para los servicios de backend. Por ejemplo, una regla de Ingress puede especificar que el tráfico HTTP que llegue a la ruta /web1 deberá dirigirse hacía el servidor web de backend web1. Utilizando los recursos de Ingress, también puede aplicar enrutamiento basado en host: por ejemplo, dirigir las solicitudes que llegan de web1.yoyour_domain.com al servicio de backend de Kubernetes web1.

      En este caso, debido a que implementamos el controlador de Ingress en un clúster de Kubernetes de DigitalOcean, el controlador creará un servicio LoadBalancer que hará aparecer un equilibrador de carga de DigitalOcean al cual se dirigirá todo el tráfico externo. Este equilibrador de carga dirigirá el tráfico externo al Pod del controlador de Ingress ejecutando Nginx, que posteriormente reenviará el tráfico a los servicios de backend correspondientes.

      Comenzaremos creando primero los recursos de Kubernetes requeridos por el controlador de Ingress de Nginx. Estos consisten en ConfigMaps que contienen la configuración del controlador, roles de control de acceso basado en roles (RBAC) para otorgar al controlador acceso a la API de Kubernetes y la implementación real del controlador Ingress que utiliza v0.24.1 de la imagen del controlador de Ingress de Nginx. Para ver una lista completa de estos recursos necesarios, consulte el manifiesto del repositorio GitHub del controlador de Ingress de Nginx en Kubernetes.

      Para crear estos recursos obligatorios, utilice kubectl apply y el indicador -f para especificar el archivo de manifiesto alojado en GitHub:

      • kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml

      En este caso, utilizamos apply en lugar de create para que en el futuro podamos implementar cambios apply en incrementos a los objetos del controlador de Ingress en lugar de sobrescribirlos por completo. Para obtener más información sobre apply, consulte Recursos de administración de los documentos oficiales de Kubernetes.

      Debería ver el siguiente resultado:

      Output

      namespace/ingress-nginx created configmap/nginx-configuration created configmap/tcp-services created configmap/udp-services created serviceaccount/nginx-ingress-serviceaccount created clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created role.rbac.authorization.k8s.io/nginx-ingress-role created rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created deployment.extensions/nginx-ingress-controller created

      Este resultado también sirve como un resumen práctico de todos los objetos del controlador de Ingress creados a partir del manifiesto mandatory.yaml.

      A continuación, crearemos el servicio LoadBalancer del controlador de Ingress, el cual creará un equilibrador de carga de DigitalOcean que equilibrará la carga y dirigirá el tráfico HTTP y HTTPS al Pod del controlador de Ingress implementado en el comando anterior.

      Para crear el servicio LoadBalancer, una vez más utilice kubectl apply en un archivo de manifiesto que contenga la definición del servicio:

      • kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml

      Debería ver el siguiente resultado:

      Output

      service/ingress-nginx created

      Ahora, confirme que el equilibrador de carga de DigitalOcean se haya creado de manera exitosa obteniendo los detalles del servicio con kubectl:

      • kubectl get svc --namespace=ingress-nginx

      Debería ver una dirección IP externa que corresponda a la dirección IP del equilibrador de carga de DigitalOcean:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx LoadBalancer 10.245.247.67 203.0.113.0 80:32486/TCP,443:32096/TCP 20h

      Anote la dirección IP externa del equilibrador de carga, ya que la necesitará en un paso posterior.

      Nota: Por defecto, para el servicio LoadBalancer de Ingress de Nginx se fijó service.spec.externalTrafficPolicy en el valor Local, que dirige todo el tráfico del equilibrador de carga a los nodos ejecutando los Pods de Ingress de Nginx. Los otros nodos experimentarán fallas de manera deliberada en las verificaciones de estado del equilibrador de carga, de modo que el tráfico de Ingress no se dirija a estos. Las políticas de tráfico externo están fuera del alcance de este tutorial, pero para obtener más información puede consultar Análisis detallado de las políticas de tráfico externo de Kubernetes e IP de origen para servicios con Type=LoadBalancer en los documentos oficiales de Kubernetes.

      Este equilibrador de carga recibe tráfico en los puertos HTTP y HTTPS 80 y 443, y lo reenvía al Pod del controlador de Ingress. Luego, el controlador de Ingress dirigirá el tráfico al servicio de backend correspondiente.

      Ahora podemos apuntar nuestros registros DNS hacia este equilibrador de carga externo y crear algunos recursos de Ingress para implementar reglas de enrutamiento de tráfico.

      Paso 3: Crear el recurso de Ingress

      Comencemos creando un recurso de Ingress mínimo para direccionar el tráfico orientado a un subdominio determinado hacia un servicio de backend correspondiente.

      En esta guía, utilizaremos el dominio de prueba example.com. Deberá sustituirlo por el nombre de dominio que posea.

      Primero crearemos una regla sencilla para direccionar el tráfico dirigido a echo1.example.com hacia el servicio de backend echo1 y el tráfico dirigido a echo2.example.com hacia el servicio de backend echo2.

      Empiece abriendo un archivo llamado echo_ingress.yaml en su editor de texto favorito:

      Pegue la siguiente definición de ingress:

      echo_ingress.yaml

      apiVersion: extensions/v1beta1
      kind: Ingress
      metadata:
        name: echo-ingress
      spec:
        rules:
        - host: echo1.example.com
          http:
            paths:
            - backend:
                serviceName: echo1
                servicePort: 80
        - host: echo2.example.com
          http:
            paths:
            - backend:
                serviceName: echo2
                servicePort: 80
      

      Cuando haya terminado de editar sus reglas de Ingress, guarde y cierre el archivo.

      Aquí, especificamos que queremos crear un recurso de Ingress llamado echo-ingress y dirigir el tráfico según el encabezado del host. Una solicitud de encabezado de host HTTP especifica el nombre de dominio del servidor de destino. Para obtener más información sobre encabezados de solicitudes de hosts, consulte la página de definición de Mozilla Developer Network. Las solicitudes con el host echo1.example.com se dirigirán al backend echo1, configurado en el paso 1, y las solicitudes con el host echo2.example.com se dirigirán al backend echo2.

      Ahora puede crear el Ingress usando kubectl:

      • kubectl apply -f echo_ingress.yaml

      Visualizará la siguiente salida que confirma la creación de Ingress:

      Output

      ingress.extensions/echo-ingress created

      Para comprobar el Ingress, diríjase a su servicio de administración de DNS y cree registros A para echo1.example.com y echo2.example.com apuntando al IP externo del equilibrador de carga de DigitalOcean. El IP externo del equilibrador de carga es la dirección IP externa para el servicio de ingress-nginx, que obtuvimos en el paso anterior. Si usa DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros A.

      Una vez que haya creado los registros DNS echo1.example.com y echo2.example.com necesarios, puede probar el controlador y el recurso de Ingress que creó usando la utilidad de línea de comandos curl.

      Desde su computadora local, aplique curl al servicio echo1.

      Debe obtener la siguiente respuesta del servicio echo1:

      Output

      echo1

      Esto confirma que su solicitud a echo1.example.com se está dirigiendo de manera correcta a través del Ingress de Nginx al servicio de backend echo1.

      Ahora, realice la misma prueba para el servicio echo2:

      Debe obtener la siguiente respuesta del servicio echo2:

      Output

      echo2

      Esto confirma que su solicitud a echo2.example.com se está dirigiendo de manera correcta a través del Ingress de Nginx al servicio de backend echo2.

      En este punto, habrá configurado con éxito un Ingress básico de Nginx para realizar enrutamientos virtuales basados en host. En el siguiente paso, instalaremos cert-manager usando Helm para proporcionar certificados TLS para nuestro Ingress y habilitaremos el protocolo HTTPS por ser más seguro.

      Paso 4: Instalar y configurar Cert-Manager

      En este paso, usaremos Helm para instalar cert-manager en nuestro clúster. cert-manager es un servicio de Kubernetes que proporciona certificados TLS de Let´s Encrypt, y otras autoridades certificadoras, y administra sus ciclos de vida. Los certificados pueden solicitarse y configurarse aplicando a recursos de Ingress la anotación certmanager.k8s.io/issuer, añadiendo una sección tls a la especificación de Ingress y configurando uno o más *emisores *para especificar su autoridad de certificación preferida. Para obtener más información sobre los objetos de emisores, consulte la documentación oficial de cert-manager sobre emisores.

      Nota: Verifique que está utilizando Helm v2.12.1 o una versión posterior antes de instalar cert-manager. Para comprobar la versión de Helm que instaló, ejecute helm version en su equipo local.

      Antes de usar Helm para instalar cert-manager en nuestro clúster, debemos crear las Definiciones de recursos personalizados (CRD) de cert-manager. Créelos con apply de manera directa desde el repositorio de cert-manager de GitHub:

      • kubectl apply
      • -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

      Debería ver el siguiente resultado:

      Output

      customresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created

      A continuación, añadiremos una etiqueta al espacio de nombres kube-system, donde instalaremos cert-manager, para habilitar la validación avanzada de recursos mediante un webhook:

      • kubectl label namespace kube-system certmanager.k8s.io/disable-validation="true"

      Ahora, añadiremos el repositorio de Jetstack de Helm a Helm. Este repositorio contiene el chart de Helm de cert-manager.

      • helm repo add jetstack https://charts.jetstack.io

      Por último, podemos instalar el chart en el espacio de nombres de kube-system:

      • helm install --name cert-manager --namespace kube-system jetstack/cert-manager --version v0.8.0

      Debería ver el siguiente resultado:

      Output

      . . . NOTES: cert-manager 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.readthedocs.io/en/latest/reference/issuers.html 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.readthedocs.io/en/latest/reference/ingress-shim.html

      Esto indica que la instalación de cert-manager se realizó de manera correcta.

      Antes de comenzar a emitir certificados para nuestros hosts de Ingress, debemos crear un emisor, el cual especifica la autoridad de certificación de la que se pueden obtener certificados firmados x509. En esta guía, usaremos la autoridad de certificación de Let´s Encrypt, que proporciona certificados TLS gratuitos y ofrece un servidor de ensayo para probar la configuración de sus certificados y un servidor de producción para implementar certificados de TLS verificables.

      Crearemos un emisor de prueba para asegurarnos de que el mecanismo de suministro de certificados funcione de manera correcta. Abra un archivo llamado staging_issuer.yaml en su editor de texto favorito:

      nano staging_issuer.yaml
      

      Pegue el siguiente manifiesto de ClusterIssuer:

      staging_issuer.yaml

      apiVersion: certmanager.k8s.io/v1alpha1
      kind: ClusterIssuer
      metadata:
       name: letsencrypt-staging
      spec:
       acme:
         # The ACME server URL
         server: https://acme-staging-v02.api.letsencrypt.org/directory
         # Email address used for ACME registration
         email: your_email_address_here
         # Name of a secret used to store the ACME account private key
         privateKeySecretRef:
           name: letsencrypt-staging
         # Enable the HTTP-01 challenge provider
         http01: {}
      

      Aquí especificamos que deseamos crear un objeto de ClusterIssuer llamado letsencrypt-staging y usar el servidor de ensayo de Let´s Encrypt. Más adelante usaremos el servidor de producción para implementar nuestros certificados, pero el servidor de producción puede limitar las solicitudes que se hagan con el mismo. Por ello, para fines de prueba es mejor usar la URL de ensayo.

      A continuación, especificaremos una dirección de correo electrónico para registrar el certificado y crearemos un Secreto de Kubernetes llamado letsencrypt-staging para almacenar la clave privada de la cuenta de ACME. También habilitaremos el mecanismo de comprobación HTTP-01. Para obtener más información sobre estos parámetros, consulte la documentación oficial de cert-manager sobre emisores.

      Implemente el ClusterIssuer usando kubectl:

      • kubectl create -f staging_issuer.yaml

      Debería ver el siguiente resultado:

      Output

      clusterissuer.certmanager.k8s.io/letsencrypt-staging created

      Ahora que creamos nuestro emisor de ensayo de Let´s Encrypt, estamos listos para modificar el recurso de Ingress que creamos previamente y habilitar el cifrado TLS para las rutas de echo1.example.com y echo2.example.com.

      Abra echo_ingress.yaml de nuevo en su editor favorito:

      Añada lo siguiente al manifiesto de recurso de Ingress:

      echo_ingress.yaml

      apiVersion: extensions/v1beta1
      kind: Ingress
      metadata:
        name: echo-ingress
        annotations:  
          kubernetes.io/ingress.class: nginx
          certmanager.k8s.io/cluster-issuer: letsencrypt-staging
      spec:
        tls:
        - hosts:
          - echo1.example.com
          - echo2.example.com
          secretName: letsencrypt-staging
        rules:
        - host: echo1.example.com
          http:
            paths:
            - backend:
                serviceName: echo1
                servicePort: 80
        - host: echo2.example.com
          http:
            paths:
            - backend:
                serviceName: echo2
                servicePort: 80
      

      Aquí agregamos algunas anotaciones para especificar la ingress.class, que determina el controlador de Ingress que debería utilizarse para implementar las reglas de Ingress. Además, definimos que el cluster-issuer es letsencrypt-staging, el emisor de certificados que acabamos de crear.

      Por último, agregamos un bloque de tls a fin de especificar los hosts para los que queremos adquirir certificados y especificamos un secretName. Este secreto contendrá la clave privada TLS y el certificado emitido.

      Cuando haya terminado de realizar cambios, guarde y cierre el archivo.

      Ahora actualizaremos el recurso de Ingress existente usando kubectl apply:

      • kubectl apply -f echo_ingress.yaml

      Debería ver el siguiente resultado:

      Output

      ingress.extensions/echo-ingress configured

      Puede usar kubectl describe para rastrear el estado de los cambios de Ingress que acaba de aplicar:

      Output

      Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 14m nginx-ingress-controller Ingress default/echo-ingress Normal UPDATE 1m (x2 over 13m) nginx-ingress-controller Ingress default/echo-ingress Normal CreateCertificate 1m cert-manager Successfully created Certificate "letsencrypt-staging"

      Una vez que el certificado se haya creado con éxito, puede ejecutar un describe adicional sobre este para confirmar aún más que se creó de forma correcta:

      • kubectl describe certificate

      Debería ver el siguiente resultado en la sección Events:

      Output

      Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Generated 63s cert-manager Generated new private key Normal OrderCreated 63s cert-manager Created Order resource "letsencrypt-staging-147606226" Normal OrderComplete 19s cert-manager Order "letsencrypt-staging-147606226" completed successfully Normal CertIssued 18s cert-manager Certificate issued successfully

      Esto confirma que el certificado TLS se realizó de forma correcta y que el cifrado HTTPS ahora está activo para los dos dominios configurados.

      Ahora estamos listos para enviar una solicitud a un servidor de backend echo y probar que HTTPS funciona bien.

      Ejecute el siguiente comando wget para enviar una solicitud a echo1.example.com e imprimir los encabezados de respuesta en STDOUT:

      • wget --save-headers -O- echo1.example.com

      Debería ver el siguiente resultado:

      Output

      URL transformed to HTTPS due to an HSTS policy --2018-12-11 14:38:24-- https://echo1.example.com/ Resolving echo1.example.com (echo1.example.com)... 203.0.113.0 Connecting to echo1.example.com (echo1.example.net)|203.0.113.0|:443... connected. ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=Fake LE Intermediate X1’: Unable to locally verify the issuer's authority. To connect to echo1.example.com insecurely, use `--no-check-certificate'.

      Esto indica que HTTPS se habilitó con éxito, pero el certificado no puede verificarse porque es un certificado temporal de carácter falso emitido por el servidor de ensayo de Let´s Encrypt.

      Ahora que probamos que todo funciona usando este certificado temporal falso, podemos implementar certificados de producción para los dos hosts echo1.example.com y echo2.example.com.

      Paso 5: Implementar el emisor de producción

      En este paso, modificaremos el procedimiento utilizado para proporcionar certificados de ensayo, y generaremos un certificado de producción válido y verificable para nuestros hosts de Ingress.

      Para comenzar, crearemos primero un certificado de producción ClusterIssuer.

      Abra un archivo llamado prod_issuer.yaml en su editor favorito:

      nano prod_issuer.yaml
      

      Pegue el siguiente manifiesto:

      prod_issuer.yaml

      apiVersion: certmanager.k8s.io/v1alpha1
      kind: ClusterIssuer
      metadata:
        name: letsencrypt-prod
      spec:
        acme:
          # The ACME server URL
          server: https://acme-v02.api.letsencrypt.org/directory
          # Email address used for ACME registration
          email: your_email_address_here
          # Name of a secret used to store the ACME account private key
          privateKeySecretRef:
            name: letsencrypt-prod
          # Enable the HTTP-01 challenge provider
          http01: {}
      

      Observe la URL del servidor de ACME diferente y el nombre de clave secreta letsencrypt-prod.

      Cuando finalice la edición, guarde y cierre el archivo.

      Ahora, implemente este emisor usando kubectl:

      • kubectl create -f prod_issuer.yaml

      Debería ver el siguiente resultado:

      Output

      clusterissuer.certmanager.k8s.io/letsencrypt-prod created

      Actualice echo_ingress.yaml para usar este nuevo emisor:

      Realice los siguientes cambios al archivo:

      echo_ingress.yaml

      apiVersion: extensions/v1beta1
      kind: Ingress
      metadata:
        name: echo-ingress
        annotations:  
          kubernetes.io/ingress.class: nginx
          certmanager.k8s.io/cluster-issuer: letsencrypt-prod
      spec:
        tls:
        - hosts:
          - echo1.example.com
          - echo2.example.com
          secretName: letsencrypt-prod
        rules:
        - host: echo1.example.com
          http:
            paths:
            - backend:
                serviceName: echo1
                servicePort: 80
        - host: echo2.example.com
          http:
            paths:
            - backend:
                serviceName: echo2
                servicePort: 80
      

      Aquí actualizamos el nombre de ClusterIssuer y el nombre secreto a letsencrypt-prod.

      Una vez que esté satisfecho con sus cambios, guarde y cierre el archivo.

      Implemente los cambios usando kubectl apply:

      • kubectl apply -f echo_ingress.yaml

      Output

      ingress.extensions/echo-ingress configured

      Espere unos minutos para que el servidor de producción de Let´s Encrypt emita el certificado. Puede supervisar el progreso de la operación usando kubectl describe en el objeto certificate:

      • kubectl describe certificate letsencrypt-prod

      El certificado se habrá emitido de forma correcta cuando visualice el siguiente resultado:

      Output

      Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Generated 82s cert-manager Generated new private key Normal OrderCreated 82s cert-manager Created Order resource "letsencrypt-prod-2626449824" Normal OrderComplete 37s cert-manager Order "letsencrypt-prod-2626449824" completed successfully Normal CertIssued 37s cert-manager Certificate issued successfully

      Ahora, realizaremos una prueba usando curl para verificar que HTTPS funcione de forma correcta:

      Debería ver lo siguiente:

      Output

      <html> <head><title>308 Permanent Redirect</title></head> <body> <center><h1>308 Permanent Redirect</h1></center> <hr><center>nginx/1.15.9</center> </body> </html>

      Esto indica que las solicitudes HTTP se redirigen para emplear HTTPS.

      Ejecute curl en https://echo1.example.com:

      • curl https://echo1.example.com

      Ahora, debería ver el siguiente resultado:

      Output

      echo1

      Puede ejecutar el comando anterior con el indicador verbose -v para profundizar en el protocolo de enlace del certificado y para verificar la información del certificado.

      En este punto, habrá configurado con éxito HTTPS usando un certificado de Let´s Encrypt para su Ingress de Nginx.

      Conclusión

      A través de esta guía, configuró un Ingress de Nginx para equilibrar las cargas y dirigir las solicitudes externas a los servicios de backend dentro de su clúster de Kubernetes. También protegió el Ingress instalando el proveedor de certificado cert-manager y configurando un certificado de Let´s Encrypt para dos rutas de host.

      Existen muchas alternativas al controlador de Ingress de Nginx. Para obtener más información, consulte Controladores de Ingress en la documentación oficial de Kubernetes.



      Source link