kubernetes
Search available images in container registry when deploying from settings
I'd like to see some integration with container registries to make deploying images easier for the end user.
The way I see this feature breaks down to 2 tasks:
- Add an endpoint to the backend to fetch a list of public images from a configured container registry endpoint. Ideally supporting multiple container registry providers (we use Quay.io but I know a lot of people use Docker's offering).
- Add a widget to the deploy from settings page to search the offered images and let the user select the desired image. This could be an auto-complete on the container image text box, or a button adjacent to the text box opening a selector modal.
We were planning to add autocomplete and some support for docker, and possibly other providers but there were many other things to do and polish before release. I believe this will be implemented at some point. Maybe even in the next release. We'll know more after next planning.
@codegoblins Sounds just about right. I think if you have spare cycles, it is ready to be implemented. We've been planning such feature anyways :)
Are you taking this?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Hey, I would like to contribute to the kubernetes-related projects and it feels like starting with this one would a good first issue for me. Is it up for grabs?
@mic4ael Yes. It would be good to create a pull request early so we can discuss the architecture of it. Or you can write that down before you start if you already have an idea.
Sure! I will first take a closer look on how everything works internally and then I will come up with some initial implementation plans.
On Fri, 16 Oct 2020, 16:16 Marcin Maciaszczyk, [email protected] wrote:
@mic4ael https://github.com/mic4ael Yes. It would be good to create a pull request early so we can discuss the architecture of it. Or you can write that down before you start if you already have an idea.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/dashboard/issues/511#issuecomment-710074987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3TBLAGK3Z2I7K4PWREQG3SLBIVNANCNFSM4B5Q3B2Q .
Is there any work already done on this, @floreks / @maciaszczykm / @bryk?
Any notes of previous discussions world of great help to us to determine if this is something can be worked from where it was left or need fresh start.
Q1: Is this feature request to store only the registry providers endpoint in settings, then using the endpoint GET "list of images" (by verified / official / all if allowed by registry provider) while typing in "container image" input filed and caching for sometime?
Fetching all "images" from public / private registry itself is not helpful in my opinion nor I think it is even allowed [rate-limit] by registry at one go or incremental; but the title and description ask is this I believe.
Please help me understand the request better @maciaszczykm , @codegoblins . 🙂
Q2: Do we need to pre-populate a list of well known public image registry endpoint or let the user add themselves somewhere in the settings?
- If pre-populate, then what are those list of well known registry providers we need to add?
- If it is to be set at settings, and reset default settings is applied, what should this feature reset to? Erase all registry endpoint added by the users or do we need to add another checkbox to avoid erasing image list?
Q3: Do we need an images already pulled / built (may date back to very long ago and may have very long list) through any method (docker pull, podman pull, docker build, buildah bud etc.) be recognised and listed on dashboard as in when you type in the “container image” input field?
Q4: Do you think this should be an extension / K8s operator to the K8s dashboard / CLI method and not baked within dashboard?
@haripriya1909 if you want to work on it you need to sync with @prnam as he was first to claim it.
Q1: Is this feature request to store only the registry providers endpoint in settings, then using the endpoint GET "list of images" (by verified / official / all if allowed by registry provider) while typing in "container image" input filed and caching for sometime?
Fetching all "images" from public / private registry itself is not helpful in my opinion nor I think it is even allowed [rate-limit] by registry at one go or incremental; but the title and description ask is this I believe.
Please help me understand the request better @maciaszczykm , @codegoblins . 🙂
I think there is no real plan for this one yet. We agreed that this would be a nice to thing to have but I didn't spend any time to get more familiar with this topic and provide any proposal. If you want to work on it then a proposal would be a good way to start. Consider some options and provide your insights. We'll try to help. @codegoblins do you have any ideas that might help at this point?
Q4: Do you think this should be an extension / K8s operator to the K8s dashboard / CLI method and not baked within dashboard?
Something dashboard-specific will be enough unless you have different plans.
Q2: Do we need to pre-populate a list of well known public image registry endpoint or let the user add themselves somewhere in the settings?
Having settings is almost always better but can be added later on.
If pre-populate, then what are those list of well known registry providers we need to add?
Start with something simple.
Apologies for creating an issue then going dark for 6 years but I stopped working on k8s related projects so I'm afraid I don't have much to add. At the time I was thinking it would be nice to have some form of autocomplete, whether that was searching a public or private registry, or even just remembering images I've deployed before (e.g. in localstorage). That was based on my use of the software in its early stages though, I couldn't tell you if it would be useful now.
Search & Select Container Image feature
Objective
- Reduce the issues with wrong image pull or typo-sqautting attacks
- Make it even more easier to select image using container field present at create from form
Key outcomes
- Time taken to select image for users must reduce, thus improve user experience
- Should minimise typo-sqautting attacks
- Should widely be accepted by the community as stable feature for at least 6 months from launch
Due date - March 31, 2022
🤔 Problem Statement
Manual entry of container image name or digest without autocomplete may lead to unintended images pulls or typo-squatting attacks. Listing images from well known registries as in when user types in container image field present at create from form tab and making them able to select it if they are happy with suggestion will help reduce the issue and may lead more user adopt to the create from form page i.e in other words increase better user experience to our dashboard users.
🎯 Scope
Must have:
-
container image field in create from form should be able to search & select the image from configured registry
-
only list public images which are classified / vetted as verified or official
-
registry configuration on settings page
-
out-of-the-box configuration of well known registry that are OCI compliant
-
fallback to text based input (as it is now) on container image field when none is selected from the list or images or from pre-pulled or locally built images
-
pull latest image information from all registry configured, every time create from form is selected by user
Nice to have:
- list all public images that are available in any registry and remove limitation to verified and official images
- to use logos than using wordmark as prefix for uniquely identifying images with same name (ex: using docker logo and image-name:tag as text than using docker/ngnix:latest / acr.io/ngnix:latest / gcr.io/ngnix:latest as plain text in suggestion dropdown list)
- extend the ability to search & selected from image:tag to also using image@digest
Not in scope:
- private hosted registry configuration on settings page
- preview metadata of image within container image field in create from form
- list locally built images
- helm charts
📒 Registries
| Name | Method | Out-of-the-box configured or Pre-configured | Comments | Image (Public / Private / Private & Public) |
|---|---|---|---|---|
| Docker | API | YES | add auth as secrets for private registry access | Private & Public |
| Azure | API | YES | add auth as secrets for private registry access | Private & Public |
| OCI | API | YES | add auth as secrets for private registry access | Private & Public |
| GCP | API | YES | add auth as secrets for private registry access | Private & Public |
| AWS | API | YES | add auth as secrets for private registry access | Private & Public |
| Quay | API | NO | API are not documented well at the moment | N/A |
Hey @maciaszczykm, Please find initial project plan for this feature, as I see it.
I am working on high fidelity design and will share it as soon as I am done. Any inputs you shall have, kindly share 🙂
@prnam Sounds nice, you can continue with creating proof of concept. I'd start with adding support for one registry, i.e. Docker. Please open pull request sooner rather than later so we will be able to discuss technical details as this doesn't cover them.
You read my mind, @maciaszczykm, Docker is first will be done. Every weekend you will get the updates both design and technical with draft PR. Will tag you here or Slack, when done or need help.
Updates from my notes (so far):-
- Postman Workspace consisting of REST API that will be used to fetch Image list & tags
- Here is how to get pre-pulled / built images list -
curl --unix-socket /var/run/docker.sock http://localhost/images/json | jq '.[0].RepoTags' - Here is how to configure Private registry -
Stuck at & Help needed -
- How to list catalogs from DockerHub, GCR, OCIR and ECR as anonymous user via REST API
- How to list specific image and tags for given namespace (registry-alias in AWS) & repository-name via REST API for ECR & OCIR
- How to only list OR sort the list by official images / verified publisher / verified accounts for any public registry
Update:
- w.r.t. AWS Public Registry, I have raised help at AWS:Repost. Hoping to get help some day.
- w.r.t. Docker Registry, received some help at Slack - Docker Community
Next Steps(moving ahead) :
- creating a high fidelity design on the possible approach and get reviewed
- once approach is approved based on design, raise initial PR with same approach from technical standpoint
Other:
- K8s #sig-ui Slack discussion thread here
I was wondering if we can use etcd to store temporary key-value data of the image from all known registry and thus allow search/auto complete? Would look into these deeper but putting it out know if anyone had this thoughts and would like to share if there is any success / failure stories?