Kubernetes recommends six labels under the app.kubernetes.io prefix. For vulnerability tracking, name, version and part-of matter most. Kubernetes has no standard owner label, so add one of your own, such as a team label, and enforce it. Labels do not enforce anything by themselves, so check them in CI.
The recommended labels
The Kubernetes documentation lists these six, and recommends applying them on every resource object. They are recommendations only, not required by core tooling.
| Key | Meaning |
|---|---|
| app.kubernetes.io/name | Name of the application |
| app.kubernetes.io/instance | Unique name of this instance |
| app.kubernetes.io/version | Current version, such as a SemVer or revision hash |
| app.kubernetes.io/component | Component within the architecture |
| app.kubernetes.io/part-of | Higher level application this belongs to |
| app.kubernetes.io/managed-by | Tool managing the operation, such as Helm |
The three that earn their keep
name lets you join a running workload to a catalog entry and a repository. version lets you ask which running workloads are still on the affected release. part-of lets you roll findings up to a product.
The others are useful but less central. managed-by helps you find hand deployed workloads: if a workload lacks it, someone applied it manually.
The label that is missing
There is no recommended owner key. Define one for your organisation, with a prefix you control, and set it to a team name that matches your catalog. Pick one spelling and keep it. Two labels for the same idea is how a report ends up with a third of services under "unknown".
Make it real
- Pick the label set and write it in one page.
- Add the labels to your base chart or deployment template, so new services inherit them.
- Add an admission or CI check that rejects workloads without name, version and owner.
- Report on workloads missing labels weekly until the count is zero.
- Join labels to scanner output, so every finding carries a team.
Keep values consistent with the catalog. If the catalog says a team is called payments, the label should say payments, not Payments Team.
Where labels fall short
A version label is only as accurate as the process that sets it. If the image changes and the label does not, you have a confident wrong answer. Prefer setting the label from the same pipeline step that builds the image, and compare it with the image digest.
Quick check
Are these labels required by Kubernetes?
No. The documentation says they are recommendations and not required by any core tooling.
Should the version label hold a tag or a digest?
Use it for the application version. Track the digest separately, since a digest identifies the exact image content.
Safeguard's asset discovery and dependency scanning can use this metadata to group findings, and a free scan shows what a single repository reports.
Sources
Last reviewed: 19 October 2026.
