Add ability to monitor validity period for CAs in bundle

[vinny-sabatini]

I would like a way to monitor the validity period of CA's that are distributed managed by trust-manager Bundles. This would help provide visibility if there are CAs in the bundle that are close to expiring that may need to be updated, or removed from the bundle.

My initial thought is this could be achieved via custom Prometheus metrics that provides the Not Before and Not After dates for each CA in the bundle. If we choose this route, @erikgb recommended using metrics similar to cert_not_before and cert_not_after (inspired by https://github.com/ribbybibby/ssl_exporter).

Another option could be to have trust-manager update the .status block of each Bundle CR with the dates for the CA , and then users could use that metadata however they need to in their environments. For example, they could pull that into Prometheus using kube-state-metrics using Custom Resource State Metrics.

/kind feature

[erikgb]

I would vote for native metrics. No need to "pollute" the Bundle API with bundle certificate details. Maybe you could draft how the new metrics could look like, including labels, before implementing? I would be happy to review a PR adding this.

/help

[cert-manager-prow]

@erikgb:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

I would vote for native metrics. No need to "pollute" the Bundle API with bundle certificate details. Maybe you could draft how the new metrics could look like, including labels, before implementing? I would be happy to review a PR adding this.

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[vinny-sabatini]

I am also leaning towards using native metrics. Here is my first draft of the metrics to add. Full disclosure, I am not very familiar with the trust-manager codebase, so I am not sure if there are possible challenges with trying to include the labels I am recommending.

Here are the proposed metrics:

Metric Name	Description	Type
ssl_ca_not_before	A Unix timestamp of the date when the CA validity begins	Gauge
ssl_ca_not_after	A Unix timestamp of the date when the CA validity ends	Gauge

Both metrics should have the same labels, I propose including the following:

Label Name	Description
serial_number	The serial number of the CA
subject_common_name	The common name of the CA's subject
bundle_name	The .metadata.name of the Bundle that the CA is a part of
source_kind	The Kubernetes resource kind that included the CA in the bundle. This would be set to either configmap, secret, or default if it is from a useDefaultCAs source
source_name	The Kubernetes resource name of the ConfigMap or Secret containing the CA, or none if it is from a useDefaultCAs source
source_key	The key within the ConfigMap or Secret containing the CA, or none if it is from a useDefaultCAs source

I considered adding more labels for the other certificate metadata, but I believe the serial_number and subject_common_name should be sufficient to identify a given CA. The remaining labels are intended to help identify which bundle the CA is included in and how it was added to the bundle.

@erikgb let me know what you think!

[erikgb]

@vinny-sabatini I think the metrics make sense, but could we maybe drop the "source" labels in the initial change? We can always add them later on - if needed. WDYT?

[vinny-sabatini]

@erikgb I'm good with removing the "source" labels for the first iteration of these metrics 👍

[terricain]

If no-ones currently working on this, I'll have a go at it 😄

[erikgb]

Thanks @terricain, but I don't know if @vinny-sabatini has already started?

[vinny-sabatini]

Thanks for checking @erikgb I don't think I'll have time to work on this for 2 weeks or so. @terricain feel free to give it a try if you have time before then! I'll check in on this issue when I have some more free time.

[erikgb]

If someone wants to work on this, I would suggest the collector approach that we are currently trying to migrate to in cert-manager, ref. cert-manager/cert-manager#7856.