Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Use image annotations to split public and internal EOL lifecycle annotations

Đã đóng
  • Có gì không ổn?
#2,153 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@lbussell đang làm issue này rồi.

Từ ngày 13/7/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

area-infrastructure
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.lifecycle and it refers to myregistry.azurecr.io/dotnet/runtime@sha256:aaa111
  • The annotation has a key of vnd.microsoft.artifact.lifecycle.end-of-life.date and a value of 2026-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.

Ngôn ngữ chính
C#
Star
181
Fork
67
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Không có Dockerfile hay tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/docker-tools

Tất cả issue của dotnet/docker-tools

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.