TLS server verification

A TLS section is part of Stackable CRDs and describes how to connect to a TLS enabled system like LDAP or S3.

If the tls attribute is set to null (or is not specified), no TLS will be used for the connection.

A simple TLS section looks like this:

# [...]
tls:
  verification:
    none: {}

Verification

The parties participating via a TLS connection can be verified using certificates. At the moment the following verification methods are supported:

No verification

This example will use TLS but not perform any checks on the certificate presented by the server or present a client certificate if asked for one by the server.

tls:
  verification:
    none: {}

Server verification

This example will use TLS and verify the server using the ca certificates that are trusted by common web browsers. This can be useful when you e.g. use public AWS S3 or other public available services.

tls:
  verification:
    server:
      caCert:
        webPki: {}

This example will use TLS and verify the server using the provided CA certificate. The product CRD references a SecretClass that provides the CA certificate to verify the server against:

tls:
  verification:
    server:
      caCert:
        secretClass: openldap-tls-ca

The referenced openldap-tls-ca SecretClass does not exist yet, you have to create it. For server verification you only need to make the CA certificate available to the product as-is, so you use the k8sSearch backend, which mounts the contents of a Kubernetes Secret into the Pod. A SecretClass used only for server verification needs nothing but the CA certificate, it does not need a key. So if you were provided with a CA certificate but do not have access to its key, you can still use this method.

First, store the CA certificate (in PEM format) that you were given in a Secret. The Secret must carry the label secrets.stackable.tech/class matching the SecretClass name, and the CA certificate must be stored under the key ca.crt:

---
apiVersion: v1
kind: Secret
metadata:
  name: openldap-tls-ca
  labels:
    secrets.stackable.tech/class: openldap-tls-ca (1)
stringData:
  ca.crt: | (2)
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
1 This label must match the name of the SecretClass created below.
2 The CA certificate in PEM format.

Then create the SecretClass that uses the k8sSearch backend to find that Secret:

---
apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: openldap-tls-ca (1)
spec:
  backend:
    k8sSearch:
      searchNamespace:
        pod: {} (2)
1 The name of the SecretClass, this is what caCert.secretClass above refers to. It must match the Secret’s secrets.stackable.tech/class label.
2 The backend looks for the labeled Secret in the same namespace as the Pod that consumes the certificate.

Mutual verification

This example will use TLS and verify both - the server and the client using certificates. For this to work you need to create a SecretClass containing the ca certificate and a key to create new client-certificates. The Stackable Secret Operator will automatically provide the product with a ca.crt, tls.crt and tls.key so that the product can authenticate the server and it can authenticate itself at the server.

tls:
  verification:
    mutual:
      certSecretClass: openldap-tls