Velero: 180 page titles, 2,794 body matches, zero fingerprints, and a backup tool that holds cluster credentials
Backup tooling occupies an uncomfortable position in a security review. It needs broad access by definition, it runs on a schedule nobody watches, and its output is a copy of everything it protects. Velero is the Kubernetes-native example: an open-source project that backs up cluster resources and persistent volumes to object storage and restores them on demand. ZoomEye measurements taken on 26 October 2026 put its public footprint in perspective.
The three observations
All queries ran against ZoomEye with sub_type="all" and pagesize=1, so each total describes matched assets rather than retrieved records.
| Query | Matches |
| --- | ---: |
| title="Velero" | 180 |
| http.body="Velero" | 2,794 |
| app="Velero" | 0 |
The title count is small, and small is what the architecture predicts. Velero is a controller inside a cluster, not a web console. Its visible surface is a command-line client, some metrics, and, where an operator has added one, a UI. None of those need to answer on a public address, and a deployment that does is a configuration choice rather than a default.
The body count of 2,794 is fifteen times larger and still modest. It captures documentation, blog posts about backup strategies, and responses that happen to mention the tool.
The zero on app is the familiar pattern: no fingerprint rule exists, so this query measures the fingerprint set, not the software population.
What a backup system can see
Velero's design centres on the cluster's API server. It lists the resources in scope, serialises them, and writes the result to an object store. Volume snapshots or file-level copies are handled through the storage provider or through a node agent.
That description alone explains the security weight. A backup contains every secret object that the backed-up namespace includes, in whatever form the cluster stores it. Restoring a backup into a cluster writes those objects back. An actor who can read the backup repository, or who can trigger a restore, has a path to material that the cluster administrators themselves access through the API with auditing attached.
Two further details matter for review. The first is the credentials. Velero needs permissions to read the resources it backs up and permissions to write to the storage backend. The object store credentials are usually a static access key stored in a secret, which is a long-lived credential with write access to the backup location.
The second is the schedule. A backup that runs hourly produces many copies of the same secrets, and retention policies decide how long each survives. A compromised backup location therefore holds a moving history of the cluster's credentials rather than a single snapshot.
Where the exposure actually appears
The public measurement describes a console or a documentation surface, not the backup path. The realistic exposure is different and worth naming.
A restore operation is a write to the cluster. An actor with access to the Velero API or to the namespace where its resources live can initiate a restore of a chosen backup into a chosen namespace. That is a mechanism for reintroducing deleted objects or overwriting current ones, and it uses the controller's own permissions.
The storage backend is the second surface. Object storage buckets holding backups are frequently reachable from more networks than the cluster is, and the credentials that reach them are frequently shared with other tooling. A bucket listing that includes cluster backups is a high-value finding regardless of what the cluster itself exposes.
The node agent is the third. File-level backup reads the volume contents on the node, which means the agent runs with host access. The privilege it needs is the privilege it can use.
Controls worth the configuration
Give the backup credentials their own scope. A bucket used only for cluster backups, with an access policy that permits write and list only for the backup path, bounds what a leaked key can reach. Where the storage provider supports workload identity or short-lived credentials, use them.
Encrypt the backup at rest with a key the storage provider does not control alone. Cluster backups contain secrets; treating the bucket as ordinary storage is the wrong risk assumption.
Restrict who can create restores. Velero's restore operation is an API write, and the RBAC rule that permits it should be as narrow as the rule that permits secret reads, because a restore can produce the same outcome.
Monitor for restores that nobody scheduled. A restore is a discrete event with a timestamp and a requester, and an unexpected one is a signal that is easy to alert on and hard to explain away.
Treat the object store as part of the cluster's attack surface. Inventory it, log access to it, and review the identities that can read it.
Reading the number honestly
180 title matches is a small measurement, and it should be reported as one. It indicates that a modest number of hosts present a Velero-named page to an unauthenticated request. It says nothing about how many clusters run Velero, because most of them never expose anything to the internet at all.
The useful conclusion is structural rather than statistical: a backup system holds what it protects, so its credentials and its repository belong in the same inventory as the cluster they serve. The measurement locates the visible edge of that population; the risk sits behind it.
References
- Velero documentation: https://velero.io/docs/
- Velero source repository: https://github.com/vmware-tanzu/velero
- ZoomEye search platform: https://www.zoomeye.ai/
Measurement note
Queries: title="Velero", http.body="Velero", app="Velero". Executed 26 October 2026, sub_type="all", pagesize=1, global scope. Counts describe matching assets, not confirmed vulnerabilities or exploitation.
Top comments (2)
bookmarking this for the next backup tool security review
검색 결과의 제목·본문 일치를 실제 설치 수나 취약점 수로 확대 해석하지 않은 점이 좋네요. 특히 백업 저장소와 복원 권한을 클러스터 보안 경계 안에 함께 넣어야 한다는 설명이 중요해 보입니다. 복원 작업의 요청자·시각뿐 아니라 승인된 복원 계획과 연결해 두면 정상 복구와 예기치 않은 변경을 구별하기 더 수월하겠습니다.