mTLS (Self-signed)

Securing service-to-service communication is one of the most important aspect of any system using microservices. Enabling mutual authentication with service mesh increases the security posture and helps organizations satisfy compliance requirements.

With pre-canned profiles in Service Mesh offering, enabling mTLS is simple and straightforward. In this section, we will cover the steps needed to enforce mTLS.

Prerequisites¶

You have provisioned or imported a cluster using controller
Service mesh is already enabled in the cluster with sidecar injection enabled. Follow "Enable Sidecar Injection using Service Mesh" section to do this

Enable Service Mesh¶

Sidecar Injection using Service Mesh¶

Navigate to "Project" - "Service Mesh" - "Installation Profiles"
Create a new installation profile named "enable-injection"
Give an appropriate version name
In Installation Parameters select "SelfSigned" for certificate type (Or CertManager if you want to use an external cert-manager and have already setup cert-manager as outlined here for Vault and AWS Certificate Manager)
Select "Enable Sidecar Injection Globally"

Enable Globally

Save & Exit

Create & Deploy Blueprint¶

To enable sidecar injection you must create and deploy a blueprint on the cluster.

Navigate to "Project" -> "Blueprints" and click on "New Blueprint"
Create a new blueprint named "servicemesh-bp"
Scroll down to the Service Mesh section and enable it
Select the installation profile created as part of the previous step
Navigate to "Clusters" and update the blueprint of the cluster to "servicemesh-bp"

Now the cluster has service mesh and sidecar injection enabled.

Important

Sidecar injection to existing pods will only take place when pods are restarted.

Enable Strict mTLS¶

Strict mTLS can be enforced cluster-wide or for specific namespaces.

Steps to enable Strict mTLS across a cluster¶

Create & Deploy Blueprint¶

To enable sidecar injection you must create and deploy a blueprint on the cluster.

Navigate to "Project" -> "Blueprints" and click on "New Blueprint" or create a new version of "servicemesh-bp"
Scroll down to the Service Mesh section and enable it
Select the installation profile created as part of the previous step
Click on "Add Policy" and select "enable-strict-mtls". This is a pre-canned policy available by default

Blueprint Add-ons

Save & Exit
Navigate to "Clusters" and update the blueprint of the cluster

Strict mTLS is now enabled for all namespaces in the cluster.

Steps to enable Strict mTLS for a namespace¶

Navigate to "Project" - "Infrastructure" - "Namespaces"
Click edit button an the Namespace
Navigate to "Service Mesh Policies" under "Configuration" tab.
Select "Enable Sidecar Injection"
Click on "Add Policy" and select "enable-strict-mtls". This is a pre-canned policy

Blueprint Add-ons

Go to Placement and select the cluster you want the namespace to be published on
Go to Publish tab and publish the namespace

Strict mTLS is enabled for the selected namespace. Any service communicating with the namespace will have to adhere to strict mTLS or the requests will be rejected by the proxy sidecar.

Verify mTLS in Dashboard¶

To verify cluster level or namespace level mTLS, you can utilize the central dashboard. All connections with mTLS enabled will show a lock icon.

Dashboard is located in Home -> Top Tab. Navigate to "Service Mesh" and you will see 3 filters: Project, Cluster and Namespace. You need to select the project and cluster, and can select one or more namespaces to visualize the network.

Once the graph is loaded, click on the display dropdown and check security.

For the example shown below, Strict mTLS policy was enabled for bar namespace. 'Before strict mTLS policy' shows both the bar and foo namespaces accepting HTTP traffic. With 'After strict mTLS policy', only foo namespace accepts non-HTTPs traffic.

Before strict mTLS policy for bar namespace¶

mTLS use case - Before

After strict mTLS policy for bar namespace¶

mTLS use case - After