Use image annotations to split public and internal EOL lifecycle annotations
I maintainer di solito rispondono entro 1 giorno
@lbussell ci sta già lavorando.
Dal 13/7/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Background
- Azure container registries are automatically onboarded to vulnerability scanning.
- Keeping staged and previously-published images around for a short period of time is useful - however, they may go out of date quickly as new vulnerabilities are discovered and images are re-built/updated. This causes vulnerability scanning to provide useless alerts for images that aren't actually supported or sometimes not even published.
- Vulnerability scanning automatically ignores images with EOL lifecycle annotations.
Previously, we annotated all staged/internal/unsupported images internally with EOL lifecycle annotations so that they would be ignored in secret scanning, leaving only the official and supported images onboarded to scanning, keeping scan results actionable.
However, ImageBuilder now copies all referrer artifacts out of the container registry upon publish. This could cause publicly supported images to be marked as EOL (https://github.com/dotnet/docker-tools/issues/2066). Due to this, EOL annotation generation is temprarily disabled in nearly all repos using ImageBuilder. Thus, vulnerability scan results are now less useful/actionable again.
Background to the background
Container image lifecycle metadata comes in the form of OCI referrer artifacts.
Annotations can be applied to any OCI artifacts. Don't conflate them with referrer artifacts.
In the following example,
- The artifact is of type
application/vnd.microsoft.artifact.lifecycleand it refers tomyregistry.azurecr.io/dotnet/runtime@sha256:aaa111 - The annotation has a key of
vnd.microsoft.artifact.lifecycle.end-of-life.dateand a value of2026-01-01T00:00:00Z
oras attach \
--artifact-type "application/vnd.microsoft.artifact.lifecycle" \
--annotation "vnd.microsoft.artifact.lifecycle.end-of-life.date=2026-01-01T00:00:00Z" \
myregistry.azurecr.io/dotnet/runtime@sha256:aaa111
Proposal
There should be two distinct types of lifecycle artifacts managed by ImageBuilder:
- Those that are applied to public images after they are replaced/re-built.
- Those that are applied to internal images in our ACR to keep vulnerability scanning accurate/actionable.
We can use a new annotation in order to delineate between the two different types of refrerrer artifacts. I propose vnd.microsoft.dotnet.imagebuilder.internal. Example:
oras attach \
--artifact-type "application/vnd.microsoft.artifact.lifecycle" \
--annotation "vnd.microsoft.artifact.lifecycle.end-of-life.date=2026-01-01T00:00:00Z" \
--annotation "vnd.microsoft.dotnet.imagebuilder.internal=true" \
myregistry.azurecr.io/dotnet/runtime@sha256:aaa111
When ImageBuilder copies referrer artifacts from internal to public, it should read the annotations and always skip artifacts that have the annotation vnd.microsoft.dotnet.imagebuilder.internal=true. This can apply to any referrer artifacts, not just lifecycle metadata.
This would allow ImageBuilder to blanket annotate all build artifacts/historical images in an ACR as EOL without any concern for those artifacts leaking publicly.
- Lingua principale
- C#
- Stelle
- 182
- Fork
- 67
- Merge medio
- 2g 58m
- PR unite (30g)
- 16
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dotnet/docker-tools
-
area-dockerfiles up-for-grabs
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dotnet/docker-tools#2080 ·
I maintainer di solito rispondono entro 1 giorno
-
area-infrastructure
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
dotnet/docker-tools#2240 ·
I maintainer di solito rispondono entro 1 giorno
-
Rework container image rebuildsForse di nuovo libera @lbussell l’ha presa 83 giorni fa e non c’è nessuna pull request aperta. Apertaarea-infrastructure
dotnet/docker-tools#2166 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
image-info.json's `commitUrl` is incorrect when manifest is not in repo rootForse di nuovo libera @lbussell l’ha presa 85 giorni fa e non c’è nessuna pull request aperta. Apertaarea-infrastructure
dotnet/docker-tools#2165 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
area-infrastructure up-for-grabs
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
dotnet/docker-tools#2094 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dotnet/docker-tools
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
SubtitleEdit/subtitleedit#15462 ·
I maintainer di solito rispondono entro 1 giorno
-
:watch: Not Triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
comp:instrumentation.aspnetcore
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
open-telemetry/opentelemetry-dotnet-contrib#5427 ·
I maintainer di solito rispondono entro 1 giorno
-
design-proposal
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
dotnet/aspnetcore#69592 ·
I maintainer di solito rispondono entro 1 giorno
-
Client Container Registry customer-reported needs-team-attention question Service Attention
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
Azure/azure-sdk-for-net#63470 · 3 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno