Ceph security updates and CVE patching

Ceph security updates and CVE patching: what keeps a cluster covered

Keep a production cluster on an actively maintained release and apply point releases through cephadm on a planned cadence. Coverage depends on the release line, not on the age of the hardware, so the first decision is which line the cluster runs. The Ceph releases page lists two actively maintained lines: Tentacle (20.2.x), first released November 18, 2025, with latest 20.2.4 and an estimated end of life of June 1, 2027, and Squid (19.2.x), first released September 26, 2024, with latest 19.2.7 and an estimated end of life of October 31, 2026. The project states that actively maintained releases receive periodic backports and security fixes. Confirm the current point release and end-of-life estimates on the Ceph active releases page before you schedule work, because those dates move. Any cluster on a release outside these two lines should be planned for a major upgrade before its support window closes.

Ceph is licensed under LGPL-2.1 or LGPL-3, and the project does not sell a paid edition with its own support contract. Security fixes reach you through the community release process, and it is your team, or the partner you engage, that must pick them up, test them and roll them out. That makes the patch process an operational responsibility with a recurring cost in staff time or retainer hours. Ask any partner to state in writing which release lines they will track, how they learn of new point releases, and who approves a change to a production cluster.

The safe way to apply a point release is through cephadm, which runs Ceph daemons as containers and upgrades them host by host with health checks between steps. Before the window opens, check that the cluster reports healthy, that enough capacity remains for a daemon to restart, and that you have a tested rollback path for the monitors. Plan the window around the release notes for each point release, since some changes need extra steps. Record the version running on every host and every daemon type, so you can prove afterward which fixes are in place. Treat each security point release as a standing change request with a named owner, a test cluster run first, and a date by which production must match it.

Which release line and patch approach fits your cluster

This table compares three ways to run a Ceph cluster against security fixes: staying on Squid, moving to Tentacle, and validating patches on a separate test cluster first. Read each row against the estimated end-of-life dates in the Ceph releases page, then confirm the cadence and out-of-band handling you need with the project or your vendor.

Option	When it fits	Support window and main risk	What to confirm
Stay on Squid until end of life	Cluster is stable, change windows are scarce, and a planned move to Tentacle is scheduled for later	Squid (19.2.x, first released September 26, 2024, latest 19.2.7) has an estimated end of life of October 31, 2026. Risk: fixes stop after that date, so the upgrade deadline arrives with little slack.	Whether the latest Squid point release includes every advisory that applies to your deployed features, and the exact date of the last planned backport
Move to Tentacle	You need a line that will receive fixes for longer, and you can plan a cephadm-managed major upgrade	Tentacle (20.2.x, first released November 18, 2025, latest 20.2.4) has an estimated end of life of June 1, 2027. Risk: a newer line may carry fewer field-tested fixes in your environment.	Upgrade path from your current release, client compatibility with your hypervisors and RGW consumers, and any known issues listed for the target point release
Validate patches on a separate test cluster	You run production workloads with strict change control and need proof that a point release behaves as expected	Test cluster costs hardware and admin time, and it only reflects production if it mirrors your OSD media, network and client mix. Risk: a test cluster that drifts from production gives false confidence.	Whether the vendor or project publishes upgrade notes for each point release, and how your support contract covers testing of out-of-band fixes
Scheduled maintenance window	Routine security point releases that can wait for planned change control	Patches are applied in a planned window with cephadm rolling the update across daemons. Risk: a long gap between windows leaves known advisories open on production.	The cadence your change board accepts, and how health checks must look before and after each rolling update
Emergency out-of-band patch	A published advisory affects a feature you expose, such as RGW or the dashboard, and cannot wait for the next window	Requires a fast path through approvals, a targeted point release and a rollback plan. Risk: rushed upgrades on a degraded cluster can cause more outage than the vulnerability.	How advisories reach you, who approves an out-of-band change, and whether your contract includes emergency response

Setting up a patch routine with cephadm

This sequence moves a cluster from its current release to a security point release in a controlled order, with a staging rehearsal and checks at each stage. The result is a patched cluster and a written record of the version, health and client checks that prove it.

Confirm the running version
The storage administrator checks which Ceph version every daemon runs before anything changes. Use the cluster status view and the cephadm version check on the admin host, then compare the output with the version listed for each daemon type. Confirm exact command syntax against the cephadm documentation for the installed version. This step is done when you have a written inventory showing one consistent running version, or a list of hosts that already differ and need attention first.
Record the target point release
Open the Ceph active releases page and identify the point release for your release line that carries the security fixes you need. Note the release name, the version number and the date it was published, and check the release notes for security and known-issue entries. Confirm that your running release line is still listed as actively maintained. If it is not, the patch routine becomes a major upgrade planning task, which is a separate effort. This step is done when the target version and its release notes are saved with the change request.
Verify cluster health before starting
Run a full health check and record the result before touching any daemon. The cluster should report HEALTH_OK, or any warnings should be known, documented and accepted by the change owner. Check that placement groups are active and clean, that no recovery or scrub is in progress, and that enough capacity remains to absorb a daemon restart on each host. Stop the change if health is degraded. This step is done when the pre-change health output is saved alongside the version inventory.
Rehearse the upgrade on staging
Run the same cephadm upgrade to the target image on a staging cluster built from the same release and a similar host layout. Start the upgrade with the cephadm upgrade commands for the target version, then follow its progress. Record the time each stage takes and any warnings raised. Any failure found here should be fixed in the runbook before production is touched. This step is done when the staging upgrade completes and the staging cluster reports the expected version on every daemon.
Watch daemon restart order and warnings
On production, start the cephadm upgrade to the target image and monitor it until completion. Cephadm restarts monitors, managers, OSDs, metadata servers and gateways in an order it controls, so watch the upgrade status and the cluster health after each batch. Pause or stop the upgrade if health warnings persist, if placement groups stop returning to clean, or if a daemon fails to come back. This step is done when the upgrade reports complete and every daemon reports the target version.
Validate client access and data operations
Confirm that clients still reach the cluster after the restart cycle. Run a read and write test against each interface in use: a test object write and read through the object gateway with a service account, a test image map and write on a block client, and a file mount check if CephFS is in use. Confirm that existing cephx keys still authenticate and that no client receives authorization errors. This step is done when each interface in use passes its test and the results are recorded.
Document the result and close the change
Write a short record that names the starting version, the target version, the release notes reviewed, the health output before and after, the daemon restart observations, and the client test results. Store the record with the change ticket and set the next review date for the following point release. Ask the change owner to sign off. This step is done when the record is filed, the inventory matches the target version, and the next patch review is scheduled.

Security and operational risks while patching

Patching a Ceph cluster is itself a security-sensitive change. The cards below cover the risks that show up most often: running on a branch that no longer gets fixes, breaking clients during a rollout, exposing the tooling that drives upgrades, widening access to the cephadm SSH key and admin keyrings, trusting unverified container images, and losing the record of who approved each change.

Unpatched clusters on an end-of-life branch

A cluster that stays on a release past its end of life stops receiving backported security fixes, so every new advisory becomes a risk you carry alone. Compare the running version with the active release list on the Ceph releases page and write down the end-of-life date for each cluster. Confirm with the project which fixes, if any, reach older branches before you decide to stay put. Plan the next major move early so it does not become an emergency.

Rollouts that break client compatibility

A security point release can change client behavior, such as authentication handling or messenger settings, and break older RBD, RGW or CephFS clients that were never retested. Before rolling out, inventory every client type and kernel or library version still in use, then test each one against the target release in a staging cluster. Keep a documented rollback path for clients that cannot move at the same pace as the cluster.

Unauthenticated access to upgrade tooling

cephadm drives upgrades through the orchestrator, and anyone who can reach its management interfaces or the dashboard API can start or alter an upgrade. Restrict dashboard and management endpoints to an administrative network, require authenticated access for every operator, and confirm which accounts hold orchestrator permissions. Review those permissions before each patch window so that stale accounts do not keep upgrade rights.

Widened SSH key and admin keyring exposure

During a patch window, engineers often copy the cephadm SSH key or the admin keyring onto laptops, jump hosts or temporary automation to speed things up. Each copy extends the set of machines that can administer the whole cluster. Limit the SSH key to the hosts cephadm manages, keep admin keyrings on designated _admin hosts only, and remove any temporary copies once the change closes. Record which hosts hold the keys before and after the window.

Unverified container image sources

cephadm deploys each daemon from a container image, so the registry and tag you pull from define the code that runs in production. Pulling from a mutable tag or an unapproved mirror makes it hard to prove what was deployed. Pin each release to an immutable image reference, mirror approved images into a registry you control, and verify digests before rollout. Confirm the source and signing approach with the Ceph project and your registry team.

Missing change approval and audit records

When a patch goes wrong, the first questions are who approved it, which version moved, which hosts changed and who ran the commands. Without a written record, those answers come from memory and shell history. Keep a change record for each point release that names the approver, the source version and target version, the hosts touched, the validation results and the rollback decision. Store these records where the people who run the cluster cannot quietly edit them.

Tracking advisories and deciding what to apply

Start by building a watch list that matches your cluster, not the project at large. Subscribe to the Ceph release notes and to whatever security notification channel the project currently offers, and confirm the exact channels, their names and how they deliver notices on the project site before you rely on them, since these can change. Record which release line each cluster runs. The releases page lists Tentacle (20.2.x) and Squid (19.2.x) as the actively maintained lines, with published estimated end-of-life dates for each. Note those dates in your change calendar, because a cluster on a line past its end-of-life date will not receive the fixes you are waiting for.

When an advisory arrives, map it against what you actually run. Check the affected release lines first, then the services that are enabled: the Object Gateway (RGW) if you serve S3 or Swift traffic, the Dashboard if it is reachable, and any msgr2 settings such as secure mode. An advisory against a component you do not run may be a documented non-issue for you, but record that conclusion with the date and the name of the person who made it. Keep a short inventory with the running version of every host and container image, so the mapping takes minutes rather than a search across hosts.

Then decide between an out-of-band rollout and the next scheduled window. Move early when an exposed service is affected and the exploit path is reachable from networks you do not fully control, such as an RGW endpoint on a public address or a Dashboard that users reach from outside the management network. Otherwise, a fix in a point release can usually wait for the planned window, provided you have a documented compensating control. Whichever path you choose, write down the decision, the evidence behind it and the rollback plan before you start, and ask your partner or internal team to show how a cephadm point release is staged across hosts.

Patching differences by deployment environment

With cephadm, the Ceph daemons run as containers on hosts you control, and the orchestrator applies a point release across those hosts. Your routine is to confirm the release line your cluster is on, schedule a point release, and let cephadm restart daemons in sequence while the cluster stays healthy. Start by checking the active releases page for your version and its estimated end of life.

Version track: Confirm whether your cluster runs Squid or Tentacle, the two actively maintained releases, and record each estimated end of life date.
Staging first: Apply the point release to a non-production cluster with the same host OS, network layout and client mix before production.
Health gates: Check cluster health and recovery state before and after each group of hosts, and agree in advance on the conditions that stop the rollout.
Host OS packages: Patch the host operating system and kernel on a separate track, and confirm that the container runtime and cephadm versions remain supported for the target release.
Client compatibility: Confirm that RBD, RGW and kernel clients reconnect cleanly after daemons restart.

Confirm the target point release, the staging result and the rollback plan before you schedule the maintenance window.

Limits to confirm before you commit to a patch schedule

A patch schedule is only as good as the assumptions behind it. The items below are the facts that change over time or depend on your own environment, so confirm each one before you commit dates to a change calendar or a compliance commitment.

Exact end-of-life dates

The end-of-life dates on the Ceph releases page are estimates, not commitments. Check the current page on the day you plan the work, and record the date you checked. Build your upgrade window so that it finishes well before the release you run stops receiving security fixes, and set an internal alert for the estimated date so the planning conversation starts early.

Advisory scope by feature

A published advisory does not always affect every deployment. Some issues depend on a specific feature, such as the Dashboard, Object Gateway authentication or a particular protocol mode. Map each advisory to the features you enable, the daemons you run and the configuration you have, then decide whether the fix is urgent or part of the next scheduled point release.

Client version support

Security fixes in the cluster do not update the clients that talk to it. Kernel RBD clients, hypervisor libraries, Kubernetes CSI drivers and custom S3 applications each carry their own versions. Inventory every client, confirm which Ceph releases it supports, and identify the ones that will need their own update before you can move the cluster forward.

Container image availability

cephadm pulls container images from a registry during upgrades and point releases. Confirm that the image tags you need are mirrored into your internal registry, that the mirror syncs on a schedule you control, and that the images are signed or scanned under your own policy. An air-gapped or restricted site may need an offline image bundle prepared in advance.

Change-window rules

Your organization may limit when production storage can change, require a freeze before quarter close, or demand a separate approval for each restart. Confirm these rules before you promise a date. Ceph rolls daemons one at a time, but recovery traffic can still affect clients, so the window must allow for data movement after each host restarts.

Support terms against your compliance needs

The project's support terms describe which releases receive fixes, not what your auditor expects. Compare the support window, the patch cadence and the disclosure process with the vulnerability management requirements in your framework. If your policy sets a shorter maximum time to patch, or requires vendor-issued advisories, plan for a gap or arrange your own support path before the release goes out of support.

Questions buyers ask about Ceph security patching

What does it cost to keep a Ceph cluster patched, and who pays for what?

Patching cost has two parts: the internal staff time to plan, schedule and verify each point release, and any external work you buy for the rollout. Ceph itself is licensed under LGPL-2.1 or LGPL-3 and the project offers no paid edition, so there is no license fee to budget for security fixes. The recurring costs are staff hours for monitoring advisories and running upgrades, maintenance windows, and test capacity for a staging cluster. Costs rise with cluster size, the number of hosts and OSDs, how many client types depend on the cluster, and how much pre-change testing your change process demands. Ask any partner for a written scope that separates one-time work, such as building the runbook, from recurring work, such as quarterly point releases, and ask which items are fixed and which are billed by time.

How long does a rolling security point release take on a cephadm cluster?

Duration depends mainly on cluster size, the health of the cluster before you start, and how much capacity is left to absorb daemon restarts. cephadm upgrades daemons in stages, so the run time grows with the number of hosts and services and with how long each daemon takes to come back healthy. Data recovery and rebalancing can extend the window if any OSD is down or degraded when you begin. Pre-checks, staging rehearsal and post-upgrade verification add time that is separate from the upgrade itself. The Ceph documentation for cephadm describes the upgrade process, and you should confirm the expected sequence for your exact release with your team before scheduling. Ask for a timed rehearsal in a non-production cluster before committing to a production window.

What does our internal team need to provide for patching work?

Your team needs named owners for the cluster, a change process that can approve maintenance windows, and access to the cluster through cephadm with appropriate administrative rights. Someone must also own the decision to upgrade, including sign-off on the target point release and on rollback criteria. Engineers should be able to read cluster health output, interpret placement group states and check client applications after a restart. You also need a staging environment that resembles production closely enough to catch client compatibility problems, and monitoring that alerts on degraded health during the window. Confirm access, approval paths and on-call coverage before the work starts, because these are the most common reasons a scheduled release slips.

Can our own team keep a Ceph cluster patched without a partner?

Yes, many teams do this in-house, provided they have the skills and time. The Ceph project publishes its active releases and states that they receive periodic backports and security fixes, so your team can follow that schedule directly. The main risks are slow recognition of new advisories, skipped point releases that leave the cluster behind, and upgrades performed without rehearsal. A partner is most useful when the team lacks cephadm experience, has no staging cluster, or cannot staff regular windows. Whichever route you choose, write down who watches the release notes, who approves each upgrade, and how you verify the result. Ask any partner to show how they would hand the runbook and history back to your team.

What happens when our Ceph release reaches end of life?

When a release reaches its end-of-life date, the project no longer provides backports or security fixes for it, so the cluster needs to move to a supported release. The Ceph releases page lists the currently maintained releases and their estimated end-of-life dates. Moving between major releases is a larger project than a point release because it touches more of the cluster and its clients, so it needs its own plan, testing and window. Start planning well before the date, since a major upgrade needs time for client compatibility checks, rehearsal and approval. Confirm the end-of-life dates against the releases page when you plan, because estimates can change.

How do we handle an urgent security advisory outside the normal schedule?

Treat an urgent advisory as a separate change with a short decision cycle. First, check whether the advisory affects your release, your enabled features and your exposure, since a flaw in a component you do not use or cannot reach may carry lower urgency. Second, decide whether a point release is available and whether it can be applied with a rolling restart or needs a longer window. Third, use your emergency change process, rehearse the steps in staging if time allows, and verify health and client behavior afterward. Compensating controls, such as restricting network access to the dashboard or tightening cephx capabilities, may reduce exposure while you wait. Having the runbook ready before an advisory arrives is what keeps this path short.

Does DeployOpen issue compliance attestations for our patching program?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, such as patch records, change history, runbooks and verification results. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. In practice, we would help you define what evidence your assessor will want, such as a record of advisories reviewed, the release applied, the date and the verification performed, and set up a process that produces that evidence consistently. Ask your auditor which artifacts they expect before the engagement is scoped, so the evidence design matches their test procedures.

What to ask for in a written scope

A fixed-scope patching engagement or retainer should start with a current version inventory: the Ceph release on every daemon, the cephadm version on each host, the container image each service runs, and any client libraries that talk to the cluster. Ask the partner to produce this inventory in writing before any change is planned, and to name the target release line explicitly, such as Squid (19.2.x) or Tentacle (20.2.x), with the reasons for the choice. Confirm the estimated end-of-life dates for each line on the Ceph releases page before you accept a target, because a line that ends during your planning window forces a second upgrade.

The scope should also state the staging and rollback plan in concrete terms: which environment mirrors production, how a point release is tested there, how cephadm upgrade progress is watched, and what the rollback path is if a monitor or OSD fails to come back. Ask who owns advisory monitoring, meaning who reads Ceph security announcements, decides whether a fix applies to your configuration, and opens the change request. Agree on a cadence for routine point releases and a separate path for urgent fixes, and write down who may make out-of-band changes such as a hotfix image, a manual ceph config set or a host package update, and how those changes are recorded afterward.

Finally, list the evidence the engagement will produce for your assessors: the version inventory at each point, change records, test results, upgrade logs, and the advisory register. DeployOpen prepares systems and records for assessments but does not issue audit reports, attestations or certifications, so the scope should say that your auditor or certification body remains responsible for their own conclusions. Confirm the format, retention period and storage location of these records in your own environment.

How DeployOpen works on this

DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph. For security updates, we start from your current release and advisory exposure, then agree in writing how each point release will be tested, rolled out and evidenced before any cluster is touched.

How we scope

Inventory the running Ceph release, cephadm version, container images and host operating systems across every cluster.
Agree in writing which release line you will stay on and the support window it implies.
Define who reviews advisories, who approves a rollout and how emergency patches are handled.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Build a staging cluster that mirrors production topology, including CRUSH rules, RGW and client versions.
Write rollout runbooks with cephadm upgrade steps, health checks, pause points and rollback criteria.
Run security and functional tests against the staging cluster before each point release reaches production.
Confirm that client libraries, hypervisors and Kubernetes CSI drivers still work with the target release.

How we hand over

Document the advisory tracking process, owners, escalation contacts and the patch calendar.
Deliver the tested runbooks, rollback procedure and a record template for each patch applied.
Train your operators to run cephadm upgrades and read health output before and after a change.
Hand over evidence packs that show versions, test results and approvals for your audit trail.

How we support

Offer ongoing patch support, release tracking and staging validation as a retainer.
Plan periodic reviews of the release line against published end-of-life dates for your cluster.
Plan joint emergency patch windows with your change board when an advisory affects your deployment.
Prepare evidence for your compliance assessment, while independent auditors issue any audit reports.

Ceph security updates and CVE patching