Allow passing client_cert and client_key through relation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Prometheus2 charm |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
In order for prometheus to scrape LXD metrics endpoint, TLS client authentication is required as shown on https:/
While the prometheus2 charm recently grew support for a tls-client relation to have a certificate issued by vault's CA, there are some problems with this approach:
LXD doesn't do regular TLS validation by following a certification chain to a CA, it instead checks if the leaf certificate is part of a trusted list. This means that if prometheus2 were to obtain its cert/key from vault, it'd need a way to get the certificate to LXD to be trusted.
Also, going with vault would require to deal with cert renewal and CRL while LXD uses TLS certs more like SSH public keys that are long lived.
Lastly, if LXD were to support the TLS "CA style" validation instead of the trusted leaf, it'd still have a problem because when Juju deploys vault, it doesn't create a sub-CA per service. As such, everything that relates to vault would as a side effect be able to talk to LXD because the same CA would be used.
For those reasons, we believe the solution would be to have the client_cert and client_key data provided by LXD to prometheus2 through the prometheus-manual relation.
Related branches
- 🤖 prod-jenkaas-bootstack (community): Needs Fixing (continuous-integration)
- James Troup (community): Approve
- Alvaro Uria (community): Needs Information
- BootStack Reviewers: Pending requested
-
Diff: 189 lines (+121/-5)2 files modifiedsrc/reactive/prometheus.py (+45/-1)
src/tests/unit/test_reactive_prometheus.py (+76/-4)
Changed in charm-prometheus2: | |
status: | New → Fix Released |