Using Environment Variables for Secrets

Environment-Variables.md

@@ -41,6 +41,46 @@ For S3 API server authentication, see the dedicated **[S3 Credentials](S3-Creden
 - AWS standard environment variables (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`)
 - Complete authentication examples and troubleshooting
 
+# Security Configuration (security.toml)
+
+The same `WEED_` prefix convention works for `security.toml`, allowing you to keep secrets out of config files entirely. This is the recommended approach for systems where configuration is stored in version control (e.g., NixOS, GitOps workflows).
+
+### JWT Signing Keys
+```shell
+# Volume server JWT keys
+WEED_JWT_SIGNING_KEY=your-secret-key
+WEED_JWT_SIGNING_READ_KEY=your-read-secret-key
+WEED_JWT_SIGNING_EXPIRES_AFTER_SECONDS=10
+
+# Filer JWT keys
+WEED_JWT_FILER_SIGNING_KEY=your-filer-secret-key
+WEED_JWT_FILER_SIGNING_READ_KEY=your-filer-read-secret-key
+WEED_JWT_FILER_SIGNING_EXPIRES_AFTER_SECONDS=10
+```
+
+### gRPC mTLS
+```shell
+WEED_GRPC_CA=/path/to/ca.crt
+WEED_GRPC_VOLUME_CERT=/path/to/volume.crt
+WEED_GRPC_VOLUME_KEY=/path/to/volume.key
+WEED_GRPC_MASTER_CERT=/path/to/master.crt
+WEED_GRPC_MASTER_KEY=/path/to/master.key
+WEED_GRPC_FILER_CERT=/path/to/filer.crt
+WEED_GRPC_FILER_KEY=/path/to/filer.key
+WEED_GRPC_CLIENT_CERT=/path/to/client.crt
+WEED_GRPC_CLIENT_KEY=/path/to/client.key
+```
+
+### HTTPS
+```shell
+WEED_HTTPS_CLIENT_ENABLED=true
+WEED_HTTPS_CLIENT_CERT=/path/to/client.crt
+WEED_HTTPS_CLIENT_KEY=/path/to/client.key
+WEED_HTTPS_CLIENT_CA=/path/to/ca.crt
+```
+
+For full details, see [[Security Configuration]].
+
 # Docker
 You can set environment variables easily in Docker:
 ```shell

Security-Overview.md

@@ -79,7 +79,7 @@ Besides gRPC mentioned above, volume servers can only be changed by file upload,
 ## JWT-based access control
 To enable JWT-based access control,
 1. generate `security.toml` file by `weed scaffold -config=security`
-1. set `jwt.signing.key` to a secret string
+1. set `jwt.signing.key` to a secret string — or set the `WEED_JWT_SIGNING_KEY` environment variable to avoid storing the secret in the config file (see [[Security Configuration#Using Environment Variables for Secrets]])
 1. copy the same `security.toml` file to the masters and all volume servers.
 
 > **Re-enabling Volume UI**
@@ -112,7 +112,7 @@ The volume server can also check JWT for reads. This mode does not work with `we
 To enable JWT-based access control for the Filer,
 
 1. generate `security.toml` file by `weed scaffold -config=security`
-2. set `jwt.filer_signing.key` to a secret string - and optionally `jwt.filer_signing.read.key` as well to a secret string
+2. set `jwt.filer_signing.key` to a secret string (or use `WEED_JWT_FILER_SIGNING_KEY` env var) — and optionally `jwt.filer_signing.read.key` as well (or `WEED_JWT_FILER_SIGNING_READ_KEY`)
 3. copy the same `security.toml` file to the filers and all S3 proxies.
 
 If `jwt.filer_signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `jwt.filer_signing.key`.