Where do cephx keyrings get defined

[khrpcek]

Hey, i'm trying to replace my ceph-csi-rbd/cephfs deployments with the newer ceph-csi-operator. I've been going through the docs and source but I don't see how the cephx keyring is supplied for a CephConnection, Driver, or ClientProfle object. Does anyone know what I'm missing here?

[Madhu-1]

@khrpcek you will create the secrets(that contains the cephx user and the key) and specify the secrets in the storageclass. csi driver will read it from the storageclass when creating the pvc or mounting the PVC to app pod. ceph-csi-operator doesnt deal with secrets or the storageclass thats why you dont see any document for the same.

[Madhu-1]

You will see examples here https://github.com/ceph/ceph-csi/tree/devel/examples

[khrpcek-ucar]

Gotcha, it's still the same as before. Thanks!

[SQUADRON-LEADER]

Hey! @khrpcek The ceph-csi-operator handles the CephX credentials a bit differently compared to the older standalone ceph-csi-rbd/cephfs deployments.

The keyring itself is usually not embedded directly in the CephConnection, Driver, or ClientProfile CRs. Instead, the operator expects the CephX user credentials to come from a Kubernetes Secret, which is then referenced internally by the operator-managed CSI components.

Typically the flow is:

• CephConnection → defines monitor endpoints / cluster connectivity
• ClientProfile → defines the CephX client identity and capabilities
• Kubernetes Secret → stores the actual key for that CephX user

The operator then mounts/injects those secrets into the generated CSI provisioner/nodeplugin deployments automatically.

If you look in the examples, the missing piece is often that the secret needs to exist beforehand with something like:

apiVersion: v1
kind: Secret
metadata:
  name: ceph-client-secret
type: Opaque
stringData:
  userID: csi-rbd-provisioner
  userKey: <cephx-secret>

Then the ClientProfile references that secret (depending on the operator version/API).

The docs are still a bit sparse around this because the operator abstracts a lot of the old Helm values/config away. Looking at the controller code under the reconciler logic is usually clearer than the CRD docs right now.