enhancements icon indicating copy to clipboard operation
enhancements copied to clipboard

Verifying Image Registry Origin in Private Kubernetes Clusters

Open hasan4791 opened this issue 1 year ago • 1 comments

Enhancement Description

  • One-line enhancement description (can be used as a release note): Return image information from runtime to update pod resources, enabling users to identify and verify which registry (public or internal) an image is pulled from when deploying applications in private Kubernetes clusters.
  • Kubernetes Enhancement Proposal: TBD
  • Discussion Link: TBD
  • Primary contact (assignee): @hasan4791
  • Responsible SIGs:
  • Enhancement target (which target equals to which milestone):
    • Alpha release target (x.y):
    • Beta release target (x.y):
    • Stable release target (x.y):
  • [ ] Alpha
    • [ ] KEP (k/enhancements) update PR(s):
    • [ ] Code (k/k) update PR(s):
    • [ ] Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently. The proposal aims to address the challenge of verifying which registry an image is being pulled from when deploying applications in private Kubernetes clusters. Currently, users must manually check runtime logs to determine which registry was used, but this approach can be time-consuming and error-prone. The proposed solution seeks to provide transparency by adding a new label or field to the pod resource that indicates whether the image was pulled from a public or internal registry. This would help users better manage their applications' dependencies, troubleshoot issues related to image availability, and ensure compliance with organizational security policies.

hasan4791 avatar Apr 23 '24 12:04 hasan4791

/sig node

hasan4791 avatar Apr 23 '24 12:04 hasan4791

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Jul 26 '24 14:07 k8s-triage-robot

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle rotten
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot avatar Aug 25 '24 15:08 k8s-triage-robot

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-triage-robot avatar Sep 24 '24 16:09 k8s-triage-robot

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

k8s-ci-robot avatar Sep 24 '24 16:09 k8s-ci-robot