Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
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.


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.


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

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

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

Finally we can install the service:
helm install \
--name cert-manager \
--namespace cert-manager \
--version v0.7.2 \

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


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:
kind: ClusterIssuer
name: letsencrypt-prod
# The ACME server URL
# Email address used for ACME registration
# Name of a secret used to store the ACME account private key
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


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
name: vsystem
annotations: nginx letsencrypt-prod "true" "HTTPS" "true" "500m" "30" "1800" "1800" "16k"
- hosts:
secretName: vsystem-tls-certs
- host:
- path: /
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


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!

Labels in this area