Giter Site home page Giter Site logo

enix / x509-certificate-exporter Goto Github PK

View Code? Open in Web Editor NEW
598.0 17.0 57.0 1.08 MB

A Prometheus exporter to monitor x509 certificates expiration in Kubernetes clusters or standalone

License: MIT License

Dockerfile 1.10% Go 89.70% Shell 2.91% Smarty 0.56% Mustache 5.74%
prometheus-exporter kubernetes monitoring-tool certificates expiration-monitoring dashboard grafana-dashboard certificates-focusing alert

x509-certificate-exporter's Introduction

🔏 X.509 Certificate Exporter

Build status Code coverage Go Report License MIT Brought by Enix

A Prometheus exporter for certificates focusing on expiration monitoring, written in Go. Designed to monitor Kubernetes clusters from inside, it can also be used as a standalone exporter.

Get notified before they expire:

  • PEM encoded files, by path or scanning directories
  • Kubeconfigs with embedded certificates or file references
  • TLS Secrets from a Kubernetes cluster

Grafana Dashboard

Installation

🏃 TL; DR

The Helm chart is the most straightforward way to get a fully-featured exporter running on your cluster. The chart is also highly-customizable if you wish to. See the chart documentation to learn more.

The provided Grafana Dashboard can also be used to display the exporter's metrics on your Grafana instance.

Using Docker

A docker image is available at enix/x509-certificate-exporter.

Using the pre-built binaries

Every release comes with pre-built binaries for many supported platforms.

Using the source

The project's entry point is ./cmd/x509-certificate-exporter. You can run & build it as any other Go program:

go build ./cmd/x509-certificate-exporter

Usage

The following metrics are available:

  • x509_cert_not_before
  • x509_cert_not_after
  • x509_cert_expired
  • x509_cert_expires_in_seconds (optional)
  • x509_cert_valid_since_seconds (optional)
  • x509_cert_error (optional)
  • x509_read_errors
  • x509_exporter_build_info

Prometheus Alerts

When installation is not performed with Helm, the following Prometheus alerting rules may be deployed manually:

rules:
    - alert: X509ExporterReadErrors
        annotations:
            description: Over the last 15 minutes, this x509-certificate-exporter instance
                has experienced errors reading certificate files or querying the Kubernetes
                API. This could be caused by a misconfiguration if triggered when the exporter
                starts.
            summary: Increasing read errors for x509-certificate-exporter
        expr: delta(x509_read_errors[15m]) > 0
        for: 5m
        labels:
            severity: warning
    - alert: CertificateRenewal
        annotations:
            description: Certificate for "{{ $labels.subject_CN }}" should be renewed
                {{if $labels.secret_name }}in Kubernetes secret "{{ $labels.secret_namespace
                }}/{{ $labels.secret_name }}"{{else}}at location "{{ $labels.filepath }}"{{end}}
            summary: Certificate should be renewed
        expr: ((x509_cert_not_after - time()) / 86400) < 28
        for: 15m
        labels:
            severity: warning
    - alert: CertificateExpiration
        annotations:
            description: Certificate for "{{ $labels.subject_CN }}" is about to expire
                {{if $labels.secret_name }}in Kubernetes secret "{{ $labels.secret_namespace
                }}/{{ $labels.secret_name }}"{{else}}at location "{{ $labels.filepath }}"{{end}}
            summary: Certificate is about to expire
        expr: ((x509_cert_not_after - time()) / 86400) < 14
        for: 15m
        labels:
            severity: critical

Advanced usage

For advanced configuration, see the program's --help:

Usage: x509-certificate-exporter [-hv] [-b value] [--debug] [-d value] [--exclude-label value] [--exclude-namespace value] [--expose-per-cert-error-metrics] [--expose-relative-metrics] [-f value] [--include-label value] [--include-namespace value] [--kubeconfig path] [-k value] [-l value] [--max-cache-duration value] [--profile] [-s value] [--trim-path-components value] [--watch-kube-secrets] [--web.config.file value] [--web.systemd-socket] [parameters ...]
 -b, --listen-address=value
                address on which to bind and expose metrics [:9793]
     --debug    enable debug mode
 -d, --watch-dir=value
                watch one or more directory which contains x509 certificate
                files (not recursive)
     --exclude-label=value
                removes the kube secrets with the given label (or label
                value if specified) from the watch list (applied after
                --include-label)
     --exclude-namespace=value
                removes the given kube namespace from the watch list
                (applied after --include-namespace)
     --expose-per-cert-error-metrics
                expose additionnal error metric for each certificate
                indicating wether it has failure(s)
     --expose-relative-metrics
                expose additionnal metrics with relative durations instead
                of absolute timestamps
 -f, --watch-file=value
                watch one or more x509 certificate file
 -h, --help     show this help message and exit
     --include-label=value
                add the kube secrets with the given label (or label value if
                specified) to the watch list (when used, all secrets are
                excluded by default)
     --include-namespace=value
                add the given kube namespace to the watch list (when used,
                all namespaces are excluded by default)
     --kubeconfig=path
                Path to the kubeconfig file to use for requests. Takes
                precedence over the KUBECONFIG environment variable, and
                default path (~/.kube/config).
 -k, --watch-kubeconf=value
                watch one or more Kubernetes client configuration (kind
                Config) which contains embedded x509 certificates or PEM
                file paths
 -l, --expose-labels=value
     --max-cache-duration=value
                maximum cache duration for kube secrets. cache is per
                namespace and randomized to avoid massive requests.
     --profile  optionally enable a pprof server to monitor cpu and memory
                usage at runtime
 -s, --secret-type=value
                one or more kubernetes secret type & key to watch (e.g.
                "kubernetes.io/tls:tls.crt"
     --trim-path-components=value
                remove <n> leading component(s) from path(s) in label(s)
 -v, --version  show version info and exit
     --watch-kube-secrets
                scrape kubernetes secrets and monitor them
     --web.config.file=value
                [EXPERIMENTAL] path to configuration file that can enable
                TLS or authentication
     --web.systemd-socket
                use systemd socket activation listeners instead of port
                listeners (Linux only)

Development

Some snippets to get started with development and testing:

# Run server, watch test input files, only listen on localhost to
# avoid firewall popup dialogs
go run ./cmd/x509-certificate-exporter --debug -b localhost:9793 -d test/

# Once the server is running, you can check the exported metrics
curl -Ss localhost:9793/metrics | grep "^x509_cert_not_after"

# Automated tests work against a Kubernetes cluster, so create a throwaway
# cluster (for example with kind). Do not run the server locally because the
# tests run the server executable with the default listening port.
kind create cluster --kubeconfig ~/.kube/config-kind
export KUBECONFIG=~/.kube/config-kind
go test -v ./internal
kind delete cluster

# Docker build (does not run tests)
docker buildx build .

FAQ

Why are you using the not after timestamp rather than a remaining number of seconds?

For two reasons.

First, Prometheus tends to do better storage consumption when a value stays identical over checks.

Then, it is better to compute the remaining time through a prometheus query as some latency (seconds) can exist between this exporter check and your alert or query being run.

Here is an example:

x509_cert_not_after - time()

When collecting metrics from tools like Datadog that does not have timestamp functions, the exporter can be run with the --expose-relative-metrics flag in order to add the following optional metrics:

  • x509_cert_valid_since_seconds
  • x509_cert_expires_in_seconds

How to ensure it keeps working over time?

Changes in paths or deleted files may silently break the ability to watch critical certificates.

Because it's never convenient to alert on disapearing metrics, the exporter will publish on x509_read_errors how many paths could not be read. It will also count Kubernetes API responses failures, but won't count deleted secrets.

A basic alert would be:

x509_read_errors > 0

x509-certificate-exporter's People

Contributors

abuisine avatar andidog avatar arcln avatar benjaminherbert avatar chdorb avatar dependabot[bot] avatar flyffies avatar jfcoz avatar kokes avatar npdgm avatar olivernadj avatar paullaffitte avatar piotrrotter avatar programmeris avatar rdegez avatar seanorama avatar someone-stole-my-name avatar tacerus avatar tassatux avatar v0ctor avatar vi7 avatar vutkin avatar windzcuhk avatar zwindler avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

x509-certificate-exporter's Issues

Can't see nothing on grafana with kube-prometheus-stack

Hi Guys!
I've installed Prometheus and Grafana with the kube-prometheus-stack helm, and then i've installed the x509-certificate-exporter helm.
I've tried different configurations but no one work, i can't see new metrics on prometheus and i can't see the kubernetes\Certificates (x509-exporter) folder on grafana.
My tests:

  • Normal installation with Helm without change the values.yaml in the same namespace of kube-prometheus-stack
  • Normal installation with Helm without change the values.yaml in a different namespace
  • This values config: (all values in different combinations)
         "prometheusServiceMonitor":
            "create": true
            "extraLabels":
              "release": "kube-prometheus-stack"
          "prometheusPodMonitor":
            "create": true
            "extraLabels":
              "release": "kube-prometheus-stack"
          "prometheusRules":
            "extraLabels":
              "release": "kube-prometheus-stack"
          "secretsExporter":
            "podExtraLabels":
              "release": "kube-prometheus-stack"
          "service":
            "extraLabels":
              "release": "kube-prometheus-stack"
          "hostPathsExporter":
            "podExtraLabels":
              "release": "kube-prometheus-stack"

I'm using the x509 latest version 3.6.0, and the 41.6.1 kube-prometheus-stack version.

I don't know if i have to add other values or if i've to change something into the kube-prometheus-stack values.yaml.
If i see the x509 pod it is un and running and log say that everything is fine, and if i see the prometheus-operator logs there are nothing about the x509-certificate-exporter.

I don't know what else to do, please help me.

create rule only for the api

Hey

I just installed the chart on my ocp cluster, and I want only to monitor the crt of the api.
Could someone help me achieve my goal?
Until now I set prometeusrule.create = false in order to create my own prometeusrules.
and I created with this configuration:

- alert: certificate
   rules: 
   - alert: certificate-expired
      annotations:
        description: Certificate of "{{ $labels.subject_CN }}" is about to end in {{ $value }} days
                {{if $labels.secret_name }}in Kubernetes secret "{{ $labels.secret_namespace
                }}/{{ $labels.secret_name }}"{{else}}
        summary: Certificate is about to expire
      expr: ((x509_cert_not_after - time()) / 86400) < 30
      for: 1h
      labels:
          severity: critical

pre-built binaries does not show version

as title

setup

wget https://github.com/enix/x509-certificate-exporter/releases/download/v3.0.0/x509-certificate-exporter-linux-amd64
chmod +x ./x509-certificate-exporter-linux-amd64

current result

$ ./x509-certificate-exporter-linux-amd64 --version
version 0.0.0

expected result

$ ./x509-certificate-exporter-linux-amd64 --version
version 3.0.0

OS

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.9.2009 (Core)
Release:	7.9.2009
Codename:	Core

Allow Kubernetes TLS Secrets with CA certificate only

In some of our namespaces, Kubernetes TLS Secrets exist that hold a CA certificate only, i.e., the key ca.crt is not empty while tls.crt and tls.key are. This raises warnings for the X.509 Certificate Exporter and an error count in metric x509_read_errors:

time="2021-10-29T15:57:48Z" level=warning msg="no certificate(s) found in \"k8s/grafana/repo-tls-cert\""
time="2021-10-29T15:57:48Z" level=warning msg="no certificate(s) found in \"k8s/log/repo-tls-cert\""

Sample secret:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
metadata:
  creationTimestamp: "2021-04-20T07:20:35Z"
  name: repo-tls-cert
  namespace: log
  resourceVersion: "170394169"
  selfLink: /api/v1/namespaces/log/secrets/repo-tls-cert
  uid: 00cdec3c-4f30-47cc-9fcb-83a21edeb81d
data:
  ca.crt: LS...
  tls.crt: ""
  tls.key: ""

It would be nice to have a switch that allows CA-certificate-only secrets that do not raise warnings. For me, only a Kubernetes Secret that holds neither ca.crt nor tls.crt is something to worry about.

The memory gradually increases and finally triggers the oom

args:
--listen-address=:9793
--trim-path-components=3
--watch-dir=/mnt/watch/dir-data-server//data/apps/rancher/k3s/server/tls/
--watch-dir=/mnt/watch/dir-data-agent//data/apps/rancher/k3s/agent/
--watch-dir=/mnt/watch/dir-thc-server//thc/apps/rancher/k3s/server/tls/
--watch-dir=/mnt/watch/dir-thc-agent//thc/apps/rancher/k3s/agent/
--max-cache-duration=300s

At the beginning, the memory is limited to 40M, and the oom is triggered all the time. Recently, it has increased to 50M

image

lighten the docker image

Over 900MB is excessive for a Python container with little dependencies.
Let's find how much we can save while keeping a Debian base.

Listening address

Hi,

apologies if I missed something - but from what I can see it's only possible to specify the listening port via the available command line arguments. Is there a way to specify the listening/bind address as well?

Best,
Georg

In watch mode the exporter does not remove deleted secrets

Very nice tool and dashboard. Thanks.

I don't know if this is expected behaviour, but 24 hours after running with --watch-kube-secrets, I could still see metrics for secrets that no longer existed.

Shouldn't the exporter remove them and no longer generate Prometheus metrics for them?

I wanted to add another label to indicate if the cert was a CA or not as my organization mixes them up which seems to work..

diff --git a/internal/exporter.go b/internal/exporter.go
index e67a29d..d3fb6a1 100644
--- a/internal/exporter.go
+++ b/internal/exporter.go
@@ -250,6 +250,10 @@ func (exporter *Exporter) getLabels(certData *parsedCertificate, ref *certificat
        fillLabelsFromName(&certData.cert.Issuer, "issuer", labels)
        fillLabelsFromName(&certData.cert.Subject, "subject", labels)
 
+       if certData.cert.BasicConstraintsValid && certData.cert.IsCA {
+               labels["is_CA"] = "true"
+       }
+
        if ref.format == certificateFormatYAML {
                kind := strings.Split(certData.yqMatchExpr, ".")[1]
                labels["embedded_kind"] = strings.TrimRight(kind, "s")

But on running a test against the test certs I saw that the bad link pem was getting parsed without error...

$ ./x509-certificate-exporter -d test/
INFO[0000] starting x509-certificate-exporter version 0.0.0 () () 
INFO[0000] 1 valid certificate(s) found in "test/badlink.pem" 
INFO[0000] 1 valid certificate(s) found in "test/basic.pem" 

and generating metrics...

x509_cert_expired{filename="badlink.pem",filepath="test/badlink.pem",is_CA="true",issuer_CN="kubernetes",serial_number="0",subject_CN="kubernetes"} 0
x509_cert_not_after{filename="badlink.pem",filepath="test/badlink.pem",is_CA="true",issuer_CN="kubernetes",serial_number="0",subject_CN="kubernetes"} 1.861190854e+09
x509_cert_not_before{filename="badlink.pem",filepath="test/badlink.pem",is_CA="true",issuer_CN="kubernetes",serial_number="0",subject_CN="kubernetes"} 1.545830854e+09

even though it truly does not exist...

$ ls -l test/badlink.pem 
lrwxrwxrwx 1 me me 15 Nov 21 15:44 test/badlink.pem -> /toto/basic.pem

Feature request: Customize exposed tags

Hi guys,

I'm wondering if there is any plan to customize tags exposed by the exporter?

Exemple :

Here is a line provided by the exporter. For some use-case, we want to have fewer tags (to avoid too much cardinality, or avoid unneeded field like serial, subjet_* or issuer*)

x509_cert_expired{issuer_C="FR",issuer_CN="Root Certificate Authority",issuer_L="Paris",issuer_O="Daily",issuer_OU="XXX",secret_key="tls.crt",secret_name="test-cert-tls",secret_namespace="donch",serial_number="720995349510415XXXXX",subject_C="FR",subject_CN="Daily Cert Manager",subject_L="Paris",subject_O="Daily",subject_OU="XXXXX"} 0

Let me know if it makes sense!

Thanks

Allow extravolumes / extramounts

Hi guys, I would like to thank you for this really cool exporter.
One of my application uses a cert stored in a K8S secret and I was guessing if it could be possible to mount this secret and add a watchfile to this one ? Could be really cool to monitor K8S cert as my app cert with the same exporter.
Regards,
Seb.

x509-exporter should not go in subdirectories

I see two problems in that :

  • while monitoring /etc/kubernetes/pki it handles /etc/kubernetes/pki/expired which is created by standard kubeadm installations
  • x509-exporter test all files and tries to recognize a certificate, it might be dangerons to walk through hundreds of subdirectories

Feature: Support list of URLs to monitor

Hello, this tool looks great!

We would love to use it in addition to the existing features, to monitor application certificates which might not be running on Kubernetes. Similar to the tool doomsday, what I propose is a configuration option like so:

monitorUrls:
- https://example.com
- https://my-app.com

This would check the certificate being served and export metrics about it.

Thanks!

Prometheus and x509.yml files

Hi team,

Could you please advise about the Prometheus configuration in order to use it with Prometheus and Grafana.
I am looking for something like this:

prometheus.yml
  # Example job [icmp] module
  - job_name: 'x509'
    static_configs:
      - targets:  ['ip2', 'ip1']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        # Blackbox exporter Host:Port
        replacement: localhost:9115
x509.yml
modules:
  x509:
    prober: http

Could you please provide these kind of configuration files? I plan to use it standalone not with K8s or Helm.

Cheers!

Workflow with multiple clusters?

Greetings dear devs!

Thanks for your work. I'm curious on what's the best way to integrate K8S cert monitoring when we utilize multiple K8S clusters. What's the best way to integrate multiple instances? We have our own instances of Prometheus and grafana at our disposal. Should we, for instance, deploy the x509-cert-exporter to each K8S cluster and then tie everything together somehow?

This might be a question worth adding to FAQ as I believe it's a common scenario.

Thanks!

Permission denied when trying to monitor etcd certificates

Hello!

Faced a problem. Kubernetes is installed via kubespray, consists of three nodes, etcd is located on the master. Etcd certificates are located along the path /etc/ssl/etcd/ssl/ when I specify this path for watchDirectories: or watchFiles: (with files, of course), then I see an error in the daemonSet logs:

time="2023-05-03T10:11:28Z" level=info msg="starting x509-certificate-exporter version 3.6.0 (0dd5e2318ae07e33778a72f53cd6e6ac8dbe0931) (2022-10-27T14:48:05)"
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-c5e9b51d88044edc7de3c1b540990d4fbcdf87ef/etc/kubernetes/ssl/ca.crt\""
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-b13de134696fab137f243493eae5493902d9c057/etc/kubernetes/ssl/apiserver.crt\""
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-303016caf2c2dcf143ae81f3bdfff1a4416e971f/etc/kubernetes/ssl/front-proxy-ca.crt\""
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-10eec3d89e58905ed9bee454023b567740b8c61d/etc/kubernetes/ssl/front-proxy-client.crt\""
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-9dff78b77fe2f4b0f34f77796df3fea5983e5d4b/var/lib/kubelet/pki/kubelet-client-current.pem\""
time="2023-05-03T10:11:28Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/file-88342fb5a8e3b25b77edf9314d09a8071f49ec12/etc/kubernetes/ssl/apiserver-kubelet-client.crt\""
time="2023-05-03T10:11:28Z" level=warning msg="failed to parse \"/mnt/watch/file-2c2c29989a0af2cb490cf35eeead9cf737d85f62/etc/ssl/etcd/ssl/ca.pem\", open /mnt/watch/file-2c2c29989a0af2cb490cf35eeead9cf737d85f62/etc/ssl/etcd/ssl/ca.pem: permission denied"
time="2023-05-03T10:11:28Z" level=warning msg="failed to parse \"/mnt/watch/file-44755413db0f5e28668b702a04eff611bdd662ef/etc/ssl/etcd/ssl/node-dc3tlabkubm01.pem\", open /mnt/watch/file-44755413db0f5e28668b702a04eff611bdd662ef/etc/ssl/etcd/ssl/node-dc3tlabkubm01.pem: permission denied"
time="2023-05-03T10:11:28Z" level=warning msg="failed to parse \"/mnt/watch/file-b8ae9555d965a32a4d807c3fa6e7158946987b37/etc/ssl/etcd/ssl/node-dc3tlabkubm01-key.pem\", open /mnt/watch/file-b8ae9555d965a32a4d807c3fa6e7158946987b37/etc/ssl/etcd/ssl/node-dc3tlabkubm01-key.pem: permission denied"
time="2023-05-03T10:11:29Z" level=info msg="2 valid certificate(s) found in \"/mnt/watch/kube-35a4fcc6ab089d789fecaeed428cc8392148766a/etc/kubernetes/admin.conf\""
time="2023-05-03T10:11:29Z" level=info msg="2 valid certificate(s) found in \"/mnt/watch/kube-ee9e4e203c758bb95ec439d60c16fb4e8854efaf/etc/kubernetes/scheduler.conf\""
time="2023-05-03T10:11:29Z" level=info msg="2 valid certificate(s) found in \"/mnt/watch/kube-41a6b8b147ef309a70619cafcfeb8961b3c29cae/etc/kubernetes/controller-manager.conf\""
time="2023-05-03T10:11:29Z" level=info msg="parsed 12 certificates (3 read failures)"
time="2023-05-03T10:11:29Z" level=info msg="listening on :9793"

When checking the permissions on files, I see that they belong to the user etcd

[root@dc3tlabkubm01 ssl]# ll /etc/ssl/etcd/ssl/
total 48
-rwx------. 1 etcd root 1675 Dec  9 16:56 admin-dc3tlabkubm01-key.pem
-rwx------. 1 etcd root 1383 Dec  9 16:56 admin-dc3tlabkubm01.pem
-rwx------. 1 etcd root 1675 Dec  9 16:55 ca-key.pem
-rwx------. 1 etcd root 1090 Dec  9 16:55 ca.pem
-rwx------. 1 etcd root 1675 Dec  9 16:56 member-dc3tlabkubm01-key.pem
-rwx------. 1 etcd root 1383 Dec  9 16:56 member-dc3tlabkubm01.pem
-rwx------. 1 etcd root 1679 Dec  9 16:56 node-dc3tlabkubm01-key.pem
-rwx------. 1 etcd root 1379 Dec  9 16:56 node-dc3tlabkubm01.pem
-rwx------. 1 etcd root 1675 Dec  9 16:56 node-dc3tlabkubn01-key.pem
-rwx------. 1 etcd root 1379 Dec  9 16:56 node-dc3tlabkubn01.pem
-rwx------. 1 etcd root 1679 Dec  9 16:56 node-dc3tlabkubn02-key.pem
-rwx------. 1 etcd root 1379 Dec  9 16:56 node-dc3tlabkubn02.pem

Please tell me what is the reason for this error? Thank you very much!

OpenBSD release builds

Hello!

Any chance we could get builds for OpenBSD published as part of future releases?

Best,
Georg

[Enhancement] Watch for certificates in subdirectories for path specified in "watchDirectories" attribute.

Discussed in #107

Originally posted by porwalameet February 28, 2023
Hi All,
Thanks for this wonderful project which helps us monitor certificates on Kubernetes Cluster.

We are using daemonset mode with "watchDirectories" setting. This address most of our use-case, however at times we have certificates mounted onto pod-filesystem directly using CSI Volumes or configMap.
Example:
A certificate is stored in Hashicorp Vault or Azure KeyVault, and using CSI, we can pull these certificates and mount directly on pods.

Here there are no kubernetes secret created and wish to monitor these certificates as well.

However, the files reside on respective node filesystem where pod is run in /var/lib/kubelet/pods/<pod-uid>/volumes/<volume-type>. The pod UID is unique and dynamic uid which is assigned to a running pod and remains till the pod lifetime.
On host Node, it looks something like below:

# pwd
/var/lib/kubelet/pods/c5ce7790-8260-4e30-8f56-8ef6a374f755/volumes
# ls -ltr
total 0
drwxr-xr-x 3 root root  27 Feb 27 10:24 kubernetes.io~downward-api
drwxr-xr-x 5 root root  67 Feb 27 10:24 kubernetes.io~configmap
drwxr-xr-x 7 root root 103 Feb 27 10:24 kubernetes.io~empty-dir
drwxr-xr-x 4 root root  54 Feb 27 10:24 kubernetes.io~projected

So, to address this we can specify watchDirectories as /var/lib/kubelet/pods/*/volumes or just /var/lib/kubelet/pods/, which scans all pod directories and appends to existing list for the files scanned and follow the basic flow of parsing certificates.

As watchDirectories configuration monitors only files within the specified path, is there any work going on to address recursive parsing in subdirectories.

Thanks.

Push image to quay.io

It would be nice to also push the image to another container registry like quay.io.
Docker.io has pull limits, which can cause problems.

failed to parse some labels in kubeconfig

After configure x509-certificate-exporter to parse kubeconfig warning is generated and certificate is marked as failed:

time="2022-01-30T05:51:30Z" level=warning msg="failed to parse \"/mnt/watch/kube-2668e6e60f5eba4364882db368b2e2c9b543596a/var/lib/kubelet-config/kubeconfig\", failed to parse some labels in /mnt/watch/kube-2668e6e60f5eba4364882db368b2e2c9b543596a/var/lib/kubelet-config/kubeconfig (got 1 IDs but 0 certs for \"$.clusters[:].name\")"

kubeconfig content from /var/lib/kubelet-config/kubeconfig:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <redacted base64 encoded cert data>
    server: https://kubernetes-control-plane.example.com:6443
  name: kube-res-dev
contexts:
- context:
    cluster: kube-res-dev
    user: system:node:dev-k8s-worker-r1
  name: default-context
current-context: default-context
users:
- name: system:node:dev-k8s-worker-r1
  user:
    client-certificate-data: <redacted base64 encoded cert data>
    client-key-data: <redacted base64 encoded cert data>

Kubeconfig itself is valid and used by kubernetes components with no issues.

DaemonSet used for cert monitoring:

---
# Source: x509-certificate-exporter/templates/daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: x509-certificate-exporter-nodes
  labels:
    helm.sh/chart: x509-certificate-exporter-1.20.0
    app.kubernetes.io/name: x509-certificate-exporter
    app.kubernetes.io/instance: x509-certificate-exporter
    app.kubernetes.io/version: "2.12.0"
    app.kubernetes.io/managed-by: Helm
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: x509-certificate-exporter
      app.kubernetes.io/instance: x509-certificate-exporter
  template:
    metadata:
      labels:
        helm.sh/chart: x509-certificate-exporter-1.20.0
        app.kubernetes.io/name: x509-certificate-exporter
        app.kubernetes.io/instance: x509-certificate-exporter
        app.kubernetes.io/version: "2.12.0"
        app.kubernetes.io/managed-by: Helm
    spec:
      serviceAccountName: default
      tolerations:
      - operator: Exists
      restartPolicy: Always
      containers:
      - name: x509-certificate-exporter
        securityContext:
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: true
          runAsGroup: 0
          runAsUser: 0
        resources:
          limits:
            cpu: 100m
            memory: 40Mi
          requests:
            cpu: 10m
            memory: 20Mi
        image: docker.io/enix/x509-certificate-exporter:2.12.0
        imagePullPolicy: IfNotPresent
        args:
        - --listen-address=:9793
        - --trim-path-components=3
        - --watch-kubeconf=/mnt/watch/kube-2668e6e60f5eba4364882db368b2e2c9b543596a//var/lib/kubelet-config/kubeconfig
        - --max-cache-duration=300s
        volumeMounts:
        - name: kube-2668e6e60f5eba4364882db368b2e2c9b543596a
          mountPath: /mnt/watch/kube-2668e6e60f5eba4364882db368b2e2c9b543596a//var/lib/kubelet-config
          #subPath: kubeconfig
          readOnly: true
        ports:
        - name: metrics
          containerPort: 9793
      hostNetwork: false
      volumes:
      - name: kube-2668e6e60f5eba4364882db368b2e2c9b543596a
        hostPath:
          path: /var/lib/kubelet-config
          type: Directory

Use hostPath to watch all certificates in node (if running in daemonset mode)

We can use hostPath to bind the current node's /etc/kubernetes/ path to watch all certificates if running mode is DaemonSet.

  • /etc/kubernetes/pki/*.crt
  • /etc/kubernetes/ssl/*.crt
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/client.crt
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/server.crt

Wdyt?

Handle Password protected certificates

Hi,

we have certificates which are password protected and we would like to monitor them.
Looking at the docs, I don't see any reference to it and the implementation doesn't handle it here :

cert, err := x509.ParseCertificate(block.Bytes)

We foresee an implementation as follows :

  • the certificate object in k8s has a label annotation that indicates the secret that holds the password to decode the certificate
  • the exporter is capable of reading the certificate and then discover that there is an associated password and reads it to decode the certificate
  • after this decode, the rest of the processing pipeline goes as usual

Does this make sense?

Dali

Handling certificate errors gracefully

Thanks for creating the exporter, it's very valuable to get information about certificates!

Right now, if we have a k8s tls secret whose certificate has duplicate entries (eg: #18) - this brings the entire exporter down. Manually trying to scrape the metrics gives 500:

$ curl -vv http://cm-x509-certificate-exporter-headless:9793/metrics
*   Trying 192.168.0.6:9793...
* TCP_NODELAY set
* Connected to cm-x509-certificate-exporter-headless (192.168.0.6) port 9793 (#0)
> GET /metrics HTTP/1.1
> Host: cm-x509-certificate-exporter-headless:9793
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< date: Mon, 10 Jan 2022 06:24:48 GMT
< x-envoy-upstream-service-time: 185
< server: envoy
< transfer-encoding: chunked
<
An error has occurred while serving metrics:

6 error(s) occurred:
* collected metric "x509_cert_expired" { label:<name:"issuer_C", ...}
....
* Connection #0 to host cm-x509-certificate-exporter-headless left intact

Also the prometheus indicates that the exporter is down.

So IMO if there is an issue with a certificate, it should ignore those specific certificate instead of the entire exporter being down.

data missing in grafana dashboard

hello,

I followed chart installation as per instructions keeping all default values provided but could not get data in dashboard and tried with modifying values.yaml for data to get scrape to grafana

tried with below content as well but no luck.

chart installation was done right but missing something to get data in dashboard. I was able to get kubernetes cluster data in another dashboard to monitor like cluster memory and cpu.

Please advise

helm upgrade x509-certificate-exporter enix/x509-certificate-exporter --values myvalues.yaml

hostPathsExporter:
daemonSets:
nodes:
watchFiles:
- /var/lib/kubelet/pki/kubelet-client-current.pem
- /etc/kubernetes/pki/apiserver.crt
- /etc/kubernetes/pki/apiserver-etcd-client.crt
- /etc/kubernetes/pki/apiserver-kubelet-client.crt
- /etc/kubernetes/pki/ca.crt
- /etc/kubernetes/pki/front-proxy-ca.crt
- /etc/kubernetes/pki/front-proxy-client.crt
- /etc/kubernetes/pki/etcd/ca.crt
- /etc/kubernetes/pki/etcd/healthcheck-client.crt
- /etc/kubernetes/pki/etcd/peer.crt
- /etc/kubernetes/pki/etcd/server.crt
watchKubeconfFiles:
- /etc/kubernetes/admin.conf

  Thanks

Prometheus metrics was collected before with the same name and label values error

Hello! I have installed x509-certificate-exporter for prometheus metrics expose on my k8s cluster. When I go to the endpoint with prometheus metrics (http://localhost:9793/metrics) I get some errors like:

6 error(s) occurred:
* collected metric "x509_cert_expired" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"xxx" > label:<name:"issuer_O" value:"IRCS" > label:<name:"secret_key" value:"cert.crt" > label:<name:"secret_name" value:"default-cert" > label:<name:"secret" value:"cert" > label:<name:"serial_number" value:"12345678901234567890" > label:<name:"subject_C" value:"EU" > label:<name:"subject_CN" value:"M1" > label:<name:"subject_O" value:"OK" > gauge:<value:0 > } was collected before with the same name and label values

Logs of the x509-certificate-exporter pod looks ok:

time="2021-09-11T18:43:07Z" level=info msg="fetching configuration from within the cluster"
time="2021-09-11T18:43:07Z" level=info msg="loaded configuration, API server is at https://112.65.0.1:443"
time="2021-09-11T18:43:07Z" level=info msg="fetching API server version"
time="2021-09-11T18:43:07Z" level=info msg="kubernetes server version is v1.19.7"
time="2021-09-11T18:43:07Z" level=info msg="starting x509-certificate-exporter version 2-10-0"
time="2021-09-11T18:43:08Z" level=info msg="5 valid certificate(s) found in \"k8s/app/default-cert\""
time="2021-09-11T18:43:08Z" level=info msg="parsed 5 certificates (0 read failures)"
time="2021-09-11T18:43:08Z" level=info msg="listening on :9793"

What can cause this problem and how I can fix it? Maybe it is a bug or my mistake? Thank you for your help!

[x509-certificate-exporter] prometheusServiceMonitor: coalesce.go:220: warning: cannot overwrite table with non table

Relabelings config for ServiceMonitor and PodMonitor generates warning:

coalesce.go:220: warning: cannot overwrite table with non table for x509-certificate-exporter.prometheusServiceMonitor.relabelings (map[])

Example.
values.yaml:

prometheusServiceMonitor:
  relabelings:
  - targetLabel: job
    replacement: x509-certificate-exporter

Generate helm manifests:

$ helm template x509-certificate-exporter enix/x509-certificate-exporter -f values.yaml
coalesce.go:220: warning: cannot overwrite table with non table for x509-certificate-exporter.prometheusServiceMonitor.relabelings (map[])
[...]

What's interesting it generates valid ServiceMonitor:

---
# Source: x509-certificate-exporter/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: x509-certificate-exporter
  labels:
    helm.sh/chart: x509-certificate-exporter-1.20.0
    app.kubernetes.io/name: x509-certificate-exporter
    app.kubernetes.io/instance: x509-certificate-exporter
    app.kubernetes.io/version: "2.12.0"
    app.kubernetes.io/managed-by: Helm
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: x509-certificate-exporter
      app.kubernetes.io/instance: x509-certificate-exporter
  endpoints:
  - port: metrics
    interval: 60s
    scrapeTimeout: 10s
    relabelings:
      - replacement: x509-certificate-exporter
        targetLabel: job

Also documentation for prometheusServiceMonitor.relabelings and prometheusPodMonitor.relabelings says that it's type object but it should be a list, after prometheus-operator API docs https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#endpoint:

 relabelings []*RelabelConfig

Do not treat "non-PEM" files as exporter errors

Hi All,

First of all, thanks a lot for this great project that drastically help monitoring certificate expiration on self-managed Kubernetes clusters!

We are using it in DaemonSet mode with the watchDirectories setting to specify which directories should be monitored. This is very handy, as new certificates that will be stored in these directories will automatically be monitored. BUT... These directories also contain other files (like .key, .csr, .conf, etc.), which are not meant to be monitored by this tool. Unfortunately, these files are reported as "exporter errors" and are "polluting" our alerting system.

Question: Is there a way to prevent the "non-PEM" files to be treated as exporter errors?

Thanks in advance for your help!

❯ k logs -f x509-certificate-exporter-controlplane-6jcpw
time="2023-01-09T09:26:16Z" level=info msg="starting x509-certificate-exporter version 3.6.0 (0dd5e2318ae07e33778a72f53cd6e6ac8dbe0931) (2022-10-27T14:48:07)"
time="2023-01-09T09:26:16Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/dir-891a355f5967c209def0469b890e5f2f129fc1de/etc/kubernetes/pki/etcd/peer.crt\""
time="2023-01-09T09:26:16Z" level=warning msg="no certificate(s) found in \"/mnt/watch/dir-891a355f5967c209def0469b890e5f2f129fc1de/etc/kubernetes/pki/etcd/peer.key\""
time="2023-01-09T09:26:16Z" level=info msg="1 valid certificate(s) found in \"/mnt/watch/dir-891a355f5967c209def0469b890e5f2f129fc1de/etc/kubernetes/pki/etcd/server.crt\""
time="2023-01-09T09:26:16Z" level=warning msg="no certificate(s) found in \"/mnt/watch/dir-891a355f5967c209def0469b890e5f2f129fc1de/etc/kubernetes/pki/etcd/server.key\""

High memory usage with watch-kube-secrets enable

We're running certificate-exporter on 4 environments. The memory usage on all other envs are below 50m. For some reason in our dev environment the memory spikes to about 500m when it reads the secrets. I have increased the default max-cache-duration to 20 mins and see the spike now every 20 mins.

In each env we are reading in the same number of certificates

The container image is:
docker.io/enix/x509-certificate-exporter:3.3.0

Args are:

    Args:
      --watch-kube-secrets
      --secret-type=kubernetes.io/tls:tls.crt
      --max-cache-duration=300s
      --listen-address=:9793

Log with cert paths redacted

time="2023-01-05T19:57:30Z" level=info msg="fetching configuration from within the cluster"
time="2023-01-05T19:57:30Z" level=info msg="loaded configuration, API server is at https://10.27.128.1:443"
time="2023-01-05T19:57:30Z" level=info msg="fetching API server version"
time="2023-01-05T19:57:30Z" level=info msg="kubernetes server version is v1.22.15-gke.100"
time="2023-01-05T19:57:30Z" level=info msg="starting x509-certificate-exporter version 3.3.0"
time="2023-01-05T19:57:51Z" level=info msg="3 valid certificate(s) found in \"k8s/*****\""
time="2023-01-05T19:57:51Z" level=info msg="3 valid certificate(s) found in \"k8s/*****\""
time="2023-01-05T19:57:51Z" level=info msg="3 valid certificate(s) found in \"k8s/*****\""
time="2023-01-05T19:57:51Z" level=info msg="3 valid certificate(s) found in \"k8s/*****\""
time="2023-01-05T19:57:51Z" level=info msg="3 valid certificate(s) found in \"k8s/*****\""
time="2023-01-05T19:57:51Z" level=info msg="parsed 15 certificates (0 read failures)"
time="2023-01-05T19:57:51Z" level=info msg="listening on :9793"

High mem in dev
Screenshot 2023-01-05 at 3 55 57 PM

What it typical memory usage looks like in other environments.
Screenshot 2023-01-05 at 3 53 20 PM

Do you know what would be causing the higher memory usage?

linux/arm64 release asset seems to be a x86_64 binary

root@ip-10-132-3-196:~# wget https://github.com/enix/x509-certificate-exporter/releases/download/v2.13.0/x509-certificate-exporter-linux-arm64
...

2022-06-09 15:20:51 (21.8 MB/s) - ‘x509-certificate-exporter-linux-arm64’ saved [44554149/44554149]

root@ip-10-132-3-196:~# chmod +x ./x509-certificate-exporter-linux-arm64
root@ip-10-132-3-196:~# ./x509-certificate-exporter-linux-arm64
-bash: ./x509-certificate-exporter-linux-arm64: cannot execute binary file: Exec format error
root@ip-10-132-3-196:~# file ./x509-certificate-exporter-linux-arm64
./x509-certificate-exporter-linux-arm64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=ypwPOrJyKwzl1NM4pEt9/XSgpcUuAVMBFOjO3In5P/M2LLiMFtcpYuwe2QTVLv/wUbU8K4TzdNpjw1blNHT, not stripped

This exporter does not reload the x509_not_after{} when the mounted certificate has been changed

This exporter does not reload the x509_not_after{} when the mounted certificate has been changed

As you know, the certificate for kubelet ,in the k8s cluster, would be rotated by kubelet automatically.
So kubelet.conf consists of /var/lib/kubelet/pki/kubelet-client-current.pem which is symbolic link of /var/lib/kubelet/pki/kubelet-client-YYYY-MM-DD-hh-mm-ss.pem file.

I did mount the /var/lib/kubelet/pki/kubelet-client-current.pem on the exporter as hostpath, but the exporter doesn't change the x509_after{} metric when the pem file has been changed.
image
image

https://github.com/kubeflow/kubeflow/pull/6581/files
Please check above link...
I love this x509-certificate-exporter and I hope this issue would be fixed.
Thanks

Have a regex search for certificate files

While using the x509-cert-exporter, we realized that if the exporter is not able to read files it will report read_errors which is expected.

I see that there are 2 arg options right now available, either point to the exact file or directory. It will be great if we have an option to provide regex to search certificate files in a directory and read only them rather than reading other files ( say for example we have .key files in the same directory ) and reporting read errors

Global podAnnotations variable has no effect in daemonset configuration

Currently setting global podAnnotations in values.yaml file has no effect in daemonset as daemonset.yaml template seems to be taking defaults from .daemonSets

{{- with .Values.hostPathsExporter.daemonSets }}
{{- range $dsName, $dsDef := . }}

Shouldn't globally defined(-able) values be pointed to ".Values" context instead?

Default values of resources - proposal

Hello,
first of all, thank you for this exporter :).

What do you think about the default resources value being unset e.g.
resources: {} ?

With recommended values maybe commented out below.

Reason for that is.... if I for example don't want to set CPU limits

  resources:
    limits:
      memory: 150Mi
    requests:
      cpu: 20m
      memory: 20Mi

It gets overriden with default values from this chart and my CPU limits are set, even if I don't want them to.

I wanted to make it work like below, but at least on v. 1.25.5 of kubernetes, this won't pass the k8s validator.

  resources:
    limits:
      cpu: "0"
      memory: 150Mi
    requests:
      cpu: 20m
      memory: 20Mi

So I delete the cpu limit via kustomize, which would not be needed if resources are unset.

metrics was collected before with the same name and label values

I have installed x509-certificate-exporter for prometheus metrics on my k8s cluster. When I curl the x509 metrics endpoint via a port forwarding port I am getting a 500 Internal Server Error which looks to be due to the collected metric was collected before with the same name and label values issue.

The redacted logs from the metrics endpoint

6 error(s) occurred:
* collected metric "x509_cert_expired" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-1" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:0 > } was collected before with the same name and label values
* collected metric "x509_cert_not_before" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-1" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:1.637326877e+09 > } was collected before with the same name and label values
* collected metric "x509_cert_not_after" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-1" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:1.645102876e+09 > } was collected before with the same name and label values
* collected metric "x509_cert_expired" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-2" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:0 > } was collected before with the same name and label values
* collected metric "x509_cert_not_before" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-2" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:1.637326877e+09 > } was collected before with the same name and label values
* collected metric "x509_cert_not_after" { label:<name:"issuer_C" value:"US" > label:<name:"issuer_CN" value:"R3" > label:<name:"issuer_O" value:"Let's Encrypt" > label:<name:"secret_key" value:"tls.crt" > label:<name:"secret_name" value:"REDACTED" > label:<name:"secret_namespace" value:"NAMESPACE-2" > label:<name:"serial_number" value:"397903463022087250624511385398675455954861" > label:<name:"subject_CN" value:"*.REDACTED" > gauge:<value:1.645102876e+09 > } was collected before with the same name and label values

and the pod logs

time="2021-11-24T11:52:30Z" level=info msg="fetching configuration from within the cluster"
time="2021-11-24T11:52:30Z" level=info msg="loaded configuration, API server is at https://10.96.0.1:443"
time="2021-11-24T11:52:30Z" level=info msg="fetching API server version"
time="2021-11-24T11:52:30Z" level=info msg="kubernetes server version is v1.20.6"
time="2021-11-24T11:52:30Z" level=info msg="starting x509-certificate-exporter version 2-12-0"
time="2021-11-24T11:52:31Z" level=info msg="4 valid certificate(s) found in \"k8s/NAMESPACE-1/DOMAIN-A\""
time="2021-11-24T11:52:31Z" level=info msg="3 valid certificate(s) found in \"k8s/NAMESPACE-1/DOMAIN-B\""
time="2021-11-24T11:52:31Z" level=info msg="1 valid certificate(s) found in \"k8s/NAMESPACE-1/web-server-ca\""
time="2021-11-24T11:52:31Z" level=info msg="1 valid certificate(s) found in \"k8s/NAMESPACE-1/web-server-tls\""
time="2021-11-24T11:52:31Z" level=info msg="4 valid certificate(s) found in \"k8s/NAMESPACE-2/DOMAIN-A\""
time="2021-11-24T11:52:31Z" level=info msg="3 valid certificate(s) found in \"k8s/NAMESPACE-2/DOMAIN-B\""
time="2021-11-24T11:52:31Z" level=info msg="parsed 16 certificates (0 read failures)"
time="2021-11-24T11:52:31Z" level=info msg="listening on :9793"

NOTE - On the platform the secrets for domain - A and domain - B are copied from namespace 2 to namespace 1 using a kubernetes Cluster Operator Daemon called kubed which synch secrets across namespaces

Feature: Certificate to Application Mapping Information in the metrics

Hi

We explored multiple tools to monitor the certificates on k8s. But one feature which is missing everywhere is the certificate to application mapping.

Say a given certificate is expired or going to expire, it will be great if we know which application will be affected by it.

I can create a PR for this if the maintainers feel it is a good feature to have

Feature request: Identifiable secret labels on x509_read_errors metric

Hello!

Similar to the other 3 metrics, would be possible to get more identifiable secret labels on the x509_read_errors metric?

For example, the exporter logs read

read error 1: failed to parse "k8s/kube-test/first-tls", tried to parse
malformed x509 data, x509: SAN dNSName is malformed

but the x509_read_errors metric does not give indication of which secret or certificate has failed to have been read

x509_read_errors{container="x509-certificate-exporter", endpoint="metrics",
instance="xx.xxx.x.xx:xxxx", job="x509-certificate-exporter-headless",
namespace="monitoring", pod="x509-certificate-exporter-7d4878bd67-sv9qw",
service="x509-certificate-exporter-headless"}

Maybe something like secret_name, secret_namespace, etc. to identify the problem without having to look at the logs?

Thanks for the work on this great project :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.