Your SAP on Azure – Part 16 – Easy TLS/SSL with SAP Data Hub and Let's Encrypt

[BJarkowski]

I always enjoy attending community events because that’s a good chance to learn something new. A few days ago I joined the first Azure Midlands Community meetup and when Microsoft MVP Marco De Sanctis presented how easy it is to manage TLS/SSL certificates in the Kubernetes cluster I thought I need to test with my SAP Data Hub installation and share it with you!

To access SAP Data Hub deployed on Azure Kubernetes Service you need to expose the System Management to the internet or local network using an Ingress controller. If you follow the official documentation or my blog about installing the SAP Data Hub there is a small script that lets you create a self-signed certificate and upload it to the vsystem-tls-certs secret. But that’s not the best approach as users can’t verify the website owner and you get this ugly welcome screen!



There is another approach. You can request and import a trusted certificate. This way your website is secure and you can see a small green lock on the address bar. But each certificate will eventually expire and you need to remember to replace it. Oh, and I almost forgot – you need to pay for the certificate!

But there is a third approach possible. Most probably you’re already familiar with Let’s Encrypt. They offer TLS/SSL certificates for free and today I will show you how to enable the automatic deployment to SAP Data Hub cluster.

(source: https://docs.cert-manager.io/)

My assumption is that you have already installed the SAP Data Hub and exposed the System Management to the internet using an Ingress service. If you’re not there yet, please refer to the installation guide or my post and continue with this guide when you can access the website.

INSTALL CERT MANAGER

We will use helm to install the cert-manager on AKS cluster. It’s a Kubernetes service that provisions certificates from Let’s Encrypt and automatically deploys them to a configured secret. The cert-manager is using custom resources that are not available on the Kubernetes by default, so we start with the creation of Custom Resource Definitions (CRDs) in a new namespace:

kubectl create namespace cert-manager

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

I label the cert-manager namespace to disable the resource validation

kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

The cert-manager is contained in custom repository so we need to add it to helm and run the update:

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

helm repo update

Finally we can install the service:

helm install \

  --name cert-manager \

  --namespace cert-manager \

  --version v0.7.2 \

  jetstack/cert-manager

To verify the installation you can display the pods running in the cert-manager namespace:



CONFIGURE CERTIFICATE ISSUER

The Issuer is one of the custom resources that we have already imported to our Kubernetes cluster and it specifies the certificate authority that will generate TLS certificates for us. Create the following manifest and type your e-mail address in the email field:

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: <E-MAIL ADDRESS>

    # Name of a secret used to store the ACME account private key

    privateKeySecretRef:

      name: letsencrypt-prod

    # Enable the HTTP-01 challenge provider

    http01: {}

Create the issuer based on the manifest file:

kubectl create -f prod-issuer.yaml -n cert-manager

CONFIGURE THE INGRESS SERVICE

The last step is to modify the ingress script delivered by SAP to add an annotation that this service should be included in the certificate deployment process. Don’t forget to update your domain names as well.

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: vsystem

 annotations:

   kubernetes.io/ingress.class: nginx

   certmanager.k8s.io/cluster-issuer: letsencrypt-prod

   nginx.ingress.kubernetes.io/secure-backends: "true"

   nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

   nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

   nginx.ingress.kubernetes.io/proxy-body-size: "500m"

   nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"

   nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"

   nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"

   nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"

spec:

 tls:

 - hosts:

   - domain.name

   secretName: vsystem-tls-certs

 rules:

 - host: domain.name

   http:

     paths:

     - path: /

       backend:

         serviceName: vsystem

         servicePort: 8797

Apply the new settings using:

kubectl apply -f vsystem-ingress.yaml -n <namespace>

Let’s have a closer look to what happened inside the new ingress:

kubectl describe ing vsystem -n datahub

In the events section you will see that the certificate was successfully created:



You can also have a look at the Certificate resource. As you can see bellow I initially had a problem with the letsencrypt-prod issuer and that’s mentioned in the event section. In my case, the problem was with an incorrect e-mail address set in the prod-issuer.yaml file.

kubectl describe certificate vsystem-tls-certs -ndatahub

TESTING

Let’s go back to the SAP Data Hub and refresh the screen. This time there was no information about Potential Security Risks, but instead, we have a login screen and a green lock in the address bar!