5 Commits

Author SHA1 Message Date
unkinben 466514063a Talk to radosgw directly via go-ceph + aws-sdk-go-v2
ci/woodpecker/pr/build Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/test Pipeline was successful
The operator drove the Ceph manager dashboard REST API to manage RGW users,
buckets and policies. That coupled it to a dashboard login, the dashboard's RGW
wiring, and the dashboard's bucket API surface. Rebuild the Ceph integration to
talk directly to radosgw the way the CLI does, using native Go libraries, while
keeping every operator capability identical.

The exported surface of internal/ceph is unchanged, so the three controllers
and cmd/operator's structure are untouched (bar the CEPH_RGW_* config plumbing).

- replace the internal/ceph client internals with github.com/ceph/go-ceph
  rgw/admin (Admin Ops API) for users, keys, quotas and bucket info/removal
- add github.com/aws/aws-sdk-go-v2 S3 client for bucket create, versioning,
  policy, tagging and object lock, signed as the bucket owner
- map go-ceph admin.ErrNoSuch*/ErrUserExists and smithy APIError codes into
  IsNotFound/IsConflict so controller create-vs-update branching is preserved
- set S3 path-style addressing and WhenRequired checksum modes for RGW
- delete the hand-rolled dashboard client, token auth and JSON plumbing
- keep policy.go/BuildBucketPolicy/BuildTagJSON as pure builders
- replace the client tests with NewClient validation and error-classifier tests
- keep CGO_ENABLED=0 distroless: only go-ceph's pure-Go rgw/admin is imported
- switch env/config to CEPH_RGW_* (endpoint, admin endpoint, access/secret key,
  region, CA, insecure) and update the deployment manifest
- rewrite README and docs/ceph-setup.md for the single RGW admin user
  (caps users=*;buckets=*), keeping Vault/VSO as the primary credential source

Claude-Session: https://claude.ai/code/session_016CEncETbf8cvy1PhsHfFHM
2026-07-24 22:36:10 +10:00
benvin ab21378f8f Merge pull request 'docs: make Vault/VSO the primary credential method' (#2) from benvin/docs-vault-primary into main
Reviewed-on: #2
2026-07-18 17:00:35 +10:00
benvin fa7d7281f0 docs: make Vault/VSO the primary credential method
ci/woodpecker/pr/build Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/test Pipeline was successful
Document sourcing cephrgw-credentials from Vault via VSO as the primary path,
using the shared default k8s auth role and the templated KV path
kubernetes/namespace/cephrgw-system/default/cephrgw-credentials (no dedicated
Vault role/policy needed). Keep the plain-Secret method as a fallback for
non-cluster/kind use.
2026-07-18 16:27:52 +10:00
benvin c7dcf29858 Merge pull request 'Initial cephrgw-operator implementation' (#1) from benvin/initial-operator into main
ci/woodpecker/tag/docker Pipeline was successful
Reviewed-on: #1
2026-07-18 11:26:35 +10:00
unkinben 41449d41c9 Merge auto-initialized repo
ci/woodpecker/pr/build Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
ci/woodpecker/pr/test Pipeline was successful
2026-07-18 08:31:00 +10:00
+31 -11
View File
@@ -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.
---