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.

Prerequisites​

  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 https://charts.jetstack.io --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:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: acme-crt
  namespace: <sidecar namespace>
spec:
  secretName: <certificate secret name>
  dnsNames:
  - my-sidecar.my-domain.com
  issuerRef:
    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
    group: cert-manager.io

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.

warning

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.