Enabling Helm with TLS and Service Accounts

Share this post:

What is TLS?

Transport Layer Security, known as TLS, is a means of maintaining data integrity between two applications that must communicate with each other. Service accounts help you define user/cluster specific roles which give you customizability over who gets to do what to your data. When used together, these technologies greatly improve the security and flexibility of whatever application you choose to run on your cluster with IBM Cloud Data Shield. This will all take place inside a custom namespace you define within your cluster, which will further help you organize your users and their permissions.

You may want to integrate this technology with Data Shield as an added layer of security to protect your data, so let’s go over how exactly it’s done.

Creating a custom namespace

First, create the new namespace:

kubectl create namespace [namespace_name]

Next, copy over all relevant secrets from the default namespace to the new one (all secrets starting with bluemix*). You can view all secrets in the default namespace using:

kubectl get secrets

Copy them over one at a time:

kubectl get secret [secret_name] --namespace=default --export -o yaml |\
kubectl apply --namespace=[namespace_name] -f -

Confirm the secrets have been copied over:

kubectl get secrets --namespace [namespace_name]

Creating a service account

Next, we will create a service account and define permissions for it.

Create a service account:

kubectl create serviceaccount --namespace [namespace_name] [service_account_name]
kubectl create clusterrolebinding [role_name] --clusterrole=cluster-admin --serviceaccount=[namespace_name]:[service_account_name]

If you wish to further customize the service account, more information can be found here.

Using certificates to authenticate

Next, we must generate certs that we need to enable a TLS connection between Helm and Tiller. These certificates help Helm and Tiller make sure they are taking instructions from the authoritative sources only. The idea is to have a Tiller instance under our custom namespace that will only accept incoming connections from SSL authenticated clients.

Those steps can be found here (be sure to specify the namespace you created and service account when you call helm init).

Finishing up

From this point on, make sure to add a --tiller-namespace option to any helm command you run and specify the kubectl namespace you created. Proceed with Data Shield Installation.

That’s it! You’ve successfully enabled TLS and set up a service account inside a custom namespace, and you can now enjoy the benefits of added security and flexibility within your already secure Data Shield application.

Cloud Security Developer

More Security stories
May 7, 2019

We’ve Moved! The IBM Cloud Blog Has a New URL

In an effort better integrate the IBM Cloud Blog with the IBM Cloud web experience, we have migrated the blog to a new URL:

Continue reading

May 6, 2019

Use IBM Cloud Certificate Manager to Obtain Let’s Encrypt TLS Certificates for Your Public Domains

IBM Cloud Certificate Manager now lets you obtain TLS certificates signed by Let’s Encrypt. Let’s Encrypt is an automated, ACME-protocol-based CA that issues free certificates valid for 90 days.

Continue reading

May 6, 2019

Are You Ready for SAP S/4HANA Running on Cloud?

Our clients tell us SAP applications are central to their success and strategy for cloud, with a deadline to refresh the business processes and move to SAP S/4HANA by 2025. Now is the time to assess, plan and execute the journey to cloud and SAP S/4HANA

Continue reading