Hardening the Ceph Dashboard

The Ceph Dashboard is a manager module, so it runs inside the active ceph-mgr daemon and talks to the cluster through the same management interfaces that operators and automation use. That placement is the reason its trust boundary matters: a person who can log in to the dashboard is not limited to viewing a status page. Depending on the role granted, that session can change pool settings, manage RBD images and gateways, and alter configuration. Before you harden anything else, map four things: the browsers and users that reach the dashboard, the identity provider behind any single sign-on design, the networks that can reach the dashboard port, and the cluster functions each role can call.

Treat a compromised dashboard account as a path into cluster management, not as a read-only incident. An attacker with a valid session, or with a stolen password for a privileged role, can use the dashboard's own features to reach the functions that the role permits, and the blast radius follows the role's permissions. For that reason, the first decision is which people hold administrative roles at all. The second is where the login path leads: if single sign-on is used, the security of the identity provider and its group mappings becomes part of the dashboard's boundary, so a weak or loosely governed provider weakens the cluster too. Confirm the exact SAML 2.0 or OAuth2 options your cephadm release supports in the Ceph Dashboard documentation before you design around them.

Finally, decide which networks may reach the dashboard and keep that list short. The dashboard should sit on a management network that administrators reach through controlled paths, not on the client or public network where application hosts and untrusted segments can open connections. Write down who may reach the port, from which source ranges, and through which proxy or gateway, then test that the restriction holds from outside the approved networks. Record the answers in your design document, because every later control in this topic, from roles to audit logging, assumes that the boundary is where you said it is.

The engagement is a fixed scope agreed in writing before work starts. The deliverables are an access inventory of every dashboard account, role and API client in use, a role model that maps each team to the least set of dashboard permissions it needs, and the configured password policy and lockout settings applied to the cluster. The scope also covers the audit logging design, including where API audit records are kept and who reviews them, an SSO integration where you have chosen one, and a review of where the dashboard sits on the network. Each item is written down so your team can judge whether it matches your requirements before anything changes in production.

Verification evidence and a handover runbook close the engagement. The evidence shows each control in its applied state: role assignments, policy values, a test lockout, sample audit entries and the network path to the dashboard. The runbook explains how to add an operator, rotate credentials, read the audit trail and roll back a change. DeployOpen prepares these controls and this evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence format your assessor expects.

Ongoing support, upgrades and continuous testing are available as a retainer, which suits clusters whose dashboard roles and SSO settings change often. Ask any provider for a written scope that names the cluster version, the accounts in scope and the acceptance checks, then compare the quote against that list line by line. Confirm with your own team which dashboard functions must stay available to on-call staff, because that answer decides how tight the role model can be.

Dashboard hardening is scoped in writing before any setting changes. The agreed scope names the dashboard endpoints, the users and roles in scope, the password and lockout policy to be applied, whether API audit logging will be turned on and where its logs are sent, and whether single sign-on is in or out of scope. Deliverables and timelines are fixed in the same document, so the client knows what will be changed, what will be left alone, and what evidence will be handed over at the end. If SSO depends on cephadm running the Management Gateway and OAuth2 Proxy services, or on an identity provider the client has not yet set up, confirm that dependency during scoping because it can move the timeline more than the dashboard settings do.

Changes are tested on a non-production cluster where possible. Role reassignments, lockout thresholds and the move of the dashboard onto a management network can each lock out an operator or break a monitoring integration, so DeployOpen proposes to rehearse them on a lab or staging cluster first, using the same Ceph release as production. Where a non-production cluster is not available, the scope should say so and describe the rollback path, such as keeping a tested administrator account with its previous settings until the new login path has been verified. Ask whether the client can provide a staging cluster, how closely it matches production, and who approves the production change window.

Support continues after handover through an optional retainer. Once the hardening is complete, the dashboard configuration, role model and audit logging still need review as the Ceph release moves through its maintenance period and as operators join or leave. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover reviewing dashboard access, applying security point releases and re-running the configuration checks after a change. A retainer is a separate agreement from the fixed-scope work, so ask for its terms, response expectations and what is excluded before deciding whether it fits your team.