WIP: don't forget to request the pull scope #1
Conversation
Harbor will deny tags/list if you did not request the pull scope Signed-off-by: Kingdon Barrett <[email protected]>
|
In case you wanted to see where it's working and for what purpose: https://github.com/kingdonb/scrob-web/actions/workflows/kuby.yml (This is my weird fork of kuby that's designed to work on GitOps, with GitHub actions building and pushing images and manifests directed from my fork of the kuby cli!) I haven't quite caught up with your branches yet, I went looking to see if you had support for Edit: and here is the build where bundle update ran inside of GitHub Actions, you can see it's all hooked up to prebundler which makes ❤️ 🥰 |
|
I was looking for help with this issue and I googled only to find this discussion we had once before, with most of the information that I needed in it: |
|
Hey @kingdonb, thanks for submitting this :) It's my understanding that the registry should include the necessary scopes in the |
| end | ||
|
|
||
| def token | ||
| @token ||= begin | ||
| http = Net::HTTP.new(realm.host, realm.port) | ||
| http.use_ssl = true if realm.scheme == 'https' | ||
|
|
||
| url_params = { service: service } | ||
| url_params = { service: service, scope: "repository:#{repo}:pull" } |
There was a problem hiding this comment.
The :scope hash entry will get replaced by the body of the if statement below, is that ok? Should the repository:<repo>:pull scope be added to the scopes in www-authenticate or just be a default?
There was a problem hiding this comment.
I'm not sure the function of the body of the if statement below, but it wasn't getting replaced for me. I'm using a Harbor registry and it seemed like the Bearer token was getting requested with no scopes. I used Pixie to inspect the conversation, but I'm not sure I have all the details right, all I could say for sure is I had several processes of different kinds having this conversation (image-reflector-controller and others) and the one that was failing was here.
When I added the repository scope, it no longer received 401 on the request that uses the bearer token (in between building the app image and starting the build for the assets image, where it needs to confirm if any prior asset image exists, it tries to list the tags and fails 401.)
I wouldn't really suggest this change in particular as it's poorly thought out (this token will undoubtedly get used for other stuff besides pulling a specific repo), it was just the quickest way for me to confirm and resolve what was wrong in this one specific conversation that seems to be the only place this gem+token gets used by me, at least for now.
👋 😄
Cool! Looks like it's working nicely :) I didn't know you could pass
Oh, like the ability to use something other than ingress-nginx?
Sweet! I looked at the build output, looks a-ok! |
I just want to set
Yeah, this is working amazingly! I think I might even use it for my CNCF livestream next month. We're showing off image update automation and the new OCI config repo approach, that allows users of Flux to avoid adding sprawling many git repositories to their cluster, they can just use a lightweight and flexible OCI repository to handle the config instead. So I needed an approach to config that generates YAML manifests, and there are basically two extremes on the manifest generation train, there's something simple like I don't quite know of "something like Kuby" in any other languages, it's a pretty unique thing IMHO, but maybe I will point this out to 1000 people on the CNCF livestream and they will tell me about some things like it for go, scala, rust... The important thing for me was to get build/CI times down to the point where they can be almost as fast as Flux's CD when fully instrumented with webhooks. The whole build/deploy takes place in about 60-120 seconds, with at least 1/3 of that time usually spent waiting for build robots to pick up the job, and another 1/8 or so spent waiting for app to pass health checks 👍 |
Harbor will deny tags/list if you did not request the pull scope
(I do not know how scopes are supposed to be assigned, but when I debugged the conversation that happens in
kuby buildtoday, I came up against this issue on my public harbor registry)This brilliant fellow explains the conversation and how it's intended to happen, and the conversation continues in the gist linked from there... https://stackoverflow.com/a/51921869/661659
I am not sure what's the correct way to determine the scope, or how to best pass the repo in so the repo scope can be requested, but this version resulted in a 200/ok for me.
Also, hey! LTNS