Description
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status