{"id":442,"date":"2025-01-23T05:45:23","date_gmt":"2025-01-23T05:45:23","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=442"},"modified":"2025-01-23T05:45:23","modified_gmt":"2025-01-23T05:45:23","slug":"nginx-ingress-with-cert-manager","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=442","title":{"rendered":"How to set up Nginx Ingress with Cert Manager in EKS"},"content":{"rendered":"

In this blog, we will learn how to integrate TLS certificates into a Kubernetes cluster using Cert-Manager<\/strong> and the Let’s Encrypt<\/strong> Certificate Authority.<\/p>\n

By the end of this blog, you will have learned.<\/p>\n

    \n
  1. Installation of CertManager<\/li>\n
  2. Configuration of Let’s encrypt Certificate Authority to Certmanager<\/li>\n<\/ol>\n

    What is Cert Manager?<\/h2>\n

    SSL\/TLS certificates<\/a> are essential for Kubernetes Ingress<\/strong> objects to secure communication between the users and the application.<\/p>\n

    Cert Manager is a tool that creates and manages TLS certificates for Ingress objects, also automatically renewing their validity at the right time.<\/p>\n

    The Cert Manager works with Certificate Authorities (CA)<\/strong> such as Let’s Encrypt, Hashicorp Vault, etc.<\/p>\n

    Before setting up the Cert Manager, let us understand its workflow.<\/p>\n

    Cert Manager Workflow<\/h2>\n

    The diagram below explains how the Cert manager works with the kubernetes cluster to provision and manage the TLS Certificates to safeguard the Ingress.<\/p>\n

    \"the<\/figure>\n
      \n
    1. When we create an Ingress object, we add a reference to the Cert Manager Issuer in it.<\/li>\n
    2. The Ingress Controller retrieves information from the Ingress object and requests a certificate from the Certificate Manager.<\/li>\n
    3. The Cert Manager will request the Certificate Authority, for example, Let’s Encrypt.<\/li>\n
    4. After the verification, the CA will generate and provide the certificate to the Cert Manager.<\/li>\n
    5. The generated certificate will be stored in Kubernetes as a TLS Secret.<\/li>\n
    6. The Ingress Controller will perform the TLS termination using the stored certificate.<\/li>\n
    7. When a user tries to access the application, the external traffic is routed from the external Load Balancer to the Ingress Controller.<\/li>\n
    8. The TLS termination will happen in the Ingress Controller with the TLS certificate and securely route the traffic to the application Pods.<\/li>\n<\/ol>\n

      How to Set Up Cert Manager on Kubernetes<\/h2>\n

      We will install the Cert Manager using the Helm chart. Before adding the repository, we need to ensure the following prerequisites are met.<\/p>\n

      Prerequisites<\/h3>\n
        \n
      1. Kubernetes Cluster<\/a> version 1.30+<\/li>\n
      2. Nginx Ingress Controller [Kubernetes cluster]<\/li>\n
      3. Helm<\/a> [Local Workstation]<\/li>\n
      4. Kubectl [Local Workstation]<\/li>\n
      5. DNS Provider (Route53, Cloudflare, etc)<\/li>\n<\/ol>\n
        \n
        \ud83d\udca1<\/div>\n
        For this tutorial, I am using an Amazon EKS cluster and Route53 as the DNS provider.
        A DNS provider is required for our certificate issuer (Let’s Encrypt). It verifies the validity of domain names to provide certificates.<\/div>\n<\/div>\n

        Step 1: Install Cert Manager on Kubernetes<\/h3>\n

        First, we need to add the Cert Manager Helm Repository<\/p>\n

        helm repo add jetstack https:\/\/charts.jetstack.io --force-update<\/code><\/pre>\n
        Update the repository before installation<\/p>\n
        helm repo update<\/code><\/pre>\n
        Now, we are ready to deploy the Cert Manager, but if you want to download the Helm chart to store your own repo, use the following command.<\/p>\n
        helm pull jetstack\/cert-manager --untar<\/code><\/pre>\n
        The following is the tree structure of the Helm chart<\/p>\n
        cert-manager\n\u251c\u2500\u2500 Chart.yaml\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 templates\n\u2502   \u251c\u2500\u2500 NOTES.txt\n\u2502   \u251c\u2500\u2500 _helpers.tpl\n\u2502   \u251c\u2500\u2500 cainjector-config.yaml\n\u2502   \u251c\u2500\u2500 cainjector-deployment.yaml\n\u2502   \u251c\u2500\u2500 cainjector-poddisruptionbudget.yaml\n\u2502   \u251c\u2500\u2500 cainjector-psp-clusterrole.yaml\n\u2502   \u251c\u2500\u2500 cainjector-psp-clusterrolebinding.yaml\n\u2502   \u251c\u2500\u2500 cainjector-psp.yaml\n\u2502   \u251c\u2500\u2500 cainjector-rbac.yaml\n\u2502   \u251c\u2500\u2500 cainjector-service.yaml\n\u2502   \u251c\u2500\u2500 cainjector-serviceaccount.yaml\n\u2502   \u251c\u2500\u2500 controller-config.yaml\n\u2502   \u251c\u2500\u2500 crd-acme.cert-manager.io_challenges.yaml\n\u2502   \u251c\u2500\u2500 crd-acme.cert-manager.io_orders.yaml\n\u2502   \u251c\u2500\u2500 crd-cert-manager.io_certificaterequests.yaml\n\u2502   \u251c\u2500\u2500 crd-cert-manager.io_certificates.yaml\n\u2502   \u251c\u2500\u2500 crd-cert-manager.io_clusterissuers.yaml\n\u2502   \u251c\u2500\u2500 crd-cert-manager.io_issuers.yaml\n\u2502   \u251c\u2500\u2500 deployment.yaml\n\u2502   \u251c\u2500\u2500 extras-objects.yaml\n\u2502   \u251c\u2500\u2500 networkpolicy-egress.yaml\n\u2502   \u251c\u2500\u2500 networkpolicy-webhooks.yaml\n\u2502   \u251c\u2500\u2500 poddisruptionbudget.yaml\n\u2502   \u251c\u2500\u2500 podmonitor.yaml\n\u2502   \u251c\u2500\u2500 psp-clusterrole.yaml\n\u2502   \u251c\u2500\u2500 psp-clusterrolebinding.yaml\n\u2502   \u251c\u2500\u2500 psp.yaml\n\u2502   \u251c\u2500\u2500 rbac.yaml\n\u2502   \u251c\u2500\u2500 service.yaml\n\u2502   \u251c\u2500\u2500 serviceaccount.yaml\n\u2502   \u251c\u2500\u2500 servicemonitor.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-job.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-psp-clusterrole.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-psp-clusterrolebinding.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-psp.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-rbac.yaml\n\u2502   \u251c\u2500\u2500 startupapicheck-serviceaccount.yaml\n\u2502   \u251c\u2500\u2500 webhook-config.yaml\n\u2502   \u251c\u2500\u2500 webhook-deployment.yaml\n\u2502   \u251c\u2500\u2500 webhook-mutating-webhook.yaml\n\u2502   \u251c\u2500\u2500 webhook-poddisruptionbudget.yaml\n\u2502   \u251c\u2500\u2500 webhook-psp-clusterrole.yaml\n\u2502   \u251c\u2500\u2500 webhook-psp-clusterrolebinding.yaml\n\u2502   \u251c\u2500\u2500 webhook-psp.yaml\n\u2502   \u251c\u2500\u2500 webhook-rbac.yaml\n\u2502   \u251c\u2500\u2500 webhook-service.yaml\n\u2502   \u251c\u2500\u2500 webhook-serviceaccount.yaml\n\u2502   \u2514\u2500\u2500 webhook-validating-webhook.yaml\n\u251c\u2500\u2500 values.schema.json\n\u2514\u2500\u2500 values.yaml\n\n2 directories, 52 files<\/code><\/pre>\n
        The following are the container images used in this Helm chart<\/p>\n