Compare commits
5 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 466514063a | |||
| ab21378f8f | |||
| fa7d7281f0 | |||
| c7dcf29858 | |||
| 41449d41c9 |
+31
-11
@@ -105,7 +105,35 @@ deployment sources from a Secret named **`cephrgw-credentials`** in its namespac
|
||||
> At least one of `CEPH_RGW_ENDPOINT` or `CEPH_RGW_ADMIN_ENDPOINT` must be set —
|
||||
> the API endpoint falls back to `CEPH_RGW_ENDPOINT` when the admin one is unset.
|
||||
|
||||
Create it directly:
|
||||
### Primary method: Vault + VSO
|
||||
|
||||
The Secret is not managed in GitOps; it is rendered from Vault by the Vault
|
||||
Secrets Operator (VSO). The argocd-apps `cephrgw-system` app ships a `VaultAuth`
|
||||
and a `VaultStaticSecret` that authenticate with the shared `default` Kubernetes
|
||||
auth role and render the KV path
|
||||
`kubernetes/namespace/cephrgw-system/default/cephrgw-credentials` into the
|
||||
`cephrgw-credentials` Secret. That path sits under the cluster's templated
|
||||
default policy (`kv/data/kubernetes/namespace/<ns>/<sa>/*`), so **no dedicated
|
||||
Vault role or policy is required** — you only seed the values:
|
||||
|
||||
```bash
|
||||
vault kv put kv/kubernetes/namespace/cephrgw-system/default/cephrgw-credentials \
|
||||
CEPH_RGW_ENDPOINT=https://s3.ceph.unkin.net \
|
||||
CEPH_RGW_ADMIN_ENDPOINT=https://radosgw.service.consul:443 \
|
||||
CEPH_RGW_ACCESS_KEY='REPLACE-WITH-ACCESS-KEY' \
|
||||
CEPH_RGW_SECRET_KEY='REPLACE-WITH-SECRET-KEY'
|
||||
```
|
||||
|
||||
The keys under that KV path are copied verbatim into the Secret, so they must be
|
||||
named exactly as the table above. VSO refreshes the Secret every few minutes,
|
||||
and the deployment's `reloader.stakater.com/auto: "true"` annotation restarts the
|
||||
operator when it changes — so rotating the credential is just a new `vault kv
|
||||
put`, no manual rollout.
|
||||
|
||||
### Fallback: a plain Secret
|
||||
|
||||
Outside this cluster (or for a quick `kind` test) you can create the Secret
|
||||
directly instead of using Vault:
|
||||
|
||||
```bash
|
||||
kubectl -n cephrgw-system create secret generic cephrgw-credentials \
|
||||
@@ -115,16 +143,8 @@ kubectl -n cephrgw-system create secret generic cephrgw-credentials \
|
||||
--from-literal=CEPH_RGW_SECRET_KEY='REPLACE-WITH-SECRET-KEY'
|
||||
```
|
||||
|
||||
The deployment carries the `reloader.stakater.com/auto: "true"` annotation, so
|
||||
rotating this Secret triggers an automatic operator restart — no manual rollout
|
||||
needed.
|
||||
|
||||
### Sourcing it from Vault (optional)
|
||||
|
||||
If you keep the keys in Vault, sync them with a `VaultStaticSecret` (VSO is
|
||||
already running in `vso-system`) that renders into `cephrgw-credentials` with the
|
||||
keys above, instead of the plain `kubectl create secret`. The operator does not
|
||||
care where the Secret comes from, only that those keys exist.
|
||||
The operator does not care where the Secret comes from, only that those keys
|
||||
exist.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user