# Rook-Ceph (/docs/runtime/components/rook-ceph)



> **Note**
> The STS-based S3 access path (`rgw s3 auth use sts`) is staged but not yet active — current S3 access uses static RGW credentials. This path will be enabled once the federated flow is validated.

Component Category [#component-category]

Data and storage / object and file storage

Component Description [#component-description]

`Rook-Ceph` is the Rook operator running a Ceph cluster on Kubernetes. It provides `CephFS` for shared file storage and a RADOS Gateway (RGW) endpoint for S3-compatible object storage. It is the platform's primary object storage layer.

Why It Is Used [#why-it-is-used]

In BullSequana AI Runtime, Rook-Ceph provides a Kubernetes-native, scalable, and operator-managed storage layer for S3-compatible workloads and shared file storage through `CephFS`. It integrates with the existing identity, ingress, and certificate-management components.

Learn More [#learn-more]

* [Rook documentation](https://rook.io/docs/rook/latest/)
* [rook/rook on GitHub](https://github.com/rook/rook)
* [Ceph documentation](https://docs.ceph.com/)

S3 Access Model [#s3-access-model]

Two S3 access paths are configured on the RGW:

* **Static access keys** — the active path. A bootstrap job creates a dedicated RGW user and writes its access key and secret to the `rook-ceph-rgw-bootstrap` secret in the `rook-ceph` namespace. Workloads and operators consume those credentials directly.
* **STS / Keycloak-federated access** — staged but inactive (`sts=false`). The path is wired so it can be enabled once the federated flow is validated.

For the validation procedure used to confirm static-key access end to end, see [Rook-Ceph RGW S3 access](/docs/deployment/playbooks/rook-ceph-rgw-s3-access).

Dashboard access [#dashboard-access]

The Ceph dashboard is exposed through Gateway API and protected by an `oauth2-proxy` instance that delegates authentication to Keycloak. A dedicated Keycloak client is created during deployment.

Operational Notes [#operational-notes]

* An orphan-cleaner cronjob runs in the `rook-ceph` namespace and removes pods that remain bound to non-existent nodes, which would otherwise block component startup after node turnover.
* CephFS is exposed through one or more Kubernetes `StorageClass` resources for dynamic `PersistentVolumeClaim` provisioning.
* TLS for RGW and dashboard endpoints is issued by cert-manager.

Deployment notes [#deployment-notes]

Rook-Ceph deploys as two components in the common tier: the operator at sync wave 5 and the cluster at sync wave 8, both in the `rook-ceph` namespace. The cluster runs three MON daemons, one MGR, and one OSD device set with a count of 3, spread across hosts. The object store uses three-way replication for both metadata and data pools. OSD nodes use the `workload=storage` node affinity label.

Interacts With [#interacts-with]

* `cert-manager`, which issues and renews TLS certificates for RGW and dashboard endpoints.
* `Gateway API` and `External DNS`, which expose the RGW S3 endpoint and the Ceph dashboard.
* `Keycloak`, which authenticates dashboard access through `oauth2-proxy` and is the planned identity provider for the future STS-based S3 access path.
* `Reflector`, which is used to propagate selected secrets across namespaces during deployment.