Hardening Velero backups before ransomware finds them first

Velero remains one of the most common open-source tools for backing up, restoring and migrating Kubernetes cluster resources and persistent volumes. For managed service providers running many clusters, how well Velero is configured — not just whether it is installed — determines whether a backup is actually useful during an incident.

Backup success is not restore success

A backup job finishing without errors proves the data was captured, not that it can be put back. Ransomware operators increasingly target backup credentials and storage locations specifically, knowing that a working restore path is the difference between an incident and an outage. Restore drills, run on a schedule and logged as evidence, are the only reliable way to know a backup will work when it is needed.

Where to focus hardening effort

• Restrict the RBAC granted to Velero's service account to what backup and restore actually require, not cluster-admin by default.
• Encrypt backups at rest and keep at least one copy offsite or immutable, so a compromised cluster cannot also destroy its own backups.
• Separate the management path for backup storage from the workload network wherever the storage backend allows it.
• Rotate and scope the credentials Velero uses to reach object storage, favoring short-lived tokens over long-lived static keys.
• Treat the restore path itself as a production-admin capability — anyone who can trigger a restore can usually overwrite live data.

What Velero does not cover on its own

Velero backs up Kubernetes objects and, with the right plugin, persistent volume data — it does not by itself protect against a compromised cluster tampering with its own backup schedule, and it is not a substitute for network-level segmentation. Pairing it with immutable, offsite storage closes the most common gap MSPs see in practice: backups that exist but remain reachable from the same blast radius as the cluster they protect.

The baseline that matters is unglamorous: encrypted and offsite copies, restricted access, and a restore drill that has actually been run — not just scheduled.

Sources: GitHub — vmware-tanzu/velero, Velero documentation.