Caddy logging sensitive storage configuration at startup

1. The problem I’m having:

I am working on a storage module for caddy (certmagic) using etcd as a backend, and I noticed that when starting caddy it will dump out the storage configuration to the log, looking something like this:

2023/12/22 15:12:40.218	INFO	tls	cleaning storage unit	{"storage": {"BasePrefix":"certmagic","Endpoints":["https://localhost:2379"],"RootCAFile":"/Users/patlu/etcd-test/tls/ca.pem","KeyFile":"/Users/patlu/etcd-test/tls/client-key.pem","CertFile":"/Users/patlu/etcd-test/tls/client.pem","InsecureSkipVerify":false,"DialTimeout":5000000000,"Username":"","Password":"","EncryptionPassword":"mysecret","Argon2Salt":"ZTFkYzMzNDlhZWVhMzA3ZWU5NmQ5YTA1MmQ1MzdhODc=","Argon2Time":3,"Argon2Memory":65536,"Argon2Threads":4}}

As you can tell the storage config contains potentially sensitive stuff like the EncryptionPassword or Username/Password settings. Logging this is probably not a good idea. To make sure this was not me accidentally logging this myself somewhere I also tried running another storage module and it looked similar. Am I missing how to properly configure sensitive values for modules? This seems to basically be a dump of the struct I use to implement the certmagic storage interface.

3. Caddy version:

./caddy version
v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

Built myself via xcaddy

a. System environment:

macOS 14 Sonoma

b. Command:

./caddy run


	storage etcd {
		endpoints {
		dial_timeout 5s
		base_prefix "certmagic"
		ca_file "/Users/patlu/etcd-test/tls/ca.pem"
		cert_file "/Users/patlu/etcd-test/tls/client.pem"
		key_file "/Users/patlu/etcd-test/tls/client-key.pem"
		tls_insecure false
		encryption_password "mysecret"
		argon2_salt "e1dc3349aeea307ee96d9a052d537a87"
		argon2_time 3
		argon2_memory 65536
		argon2_threads 4
} {
	tls {
		dns acmedns /Users/patlu/etcd-test/acme/credentials.json
	reverse_proxy {
		transport http {
			proxy_protocol v2

This is by design. Structs of storage module don’t necessarily always have passwords in them, e.g. filesystem, so we can’t skip logging them based on assumption. It’s helpful to log the configured storage module because it helps catching misconfiguration and/or knowing the exact storage location.

There are 2 resolutions that I’d recommend:


That makes sense, thank you for the information :).

I think for this specific case implementing fmt.Stringer is probably my preferred approach since logging secrets is almost always unwanted and can have annoying consequences (like having to rotate secrets) when done by mistake. So rather than expecting users to bundle the storage config with log filter config it is probably better to never output secrets at all.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.