troubleshoot icon indicating copy to clipboard operation
troubleshoot copied to clipboard

Allow using kubernetes.io/tls when configuring DB collector TLS secrets

Open banjoh opened this issue 2 years ago • 0 comments

Describe the rationale for the suggested feature.

In addition to our current bespoke specification of how DB collectors expect a TLS secret to look like, we need to allow being able to read k8s TLS secrets since there are higher chances that most environments would have their TLS secrets looking like this.

Describe the feature

Allow collectors reading a TLS secret that looks like this

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
data:
  # the data is abbreviated in this example
  tls.crt: |
        MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
        MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Here is a postgres collector specification connecting to a database secured with TLS. As you can see, the expectation is to have the secret have clientCert, clientKey and cacert. If an environment utilises kubernetes.io/tls, they would need to either create a new secret for the collector to use, or modify the existing one.

spec:
  collectors:
    - postgres:
        collectorName: my-db
        uri: postgresql://user:password@hostname:5432/defaultdb?sslmode=require
        tls:
          secret:
            # This secret must contain the following keys:
            # cacert: <CA PEM cert>
            # clientCert: <Client PEM cert> if mTLS
            # clientKey: <Client PEM key> if mTLS
            name: pg-tls-secret
            namespace: default

We need to extend the implementation to allow looking for tls.crt (eq to clientCert) and tls.key (eq to clientKey) keys in a secret.

banjoh avatar Mar 10 '23 12:03 banjoh