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
April 9, 2019

Track Your Cloud Activities Using IBM Cloud Activity Tracker with LogDNA

With IBM Cloud Activity Tracker with LogDNA, you can improve the security monitoring of your application by setting alerts for user access patterns and gain greater trackability for how your Cloud Service and Cloud Account is being used, configured, and accessed.

Continue reading

March 29, 2019

Adding Sign In to Multicloud Applications Without Code Changes

In this post, we will explore a proof of concept illustrating how we can leverage identity federation using a single IBM Cloud App ID instance along with common operational patterns, such as Kubernetes and Istio, to create a centralized identity and access management model that can transparently secure applications/services across cloud environments.

Continue reading

March 28, 2019

Sign In Your App Users With Any Identity Provider Using App ID

We're going to explain App ID’s custom identity flow and walk you through an example of how you can use it to integrate a third-party identity provider with App ID—specifically, LinkedIn.

Continue reading