Skip to main content
Version: v4.1

Certificates for Helm 3-deployed sidecars

You can use Cyral's default sidecar-created certificate or use a custom certificate to secure communications between the Cyral control plane and the sidecar.

In this page we provide two ways of deploying a custom certificate to your helm sidecar:

  • using cert-manager to provision the certificate automatically on your cluster; or
  • provisioning a certificate signed by the Certificate Authority of your choice.

The first approach creates a stack for certificate management based on a set of certificate signing and validation methods. The second approach creates a kubernetes secret containing the information from the provisioned certificate.

cert-manager provisioned certificate

This set of instructions makes use of cert-manager, an extension to kubernetes that uses CRDs to easily manage certificates from different sources.


  1. Have a Kubernetes cluster deployed.
  2. Install Helm 3.
  3. Have RBAC permissions to install CRDs.

Installing cert-manager

cert-manager installation is well documented in their documentation. We recommend installing it using helm.

To install the latest version of cert-manager, run the following command:

helm upgrade -i cert-manager cert-manager -n cert-manager --repo --create-namespace --set installCRDs=true

Creating an issuer

An Issuer is a cert-manager resource that configures how your certificate will be validated. The issuer's configuration will vary with your cloud provider and validation method. Refer to the project documentation to create an issuer.

Creating the certificate

After creating an issuer, you need to create a Certificate resource so that cert-manager starts the validation process for your domain using the configuration created in the Issuer from the last step. The certificate should look something like this:

kind: Certificate
name: acme-crt
namespace: <sidecar namespace>
secretName: <certificate secret name>
name: <your issuer name>
# We can reference ClusterIssuers by changing the kind here.
# The default value is Issuer (i.e. a locally namespaced Issuer)
kind: Issuer

This will trigger a chain that will eventually create a tls secret with the name <certificate secret name> on the <sidecar namespace> namespace. This secret name must be provided to the control plane so that the sidecar can use the certificate. See how to do it here.


By default, the sidecar contains permissions to get and watch Secret resources in the namespace it's created in. If you are using a custom ServiceAccount, make sure it has these permissions attached to it.

Use your own certificate

The helm sidecar makes use of tls secrets to read the information from TLS certificates.

You can create the secret from a PEM encoded certificate file and a key file using the following command:

kubectl create secret tls my-tls-secret \
--cert=path/to/cert/file \
--key=path/to/key/file \
--namespace <sidecar namespace>

This secret name must be provided to the control plane so that the sidecar can use the certificate. See how to do it here.