From a0b21fd8f034133d42415b6ccdd90e058fbca7eb Mon Sep 17 00:00:00 2001 From: Elias Carter Date: Thu, 5 Jun 2025 23:01:05 +0000 Subject: [PATCH] doc: improve documentation around object store certificates The documentaiton around object store certificates does not specify how to deal with internally issued certs being used on the RGW. From my testing it is possible to get the rook operator to validate the RGW certs if the entire certificate chain is put into the `cert` field of the `sslCertificateRef` secret. Additionally, the docs are linking to a broken civetweb link but rook is now using the beast frontend, so I fixed that link to point towards the beast frontend documentation instead. There was also some confusion around the `caBundleRef` and how that is used so I made the docs more explicit that the `caBundleRef` is used by the RGW to connect to external services such as LGW and mulitsite RGW. Signed-off-by: Elias Carter (cherry picked from commit 0605067a7d24921189f7020f04871b5c1c440ac3) --- .../CRDs/Object-Storage/ceph-object-store-crd.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md b/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md index f04c71013..befda0a4c 100644 --- a/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md +++ b/Documentation/CRDs/Object-Storage/ceph-object-store-crd.md @@ -181,9 +181,12 @@ The gateway settings correspond to the RGW daemon settings. * `sslCertificateRef`: If specified, this is the name of the Kubernetes secret(`opaque` or `tls` type) that contains the TLS certificate to be used for secure connections to the object store. If it is an opaque Kubernetes Secret, Rook will look in the secret provided at the `cert` key name. The value of the `cert` key must be - in the format expected by the [RGW service](https://docs.ceph.com/docs/master/install/ceph-deploy/install-ceph-gateway/#using-ssl-with-civetweb): - "The server key, server certificate, and any other CA or intermediate certificates be supplied in - one file. Each of these items must be in PEM form." They are scenarios where the certificate DNS is set for a particular domain + in the format expected by the [RGW service](https://docs.ceph.com/en/reef/radosgw/frontends/#beast). + If the certificate in the `cert` key name is issued by an internal CA, the entire certificate chain can be appended + together starting with the leaf cert first, any intermediary certs, and finally the root cert. The beast frontend will only + use the first cert in the chain, but the rook operator will use the entire chain when connecting to the RGW for management. + + There are scenarios where the certificate DNS is set for a particular domain that does not include the local Kubernetes DNS, namely the object store DNS service endpoint. If adding the service DNS name to the certificate is not empty another key can be specified in the secret's data: `insecureSkipVerify: true` to skip the certificate verification. It is not @@ -191,7 +194,10 @@ The gateway settings correspond to the RGW daemon settings. custom verification is used. * `caBundleRef`: If specified, this is the name of the Kubernetes secret (type `opaque`) that contains additional custom ca-bundle to use. The secret must be in the same namespace as the Rook - cluster. Rook will look in the secret provided at the `cabundle` key name. + cluster. Rook will look in the secret provided at the `cabundle` key name. This bundle is used used by RGW to verify + external applications that RGW connects to. For example: LDAP servers, or a different RGW realm for multisite connections. + This bundle is **not** used by the rook operator when connecting to the RGW. See the notes on `sslCertificateRef` on + how to load the entire certificate chain into `cert` for use by the operator instead. * `hostNetwork`: Whether host networking is enabled for the rgw daemon. If not set, the network settings from the cluster CR will be applied. * `port`: The port on which the Object service will be reachable. If host networking is enabled, the RGW daemons will also listen on that port. If running on SDN, the RGW daemon listening port will be 8080 internally. * `securePort`: The secure port on which RGW pods will be listening. A TLS certificate must be