Update Blog “exposing-an-application-using-ingress-and-tls-termination-on-kubernetes-in-hpe-greenlake-for-private-cloud-enterprise”

Author: GuopingJia

content/blog/exposing-an-application-using-ingress-and-tls-termination-on-kubernetes-in-hpe-greenlake-for-private-cloud-enterprise.md

@@ -22,16 +22,16 @@ tags:
 
 ### Overview
 
-[HPE GreenLake for Private Cloud Enterprise: Containers](https://www.hpe.com/us/en/greenlake/containers.html) ("containers service"), one of the HPE GreenLake cloud services available on the HPE GreenLake for Private Cloud Enterprise, allows customers to create a K8s cluster and deploy containerized applications to the cluster. It provides an enterprise-grade container management service using open source K8s.  
- 
-Once applications are deployed in a K8s cluster, the next step is to create services that expose these applications. By default, K8s services are created with the *ClusterIP* type, which supports internal connectivity among different components of the applications. However, these services are not directly accessible from outside the cluster. The challenge arises with a requirement to securely expose the deployed applications over HTTPS. This involves generating and managing SSL/TLS certificates for multiple applications deployed in the cluster. These certificates are crucial for secure communication between services, and their correct installation and management are essential to avoid access issues and security risks. To address exposing applications over HTTPS, K8s provides the concept of *Ingress*. An Ingress acts as an entry point for external traffic into the cluster. It can be configured with TLS termination. However, setting up K8s Ingress is intricate. It involves creating a K8s Secret to host the certificate and referencing the Secret in the Ingress resource. It also requires an additional load balancer configuration in the cluster.
+[HPE GreenLake for Private Cloud Enterprise: Containers](https://www.hpe.com/us/en/greenlake/containers.html), one of the HPE GreenLake cloud services available on the HPE GreenLake for Private Cloud Enterprise, allows customers to create a K8s cluster and deploy containerized applications to the cluster. It provides an enterprise-grade container management service using open source K8s.  
+
+Once applications are deployed in a K8s cluster, the next step is to create services that expose these applications. By default, K8s services are created with the *ClusterIP* type, which supports internal connectivity among different components of the applications. However, these services are not directly accessible from outside the cluster. The challenge arises with a requirement to securely expose the deployed applications over HTTPS. This involves generating and managing SSL/TLS certificates for multiple applications deployed in the cluster. These certificates are crucial for secure communication between services, and their correct installation and management are essential to avoid access issues and security risks. To address exposing applications over HTTPS, K8s provides the concept of *Ingress*. An Ingress acts as an entry point for external traffic into the cluster. It can be configured with TLS termination. However, setting up K8s Ingress with TLS termination is intricate. It involves creating a K8s Secret to host the certificate and referencing the Secret in the Ingress resource. It also requires an additional load balancer configuration in the cluster.
 
 This blog post outlines the comprehensive steps for exposing applications using Ingress and TLS termination on K8s in HPE GreenLake for Private Cloud Enterprise. [MetalLB](https://metallb.universe.tf/) is deployed to the cluster to set up the load balancer. It enables external access to services within the cluster. [Cert-manager](https://cert-manager.io/) is utilized for creating and managing SSL/TLS certificates. The generated certificate is stored as a K8s *Secret* object. This Secret can be mounted by application Pods or used by an Ingress controller. The [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/) is deployed and configured in the cluster. It handles SSL certificates and facilitates secure access to applications in the backend.
 
 ![](/img/tls-termination-s.png)
 
 Despite the complexities, securely exposing applications in a K8s cluster over HTTPS is attainable. This can be achieved by leveraging Ingress and TLS termination, along with a suite of suitable tools and utilities deployed within the K8s cluster in HPE GreenLake for Private Cloud Enterprise.
- 
+
 ### Prerequisites
 
 Before starting, make sure you have the following:
@@ -43,7 +43,7 @@ Before starting, make sure you have the following:
 
 ### Set up the load balancer with MetalLB
 
-You can install MetalLB and set up the load balancer in the K8s cluster by following up the blog post [Setting up the load balancer with MetalLB](https://developer.hpe.com/blog/set-up-load-balancer-with-metallb-in-hpe-greenlake-for-private-cloud-enterprise/).
+You can install MetalLB and set up the load balancer in the K8s cluster by following up the blog post [Setting up the load balancer with MetalLB](https://developer.hpe.com/blog/set-up-load-balancer-with-metallb-in-hpe-greenlake-for-private-cloud-enterprise/).
 
 Here is the deployed MetalLB to the namespace *metallb-system* in the cluster:
 
@@ -85,9 +85,9 @@ cfe-l2advert   ["cfe-pool"]
 
 ### Deploy Nginx Ingress controller
 
-In order for an Ingress to work in the cluster, there must be an Ingress controller being deployed and running. It's the Ingress controller that accesses the certificate and routing rules defined on the Ingress resource and makes them par of its configuration. 
+In order for an Ingress to work in the cluster, there must be an Ingress controller being deployed and running. It's the Ingress controller that accesses the certificate and the routing rules defined on the Ingress resource and makes them par of its configuration. 
 
-There is a list of Ingress controllers, such as [Traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/), [HAProxy](https://github.com/haproxytech/kubernetes-ingress#readme), [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/), you can deploy in the cluster. The following command shows to install the Nginx Ingress controller to the cluster using helm:
+A variety of Ingress controllers are available for deployment in the cluster, including [Traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/), [HAProxy](https://github.com/haproxytech/kubernetes-ingress#readme) and [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/). Execute the command below to install the Nginx Ingress controller to the cluster using helm:
 
 ```shell
 $ helm upgrade --install ingress-nginx ingress-nginx \
@@ -163,7 +163,7 @@ replicaset.apps/ingress-nginx-controller-548768956f   1         1         1
 
 The service *ingress-nginx-controller* gets deployed as the service type of *LoadBalancer* with the *EXTERNAL-IP* assigned as *10.6.115.251*. This IP address will be used for setting up domain and subdomain name resolution.
 
-### Generate a self-signed certificate using cert-manager  
+### Generate a self-signed certificate using cert-manager
 
 You can deploy cert-manager to the K8s cluster and generate a self-signed certificate by following up the blog post [Generating self-signed certificates using cert-manager](https://developer.hpe.com/blog/generating-self-signed-certificates-using-cert-manager-for-kubernetes-in-hpe-greenlake-for-private-cloud-entreprise/).
 
@@ -191,7 +191,7 @@ replicaset.apps/cert-manager-cainjector-69548575fb   1         1         1
 replicaset.apps/cert-manager-webhook-57b78f476d      1         1         1       18s
 ```
 
-Below is the deployed self-signed custom resource definition (CRD) *Issuer* in the namespace *nginx-apps*  in which you want to generate certificate:
+Below is the deployed self-signed custom resource definition (CRD) *Issuer* in the namespace *nginx-apps* in which you want to generate certificate:
 
 ```shell
 $ kubectl get issuer -n nginx-apps
@@ -202,116 +202,116 @@ cfe-selfsigned-issuer   True    115s
 Here is the generated self-signed certificate in the namespace *nginx-apps*:
 
 ```shell
-$ kubectl get certificate -n nginx-apps
-NAME                 READY   SECRET             AGE
+$ kubectl get certificate -n nginx-apps
+NAME                 READY   SECRET             AGE
 cfe-selfsigned-tls   True    cfe-tls-key-pair   2m23s
 ```
 
-The following K8s Secret *cfe-tls-key-pair* is created automatically in the same namespace as part of certificate deployment:
+The K8s Secret *cfe-tls-key-pair* is created automatically in the same namespace as part of certificate deployment:
 
 ```shell
 $ kubectl get secrets -n nginx-apps cfe-tls-key-pair
 NAME               TYPE                DATA   AGE
 cfe-tls-key-pair   kubernetes.io/tls   3      2m25s
 ```
 
-Type the following command to check the *commonName* and the *dnsNames* that are used to generate the certificate:
+Type the following command to check the *commonName* and the *dnsNames* in the generated certificate:
 
 ```shell
-$ kubectl describe certificate cfe-selfsigned-tls -n nginx-apps
-Name:         cfe-selfsigned-tls
-Namespace:    nginx-apps
-Labels:       <none>
-Annotations:  <none>
-API Version:  cert-manager.io/v1
-Kind:         Certificate
-Metadata:
-  Creation Timestamp:  2024-03-06T17:58:51Z
-  Generation:          1
-  Managed Fields:
-    API Version:  cert-manager.io/v1
-    Fields Type:  FieldsV1
-    fieldsV1:
-      f:metadata:
-        f:annotations:
-          .:
-          f:kubectl.kubernetes.io/last-applied-configuration:
-      f:spec:
-        .:
-        f:commonName:
-        f:dnsNames:
-        f:isCA:
-        f:issuerRef:
-          .:
-          f:kind:
-          f:name:
-        f:secretName:
-    Manager:      kubectl-client-side-apply
-    Operation:    Update
-    Time:         2024-03-06T17:58:51Z
-    API Version:  cert-manager.io/v1
-    Fields Type:  FieldsV1
-    fieldsV1:
-      f:status:
-        f:revision:
-    Manager:      cert-manager-certificates-issuing
-    Operation:    Update
-    Subresource:  status
-    Time:         2024-03-06T17:58:52Z
-    API Version:  cert-manager.io/v1
-    Fields Type:  FieldsV1
-    fieldsV1:
-      f:status:
-        .:
-        f:conditions:
-          .:
-          k:{"type":"Ready"}:
-            .:
-            f:lastTransitionTime:
-            f:message:
-            f:observedGeneration:
-            f:reason:
-            f:status:
-            f:type:
-        f:notAfter:
-        f:notBefore:
-        f:renewalTime:
-    Manager:         cert-manager-certificates-readiness
-    Operation:       Update
-    Subresource:     status
-    Time:            2024-03-06T17:58:52Z
-  Resource Version:  2128063
-  UID:               977eaa8a-1612-489b-a34d-0e78ab113096
-Spec:
-  Common Name:  example.com
-  Dns Names:
-    green.nginx.example.com
-    blue.nginx.example.com
-    nginx.example.com
-    example.com
-  Is CA:  true
-  Issuer Ref:
-    Kind:       Issuer
-    Name:       cfe-selfsigned-issuer
-  Secret Name:  cfe-tls-key-pair
-Status:
-  Conditions:
-    Last Transition Time:  2024-03-06T17:58:52Z
-    Message:               Certificate is up to date and has not expired
-    Observed Generation:   1
-    Reason:                Ready
-    Status:                True
-    Type:                  Ready
-  Not After:               2024-06-04T17:58:52Z
-  Not Before:              2024-03-06T17:58:52Z
-  Renewal Time:            2024-05-05T17:58:52Z
-  Revision:                1
+$ kubectl describe certificate cfe-selfsigned-tls -n nginx-apps
+Name:         cfe-selfsigned-tls
+Namespace:    nginx-apps
+Labels:       <none>
+Annotations:  <none>
+API Version:  cert-manager.io/v1
+Kind:         Certificate
+Metadata:
+  Creation Timestamp:  2024-03-06T17:58:51Z
+  Generation:          1
+  Managed Fields:
+    API Version:  cert-manager.io/v1
+    Fields Type:  FieldsV1
+    fieldsV1:
+      f:metadata:
+        f:annotations:
+          .:
+          f:kubectl.kubernetes.io/last-applied-configuration:
+      f:spec:
+        .:
+        f:commonName:
+        f:dnsNames:
+        f:isCA:
+        f:issuerRef:
+          .:
+          f:kind:
+          f:name:
+        f:secretName:
+    Manager:      kubectl-client-side-apply
+    Operation:    Update
+    Time:         2024-03-06T17:58:51Z
+    API Version:  cert-manager.io/v1
+    Fields Type:  FieldsV1
+    fieldsV1:
+      f:status:
+        f:revision:
+    Manager:      cert-manager-certificates-issuing
+    Operation:    Update
+    Subresource:  status
+    Time:         2024-03-06T17:58:52Z
+    API Version:  cert-manager.io/v1
+    Fields Type:  FieldsV1
+    fieldsV1:
+      f:status:
+        .:
+        f:conditions:
+          .:
+          k:{"type":"Ready"}:
+            .:
+            f:lastTransitionTime:
+            f:message:
+            f:observedGeneration:
+            f:reason:
+            f:status:
+            f:type:
+        f:notAfter:
+        f:notBefore:
+        f:renewalTime:
+    Manager:         cert-manager-certificates-readiness
+    Operation:       Update
+    Subresource:     status
+    Time:            2024-03-06T17:58:52Z
+  Resource Version:  2128063
+  UID:               977eaa8a-1612-489b-a34d-0e78ab113096
+Spec:
+  Common Name:  example.com
+  Dns Names:
+    green.nginx.example.com
+    blue.nginx.example.com
+    nginx.example.com
+    example.com
+  Is CA:  true
+  Issuer Ref:
+    Kind:       Issuer
+    Name:       cfe-selfsigned-issuer
+  Secret Name:  cfe-tls-key-pair
+Status:
+  Conditions:
+    Last Transition Time:  2024-03-06T17:58:52Z
+    Message:               Certificate is up to date and has not expired
+    Observed Generation:   1
+    Reason:                Ready
+    Status:                True
+    Type:                  Ready
+  Not After:               2024-06-04T17:58:52Z
+  Not Before:              2024-03-06T17:58:52Z
+  Renewal Time:            2024-05-05T17:58:52Z
+  Revision:                1
 Events:                    <none>
 ```
 
 ### Deploy sample Nginx applications
 
-In order to validate the Ingress TLS termination, three sample Nginx applications will be deployed to the cluster using the YAML manifest files from the GitHub repo [ingress-demo](https://github.com/GuopingJia/ingress-demo):
+In order to configure and validate the Ingress TLS termination, three sample Nginx applications will be deployed to the cluster using the YAML manifest files from the GitHub repo [ingress-demo](https://github.com/GuopingJia/ingress-demo):
 
 ```shell
 $ tree ingress-demo/
@@ -325,7 +325,7 @@ ingress-demo/
 └── README.md
 ```
 
-Each YAML manifest file in the folder *apps* defines the *Deployment* and the *Service* resource.  
+Each YAML manifest file in the folder *'apps'* defines the *Deployment* and the *Service* resource.  
 
 Type the following commands to deploy those Nginx applications to the namespace *nginx-apps*:
 
@@ -367,16 +367,15 @@ replicaset.apps/nginx-green-8956bbd9f   1         1         1       24s
 replicaset.apps/nginx-main-64bfd77895   1         1         1       32s
 ```
 
-Three Nginx applications, *nginx-main*, *nginx-blue* and *nginx-green*, are deployed as the service type of *ClusterIP*. They provide internal connectivity and can solely be accessed from within the cluster.
-
+Three Nginx services, *nginx-main*, *nginx-blue* and *nginx-green*, are deployed as the *ClusterIP* type. They provide internal connectivity and can solely be accessed from within the cluster.
 
 Type the following commend to check that all the application service endpoints have been populated:
 
 ```shell
-$ kubectl get endpoints -n nginx-apps
-NAME          ENDPOINTS        AGE
-nginx-blue    10.192.3.78:80    1m
-nginx-green   10.192.4.45:80    1m
+$ kubectl get endpoints -n nginx-apps
+NAME          ENDPOINTS        AGE
+nginx-blue    10.192.3.78:80    1m
+nginx-green   10.192.4.45:80    1m
 nginx-main    10.192.4.44:80    1m
 ```
 
@@ -392,7 +391,6 @@ metadata:
   name: ingress-host-based-selfsigned
   annotations:
     ingress.kubernetes.io/ssl-redirect: "true"
-    #kubernetes.io/ingress.class: "nginx"
     cert-manager.io/issuer: "nginx-selfsinged-issuer"
 spec:
   ingressClassName: nginx
@@ -432,7 +430,6 @@ spec:
             port:
               number: 80
 ```
-
 
 In the above sample YAML manifest file, there is the *'tls'* block that contains the hostname *'nginx.example.com'* and the secret *cfe-tls-key-pair* created in the certification step. There is also the *'rules'* block in which a list of routing rules is defined per host, e.g., host *nginx.example.com* will be routed to the application service *nginx-main* in the backend.  
 
@@ -490,7 +487,7 @@ $ host blue.nginx.example.com
 blue.nginx.example.com has address 10.6.115.251
 ```
 
-You can then validate the Ingres TLS configuration using the browser. 
+You can then validate the Ingres TLS configuration of the deployed Nginx applications using the browser. 
 
 Start the browser and type the URL *nginx.example.com*, it will be rediected over HTTPS with the warning message *'Your connection is not private'*: 
 
@@ -526,7 +523,6 @@ You have successfully configured the Ingress with the generated TLS certifica
 
 ### Conclusion
 
-
 This blog post provided a comprehensive guide on how to expose applications and make them accessible securely via HTTPS in a K8 cluster in HPE GreenLake for Private Cloud Enterprise. It detailed the process of configuring TLS termination on an Ingress controller, utilizing a K8s Ingress resource and a self-signed TLS certificate generated with cert-manager. While the blog post emphasized on self-signed certificates, the outlined procedure is equally applicable to any type of certificates. This flexibility allows customers to follow the steps using their own CA certificates or any commercially issued certificates for Ingress TLS termination, ensuring secure exposure of their applications in the K8s cluster over HTTPS. 
 
 Please keep coming back to the [HPE Developer Community blog](https://developer.hpe.com/blog/) to learn more about HPE GreenLake for Private Cloud Enterprise.