Ceph Dashboard SSO with Keycloak: what the integration does
Keycloak can sign administrators into the Ceph Dashboard through either SAML 2.0 or OAuth2, but it only settles who is at the door. Authorization stays inside the dashboard, so every administrator still needs an account there and a role assigned by someone who understands the cluster. The SAML 2.0 path uses the documented ceph dashboard sso setup saml2 command, which registers your identity provider metadata and attribute mapping with the Manager. The OAuth2 path depends on cephadm running the Management Gateway with authentication enabled, plus an OAuth2 Proxy service in front of the dashboard. Which path fits depends on how your cluster is deployed, so confirm that before any design work starts.
The decision is less about features than about what your cluster already runs. If the cluster is managed by cephadm and you are willing to deploy the Management Gateway and OAuth2 Proxy, the OAuth2 route puts an authenticating proxy in front of the dashboard and lets Keycloak handle sessions and group claims. If you cannot run those services, or you prefer fewer moving parts on the Manager, the SAML 2.0 route avoids the proxy layer. Ask your team to confirm the cephadm version and whether the Management Gateway is already in use. Keycloak is the recommended and tested identity provider for the OAuth2 path, which makes it the natural default if you are starting from nothing.
The operational consequence matters as much as the setup. In the OAuth2 path, cephadm disables SSO if oauth2-proxy stops, so administrators would lose dashboard sign-in during a proxy outage. Plan who can restart that service, how it is monitored, and whether break-glass local accounts exist for recovery. Before go-live, list the dashboard roles each group will receive and test that a user without a role cannot change cluster state. The Ceph Dashboard documentation is the authoritative source for the exact commands and supported versions in your release.
What you need before enabling Keycloak sign-in
Keycloak sign-in for the Ceph Dashboard depends on four layers working together: a supported Ceph release managed by cephadm, a Keycloak instance with a realm and client, name resolution and TLS across the dashboard and identity endpoints, and, for the OAuth2 path, the Management Gateway and OAuth2 Proxy services. Check each layer before you change dashboard settings, because a gap in one breaks sign-in for every user.
Supported Ceph release with cephadm
The dashboard SSO steps assume a cluster managed by cephadm, which was introduced in v15.2.0 (Octopus) and does not support older releases. Confirm the cluster runs an actively maintained release, currently Tentacle (20.2.x) or Squid (19.2.x), and plan any upgrade before you start the SSO work. Check the cluster's orchestrator status first, because the OAuth2 path depends on services that cephadm deploys.
Keycloak instance, realm and client
You need a running Keycloak server with a dedicated realm for Ceph users and a client registered for the dashboard or the OAuth2 Proxy, depending on the path you choose. Confirm the Keycloak version and production database support against current vendor documentation before you deploy, since release cadence and supported databases change. Decide who administers the realm, because that person controls which users can reach the dashboard.
DNS names for dashboard and IdP
The browser must reach the dashboard and the identity provider by stable names, and the redirect URIs registered in Keycloak must match those names exactly. Plan the dashboard hostname, the Keycloak hostname and, for OAuth2, the Management Gateway hostname as separate records. Mismatched hostnames are a common reason sign-in fails after the SSO settings look correct.
TLS certificates trusted by every client
Browsers and the dashboard both need to trust the certificates presented by Keycloak and the gateway, including any internal certificate authority used in an air-gapped network. Confirm the certificate chain is complete and that its validity period covers your rollout window. Record which CA bundle the cluster hosts use, since certificate renewal can break SSO without any change to the dashboard itself.
Management Gateway with authentication enabled
The OAuth2 option requires an active Management Gateway deployed with authentication enabled. Confirm this service is running through cephadm and reachable from the users' network before you configure OAuth2 settings. Treat the gateway as part of the sign-in path, because the dashboard's authentication depends on it being available.
OAuth2 Proxy service and its session store
OAuth2 SSO also needs an OAuth2 Proxy service, and cephadm disables SSO if that service stops, so plan its availability and monitoring before go-live. Decide how sessions are stored: encrypted cookies need a cookie secret, while Redis adds a separate service to run. Confirm the proxy release you deploy against the oauth2-proxy project's current documentation.
SAML 2.0 or OAuth2: which path fits your cluster
The SAML 2.0 route connects the Ceph Dashboard directly to an external identity provider. You configure the dashboard with ceph dashboard sso setup saml2, supply the identity provider's metadata and attribute mappings, and the dashboard accepts assertions from that provider. Authentication moves to the identity provider, but authorization stays in the dashboard, so the local user accounts and their roles still have to exist before anyone can do useful work. The route does not depend on cephadm running a gateway or proxy service, which keeps the number of moving parts small.
- Fewer services: The dashboard talks to the identity provider itself, so there is no reverse proxy to patch, certify or fail over.
- Role assignment remains manual: Each dashboard user or mapped identity still needs a role such as administrator or read-only, and you own that list over time.
- Metadata lifecycle: Certificate rotation and metadata changes on the identity provider side must be reflected in the dashboard configuration, so plan an owner for that change.
- Clean failure mode: If the identity provider is unreachable, sign-in fails at the dashboard, and the dashboard's own accounts remain the fallback you must decide how to handle.
- Protocol fit: This route suits teams whose identity provider already speaks SAML 2.0 and whose security standards accept SAML assertions at the application.
Confirm with your identity team which SAML attributes they will release, how they handle certificate expiry, and who approves changes to the dashboard role mapping before you rely on this route.
The OAuth2 route places the dashboard behind the cephadm Management Gateway with authentication enabled, and uses an OAuth2 Proxy service to talk to the identity provider. Keycloak is the recommended and tested identity provider for this path. The gateway and proxy are deployed and managed by cephadm, so this route requires a cephadm-managed cluster and cannot be used on a cluster that is run another way. Users sign in at Keycloak, and the proxy passes identity details to the dashboard as HTTP headers.
- Cephadm dependency: The Management Gateway and OAuth2 Proxy services must be deployed and kept healthy through cephadm, so upgrades of the gateway become part of your Ceph upgrade plan.
- Proxy failure disables SSO: cephadm turns SSO off if oauth2-proxy stops, so proxy availability directly determines whether operators can sign in with single sign-on.
- Identity headers: OAuth2 Proxy forwards identity data such as
X-Forwarded-User,X-Forwarded-GroupsandX-Forwarded-Email, and can pass the access token or ID token, so the header contract must be tested end to end. - Session storage choice: Cookie sessions need a cookie secret and cannot be locked, which can force re-login when token refreshes collide. Redis-backed sessions add a service you must run and secure.
- Additional components: Keycloak, the gateway and the proxy each have their own release cycles, certificates and logs, so the operating surface grows.
Confirm the supported Management Gateway and OAuth2 Proxy versions for your Ceph release, and test what happens to operator sessions when the proxy is restarted during business hours.
The two routes differ most in what your team must monitor and recover. The SAML 2.0 route leaves the dashboard as the single point where sign-in and authorization meet, while the OAuth2 route splits that work across the gateway, the proxy, the session store and the identity provider. Neither route removes the need to maintain dashboard accounts and roles, so the operating cost is the sum of the identity work plus the services you add. Plan this view with the team that will be on call.
- Monitoring targets: The SAML route needs checks on the dashboard and the identity provider. The OAuth2 route also needs health checks on the gateway and oauth2-proxy, with alerts for the state where SSO is disabled.
- Recovery path: Decide in advance how an administrator regains access if the identity provider or proxy is down, and where the break-glass account is stored.
- Change control: Gateway and proxy changes follow cephadm procedures, while Keycloak changes follow its own upgrade and operator guidance, so the two change windows must be coordinated.
- Logging: Authentication events are split across services on the OAuth2 route, so log retention and correlation need explicit design.
- Staffing: Ask whether your platform team already runs Keycloak and cephadm. Familiar tooling reduces both risk and effort.
Write down who owns each service, the escalation path for a failed sign-in, and the expected recovery steps before choosing a route.
There is no universally better path. The SAML 2.0 route fits clusters that want the dashboard to own its sign-in integration with minimal extra services, provided the identity provider speaks SAML 2.0 and the team accepts manual role maintenance inside the dashboard. The OAuth2 route fits clusters that already run cephadm-managed gateway services, use Keycloak as the central identity provider and want header-based identity handled consistently with other applications. Your Ceph release, deployment method and identity standards narrow the choice before any preference applies.
- Deployment method: The OAuth2 route requires cephadm. If your cluster is managed another way, the SAML 2.0 route is the path to evaluate first.
- Identity standards: Match the route to the protocol your identity provider and security policy already support, rather than adding a new one for the dashboard alone.
- Operations capacity: Count the services your team can patch, monitor and recover within its existing rota.
- Session behavior: Test how long operators stay signed in and how re-login behaves on the OAuth2 route with cookie sessions.
- Role model: Both routes keep dashboard roles, so design the role map first and then choose the transport.
Before you commit, run both routes in a test cluster with your real identity provider and confirm the release notes and support statements for your Ceph version.
Whichever route you choose, verification should prove more than a successful login. The test must show that identity reaches the dashboard correctly, that roles are applied as designed, and that the failure modes behave as your operations team expects. For the OAuth2 route, the failure test is especially important, because stopping the proxy is the event that turns SSO off. For the SAML 2.0 route, test certificate and metadata changes before they happen in production.
- Login path test: Sign in with each identity group that should reach the dashboard and confirm the role each one receives.
- Header check: On the OAuth2 route, confirm the user, group and email headers that arrive at the dashboard match your mapping.
- Failure drill: Stop oauth2-proxy in a test cluster and document how operators sign in and how quickly SSO returns.
- Metadata rotation drill: On the SAML route, rehearse replacing the identity provider signing certificate and updating the dashboard configuration.
- Access review: Schedule a periodic review of dashboard accounts, because authorization does not come from the identity provider on either route.
Record the test results and the named owner for each step, so the choice can be reviewed when Ceph or Keycloak changes.
How to configure Keycloak sign-in step by step
This sequence takes the dashboard from local accounts to Keycloak sign-in, whether you choose SAML 2.0 or the OAuth2 path through the cephadm Management Gateway. Each step ends with a check you can run before moving on.
Confirm the cephadm and dashboard baseline
Before changing authentication, confirm the cluster is managed by cephadm and the Ceph Dashboard is reachable over HTTPS with a local administrator account. Check that the cluster reports a healthy state and that the dashboard login works with that account. Keep this account as a break-glass administrator until SSO has been tested end to end. Your Ceph release must be one cephadm supports, and you should confirm the exact release and dashboard behavior against the Ceph Dashboard documentation for that version.
Choose SAML 2.0 or OAuth2 for the dashboard
Decide which path fits your environment. SAML 2.0 signs in through an external identity provider but keeps dashboard authorization inside Ceph, so it needs no Management Gateway. The OAuth2 path needs cephadm with an active Management Gateway deployed with authentication enabled, plus an OAuth2 Proxy service, and Keycloak is the recommended and tested identity provider for it. Record the choice in your change record, because the Keycloak client settings differ between the two paths.
Create the Keycloak realm and client
In the Keycloak admin console, create a dedicated realm for Ceph users or reuse an existing realm your organization already governs. Then create a client for the dashboard. For SAML 2.0, the client carries the dashboard's entity and assertion consumer settings. For OAuth2, the client is an OpenID Connect client configured for the OAuth2 Proxy callback. Confirm the client appears in the admin console and that a test user in the realm can authenticate against it. Keycloak's own administration guide covers realm and client creation for your version.
Configure the SAML 2.0 or OIDC settings
For SAML 2.0, export the Keycloak identity provider metadata and keep it available for the dashboard command. Map the attribute or name identifier that the dashboard will use as the username. For OAuth2, register the client secret and redirect URI in Keycloak and store the secret where cephadm can reference it securely. Verify the metadata or discovery document loads from the Keycloak endpoint, and confirm the username and group claims you intend to use appear in a test token or assertion.
Enable SSO in the dashboard
For SAML 2.0, run the documented command ceph dashboard sso setup saml2 and supply the identity provider metadata and settings it asks for. Then check the result with the SSO status view in the dashboard or the documented status command for your release. For OAuth2, enable SSO only after the Management Gateway and OAuth2 Proxy are running, because cephadm disables SSO if oauth2-proxy stops. In both cases, confirm the login page now offers the Keycloak sign-in option.
Deploy the Management Gateway and OAuth2 Proxy with cephadm
This step applies only to the OAuth2 path. Use cephadm to deploy the Management Gateway with authentication enabled, then deploy the OAuth2 Proxy service and point it at your Keycloak client. Check the orchestrator service list to confirm both services report as running, and confirm the OAuth2 Proxy logs show a successful connection to Keycloak. Exact deployment flags and specification fields should be taken from the cephadm and Dashboard documentation for your release, not from memory.
Assign dashboard roles to authenticated users
Keycloak authenticates the user, but the dashboard still decides what that user may do. Create a dashboard user account for each person or group that needs access, or map the identity to the roles your team uses, and assign the minimum dashboard role needed. Test with at least one account per role, confirming that a read-only user cannot change cluster settings. Record which Keycloak group corresponds to which dashboard role so audits can trace access.
Verify sign-in, failure behavior and recovery
Run a test login through Keycloak with a standard user and confirm the dashboard shows the expected username and role. Sign out and confirm the session ends as expected. For the OAuth2 path, stop the OAuth2 Proxy service in a test window and confirm SSO is disabled as documented, then restore it. Confirm the local break-glass account still works. Keep the results and configuration in your runbook, since Keycloak and OAuth2 Proxy release on their own schedules and each upgrade needs this test repeated.
Which dashboard roles you still assign after SSO
Single sign-on settles who the user is, not what they may do in the dashboard. With SAML 2.0 set up through ceph dashboard sso setup saml2, Keycloak authenticates the user and the dashboard then applies its own accounts and roles. Every operator who signs in still needs a dashboard user with a role such as administrator, read-only or a more limited role, created with the ceph dashboard user commands before the first login. Confirm that each Keycloak user who should reach the dashboard has a matching dashboard account, and decide who may create, change and remove those accounts. A user who authenticates successfully without a dashboard account should not expect any access, and that default should be part of your test plan.
The OAuth2 path works the same way at the authorization level. OAuth2 Proxy forwards identity to the dashboard as headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email. Those headers identify the caller and carry group membership, but they do not grant dashboard roles on their own unless you configure the mapping yourself. Check the current Ceph Dashboard documentation for how forwarded groups, if at all, translate into dashboard roles in your Ceph release before you rely on any group-based grant. Until that mapping is confirmed and tested, treat role assignment as manual and document each account in the same way as under SAML 2.0.
Review the group-to-role mapping as a access control, with a named owner. List every Keycloak group that is allowed to reach the dashboard, the dashboard role each one should receive, and who approves changes to either side. Keycloak administrators control group membership, while Ceph administrators control dashboard roles, so a change in one system can silently alter access in the other. Schedule a periodic review that compares active dashboard accounts with current Keycloak group membership and removes accounts for departed staff. Ask your implementation partner to show where each mapping is held, who can edit it, and how an edit is logged and reviewed.
How Keycloak identity fields map to dashboard accounts
This table traces one identity from a Keycloak user record through oauth2-proxy headers to the Ceph Dashboard account and roles. Read each row as a handoff: the set-in column says where the value is configured, and the claim names must be confirmed in your own realm before you rely on them. The main takeaway is that Keycloak supplies identity, but the dashboard still decides what each account can do.
| Identity field | Where it is set | Ceph Dashboard result |
|---|---|---|
| Username | Keycloak: user name or preferred_username claim in the client's token mappers | oauth2-proxy forwards it as X-Forwarded-User; the dashboard account name must match this value exactly |
| Keycloak: email claim, released to the client through a client scope | oauth2-proxy forwards it as X-Forwarded-Email; the dashboard account email should be kept in step with it | |
| Groups | Keycloak: a group membership mapper that adds a groups claim to the ID or access token | oauth2-proxy forwards it as X-Forwarded-Groups; group names are passed through but do not grant dashboard roles on their own |
| Dashboard roles | Dashboard: roles such as administrator or read-only assigned to each account | Authorization stays in the dashboard, so an account must exist and hold a role before a signed-in user can do anything |
| Account creation | Dashboard: user accounts created in advance or through automation you build | A user who signs in through Keycloak but has no dashboard account receives no useful access |
| Group to role mapping | Neither system maps it by default: you define it in your provisioning process or runbook | Confirm whether your Ceph release supports mapping groups to roles for your setup before you plan around it |
| Token passed upstream | oauth2-proxy: choice of access token or ID token forwarded to the upstream | Confirm which token the dashboard path expects in your deployment, and test with a non-admin account |
| Header trust boundary | cephadm and the Management Gateway: only the proxy path should reach the dashboard | If users can reach the dashboard without passing oauth2-proxy, forged identity headers are a risk; verify this in testing |
Security settings that matter for this integration
Single sign-on moves the trust boundary to Keycloak and oauth2-proxy, so the dashboard is only as safe as the paths into it. The cards below cover transport encryption, session handling, client registration, dashboard authorization and patch tracking, in the order a team usually configures them.
TLS on every endpoint
Keycloak, the Ceph Dashboard, the Management Gateway and oauth2-proxy each expose an HTTPS endpoint that browsers and services use during sign-in. Use certificates issued by a CA your clients trust and confirm that the SAML metadata and OIDC discovery URLs resolve to the correct hosts. Check that no step in the redirect chain falls back to plain HTTP, since a downgraded login flow exposes tokens and session cookies.
Cookie secret or Redis sessions
oauth2-proxy keeps sessions either in encrypted client-side cookies, which need a cookie secret, or in Redis, where only a ticket sits in the cookie. Generate the cookie secret from a strong random source, store it in your secrets manager, and rotate it through a planned change. Choose Redis if you run more than one proxy instance or need central session control, and confirm that the Redis deployment is itself encrypted and authenticated.
Token refresh with cookie sessions
Cookie sessions hold no server-side state, but they cannot be locked, so concurrent token refreshes from parallel browser tabs can conflict. The result is a forced re-login that users may read as an outage. Test the session lifetime and refresh behavior with several tabs open. If that behavior is unacceptable for operators who work in the dashboard all day, move to Redis-backed sessions.
Restricted Keycloak clients and redirect URIs
Create a dedicated Keycloak client for the dashboard or proxy, with the exact redirect URIs for your hostnames and no wildcards. Disable flows the integration does not use, such as direct access grants, and restrict who can create or change clients in the realm. Review the client list after each upgrade, because an extra client or a loose redirect URI can let another application receive a valid login for the dashboard.
Least-privilege dashboard roles
SSO authenticates the user, but dashboard roles still decide what that user can change in the cluster. Map Keycloak groups to the narrowest Ceph Dashboard roles that fit each job, and keep administrator roles for a small named group. Remove accounts for staff who change teams, and review role assignments on a set schedule. Confirm that group claims from Keycloak cannot be edited by ordinary users.
Patching Keycloak and OAuth2 Proxy
Keycloak and OAuth2 Proxy are open source, so you own the timing of their updates. Keycloak plans four minor releases a year, and the current release is 26.8.1. OAuth2 Proxy published v7.15.5 on October 1, 2026. Subscribe to both release feeds, record which versions run in production, and test each upgrade against your dashboard login before rollout. If you use the Keycloak Operator, keep manual approval mode so upgrades happen only when you choose.
How Keycloak and OAuth2 Proxy upgrades affect dashboard sign-in
Every component in the OAuth2 path can change under you: Keycloak, OAuth2 Proxy and the Ceph release running the Dashboard. Treat each as a separate upgrade with its own test, because an upgrade to one can break sign-in even when the others are untouched. Keycloak now plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release are opt-in. That lowers the risk of a surprise minor release, but the opt-in settings still need a review against your realm, client and mapper configuration before you adopt a new minor version. Check the Keycloak backwards compatibility notes for each target version and record which settings you changed.
Keycloak migrates its database schema automatically at startup by default. That is convenient in a lab but risky on a shared production database, because a failed migration can leave the identity service unavailable. For large deployments, the upgrading guide suggests manual migration, where your database team applies the SQL and reviews it first. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so set it, and plan each Keycloak change as a dated maintenance event. On the OAuth2 Proxy side, the oauth2-proxy release notes and configuration keys can change between versions, and cookie sessions cannot be locked, so a change in session handling or cookie settings can force users to sign in again. A Ceph upgrade can also interrupt sign-in when the Management Gateway or OAuth2 Proxy service is redeployed, and cephadm disables SSO if oauth2-proxy stops, so confirm the service is healthy after each step.
Test every combination in a non-production cluster before production. Use a Keycloak instance and realm copied from production, the same OAuth2 Proxy version you plan to run, and the target Ceph release, then run a sign-in test with a dashboard administrator and a read-only user. Confirm that group claims still map to dashboard roles, that the session survives a Keycloak restart, and that ceph dashboard sso status shows SSO enabled after the Ceph upgrade. Ask your vendor or your own team to confirm the oauth2-proxy and Keycloak versions that are documented as tested with your Ceph release. Keep a rollback path for each component and record the version pairs that passed, so the next upgrade starts from a known-good set.
Common SSO failures on Ceph Dashboard and how to fix them
This table lists the failures teams most often hit when wiring Keycloak into the Ceph Dashboard, with the likely cause and the check or fix for each. Work through the rows in order when a sign-in fails, since the identity provider, the proxy and the dashboard roles each fail in different ways.
| Failure | Likely cause | Check or fix |
|---|---|---|
| Redirect URI mismatch at Keycloak | The client in Keycloak lists a callback address that differs from the dashboard or gateway address, often by hostname, port or scheme. | Compare the valid redirect URIs on the Keycloak client with the exact address users open. Update the client, then retest a sign-in from a clean browser session. |
| Certificate trust errors | The Keycloak certificate, or the internal CA that issued it, is not trusted by the Ceph hosts, the Management Gateway or the browser. | Confirm the CA chain is installed where cephadm and the gateway connect to Keycloak. Check the certificate names match the hostnames in the configuration. |
| Users sign in but see no dashboard content | SAML 2.0 and OAuth2 handle authentication only. The dashboard still needs a local user with a role for each account. | Create the user in the dashboard and assign a role such as administrator or read-only. Test with a second account to confirm the mapping works. |
| oauth2-proxy stops and SSO is disabled | cephadm turns off OAuth2 SSO when the OAuth2 Proxy service stops, so logins fall back to the normal dashboard path or fail. | Check the service status in cephadm and the proxy logs after any host reboot or upgrade. Set up monitoring so a stopped proxy is noticed before users report it. |
| Repeated logins with cookie sessions | OAuth2 Proxy keeps sessions in encrypted cookies. Concurrent token refreshes cannot be locked, so they can conflict and force a new sign-in. | Review token lifetimes and the refresh behavior in Keycloak. If repeated prompts persist, evaluate Redis-backed session storage and confirm it fits your Redis design. |
| Header names do not match what the dashboard expects | OAuth2 Proxy forwards identity in headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, and the names or claims may differ from the ones the gateway reads. | Compare the headers the proxy sends with the header and claim settings in the gateway configuration. Confirm the claim used for the username matches the account name in the dashboard. |
| Group membership ignored | The groups claim is not included in the token or the proxy does not forward it, so users lose the access their group should grant. | Add a group mapper to the Keycloak client and confirm the group appears in the forwarded headers. Test a user from each group before rollout. |
| Logins fail after a Keycloak upgrade | Minor releases can change behavior, and the Keycloak Operator may upgrade automatically if approval mode is not set. | Set the Operator to manual approval, read the backwards compatibility notes for the target release and retest the client configuration on a staging realm first. |
Questions buyers ask before connecting Ceph Dashboard to Keycloak
What drives the cost of connecting Ceph Dashboard to Keycloak?
The largest driver is the number of decisions the work has to settle before any configuration starts: which protocol the dashboard will use, whether Keycloak already exists and how it is run, how many Ceph clusters and dashboard users are involved, and how roles map to groups. Cost also depends on whether Keycloak must be deployed from scratch, which adds a separate platform build with its own database, high availability and upgrade planning. A fixed-scope quote should list each of these as a line item, so you can see which parts you already have covered internally. DeployOpen does not publish prices; a quote follows from the written scope.
How long does a Ceph Dashboard Keycloak SSO project take?
Duration depends on the same inputs as cost: whether the identity provider exists, the state of its client and group setup, and how many clusters and dashboard roles need to be covered. A project that only wires an existing Keycloak realm to one dashboard is much shorter than one that also builds Keycloak, adds a Management Gateway and OAuth2 Proxy, and tests failure behavior. Ask for the timeline as part of the written scope, including the test window and any change-freeze dates on your side. No duration is given here because none has been supplied for this work.
What does our team need to provide before the work starts?
Expect to provide access and decisions rather than code. The main inputs are a named Keycloak administrator or realm owner, a test Ceph cluster or maintenance window, the list of users and the dashboard roles they need, and a decision on which protocol you want. For OAuth2, you also need cephadm operating the cluster, because the Management Gateway and OAuth2 Proxy services are deployed through it. Confirm whether your certificates, DNS names and network paths to the identity provider are ready, since these often delay the start more than the configuration itself.
Can our internal team set up Ceph Dashboard SSO with Keycloak alone?
A team that already runs cephadm and Keycloak, and that has someone comfortable with SAML or OIDC claims, can often do the configuration in-house. The risk sits in the parts that are easy to skip: role assignment remains inside the dashboard for SAML, OAuth2 SSO is disabled if oauth2-proxy stops, and sessions behave differently depending on how OAuth2 Proxy stores them. Check whether your team has tested a failure of the proxy and a user who changes group membership. If those skills or test environments are missing, a partner can cover them within a written scope.
How do SAML and OAuth2 differ in day-to-day operations?
SAML 2.0 sign-in is configured directly in the dashboard with the setup command, and the dashboard keeps authorization, so every user and role still has to be created there. OAuth2 needs cephadm with an active Management Gateway deployed with authentication enabled, plus an OAuth2 Proxy service in front of it, which adds components to monitor and upgrade. OAuth2 Proxy can forward user, group and email headers and keeps sessions in encrypted cookies or in Redis. Cookie sessions cannot be locked, so concurrent token refreshes can force users to sign in again. Ask the partner to show which option your team will operate after handover.
Which Keycloak upgrade and availability decisions affect the dashboard?
The dashboard depends on Keycloak staying available and on its client settings staying stable across upgrades. Keycloak applies database schema migrations at startup by default, but the upgrading guide suggests manual migration for large deployments, so confirm which approach your team will use. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates. Keycloak's high availability designs require a synchronously replicated database, which should be confirmed before go-live. Plan a test of sign-in after every Keycloak and Ceph upgrade, because a break in either system blocks dashboard access.
What should we ask for in a fixed-scope quote for this work?
Ask for a written scope that names the protocol, the Ceph clusters in scope, the Keycloak realm and client definitions, the group-to-role mapping, and whether Keycloak is in or out of scope. The quote should state what is one-time work, such as configuration and testing, and what recurs, such as Keycloak and Ceph updates and any retainer for support. Request the acceptance tests, including failed-login and proxy-outage cases, the handover material, and the named exclusions, such as certificate procurement or changes to other applications. Compare quotes against this list rather than against headline totals.
Does the identity provider need any extra hardening for the dashboard?
Yes, the dashboard inherits the security of the identity provider. Confirm that Keycloak is deployed with production settings rather than the development database, that administrative access to the Keycloak console is limited, and that TLS is in place between the browser, the proxy and Keycloak. Review which claims and groups Keycloak releases to the dashboard, because those become the basis for access decisions. Also confirm how the Ceph Dashboard account lockout and multi-factor policy will be enforced in Keycloak, since SAML sign-in does not carry those settings across automatically.
How DeployOpen scopes Ceph Dashboard SSO work
DeployOpen scopes Ceph Dashboard single sign-on as a fixed-scope engagement with deliverables and timelines agreed in writing before any work starts. The scope states which path is in use, SAML 2.0 through ceph dashboard sso setup saml2 or OAuth2 through the cephadm Management Gateway and OAuth2 Proxy, and which Keycloak realm, clients and dashboard roles are covered. Because the Dashboard keeps authorization in its own user and role model, the written scope must list every dashboard account and role mapping that will be created, not only the login flow. A quote follows from that written scope, so the more precisely the environment, identity sources and acceptance tests are described up front, the more directly the quote reflects the work.
Work is carried out inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks, and DeployOpen does not take custody of your identity provider or cluster. The deliverables typically cover configuration of the IdP client or SAML metadata, the Dashboard SSO settings, hardening of the Keycloak and Dashboard endpoints, and documentation a future operator can follow. For OAuth2, the scope should also name the oauth2-proxy session storage choice and the procedure for the case where the proxy stops and SSO is disabled. Your team should confirm the Ceph release in use, the Keycloak version and its hosting model before signing, since these decide which steps apply.
Ongoing support, Keycloak and oauth2-proxy upgrades, and periodic checks of role assignments are available as retainers that run after the initial delivery. Ask the quote to separate the one-time build from any recurring retainer and to state how upgrade testing is handled, because minor and major Keycloak releases and oauth2-proxy releases can change behavior. DeployOpen does not hold vendor partner or certified provider status for Ceph or Keycloak, and the scope should be read as an implementation and operations agreement, not as a vendor endorsement.
How DeployOpen delivers Ceph SSO with Keycloak
DeployOpen plans, builds, tests and hands over Ceph Dashboard single sign-on with Keycloak inside your own infrastructure. The work starts with a written scope that settles which method fits your cluster, which roles your operators need, and how the identity provider will be kept available. Engagements are fixed-scope, with deliverables agreed in writing before work begins.
How we scope
- Confirm your Ceph release and whether cephadm already manages the cluster before choosing SAML 2.0 or OAuth2.
- Record which Keycloak instance, realm and clients will be used, and who owns them.
- Map each dashboard role to a named group and an approver before any accounts are created.
How we build
- Configure the SAML 2.0 path with the ceph dashboard sso setup saml2 command, or deploy the Management Gateway and OAuth2 Proxy services through cephadm.
- Test sign-in, sign-out and role assignment for each account type in a non-production cluster first.
- Set the session storage choice for OAuth2 Proxy and document what happens when oauth2-proxy stops.
How we hand over
- Deliver a configuration record with IdP settings, certificate locations, client identifiers and role mappings.
- Provide a runbook covering certificate renewal, IdP outage fallback and removal of departing administrators.
- Walk your operators through the sign-in flow and the checks that confirm SSO is working after a restart.
How we support
- Plan Ceph and Keycloak upgrades as separate steps, with the Keycloak release and operator update mode agreed in advance.
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-test SSO after each Ceph or Keycloak upgrade and record the results in the handover documents.
