-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verifying Image Registry Origin in Private Kubernetes Clusters #4589
Comments
/sig node |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
Enhancement Description
when deploying applications in private Kubernetes clusters.
k/enhancements
) update PR(s):k/k
) update PR(s):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.
The text was updated successfully, but these errors were encountered: