Azure
Docker.io Cache Registry Credential does not work as expected
Describe the bug I have created a credential set as instructed in documentation for docker.io caching rule. The credential is associated with a paid docker plan.
When associating the credential with the cache rule, I receive an error stating that rate limit is not present in header
To Reproduce Steps to reproduce the behavior:
- Create a credential set from a paid docker subscription (docker.io)
- Assign the identity to the key vault
- Associate the credential set with the caching rule
Expected behavior Caching rule works as documented
Screenshots
Additional context Based on docker documentation, authenticated requests from docker paid plans won't contain rate limiting headers in their HEAD or GET requests. I can confirm this:
$TOKEN=$(curl --user '****:**REDACTED*' "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest
Response Header:
HTTP/1.1 200 OK
content-length: 2782
content-type: application/vnd.docker.distribution.manifest.v1+prettyjws
docker-content-digest: sha256:767a3815c34823b355bed31760d5fa3daca0aec2ce15b217c9cd83229e0e2020
docker-distribution-api-version: registry/2.0
etag: "sha256:767a3815c34823b355bed31760d5fa3daca0aec2ce15b217c9cd83229e0e2020"
date: Wed, 25 Sep 2024 14:32:27 GMT
strict-transport-security: max-age=31536000
docker-ratelimit-source: 8f26886e-6395-4c12-b131-a13a9121683f
So, if your implementation expects that rate limit headers are always present in the GET or HEAD requests, I must say that's not the case.
https://docs.docker.com/docker-hub/download-rate-limit/
Hi @m-soltani . Thanks for reporting this bug. Even though the credential set status is incorrectly set as unhealthy, you should still be able to pull the image. We are currently working on a fix to report the correct status of the credential set when the rate limit is not present. The fix will be deployed on our next deployment in October. I will provide an update when the fix is deployed.
Thank you. I will try pulling new image tags to see the pull works as expected.
Good day @luisdlp! we're seeing the same message as @m-soltani said. How's the fix going on? is there any expected date to deliver it? Thanks!!
just as a piece of info -- we had the same issue and it's indeed a false positive (the pull works correctly).
it's just a bit annoying to see the error and we hope to see that fixed soon as well 😁, but if anyone is holding back the setup of the credentials because they fear the pull through might not work, i can at least confirm that it does.
Hello @ahojman and @conilas,
Thank you for responding in this thread. My apologies for the delay we are working on a fix for this. We have discovered the cause of the issue. We will deploy the fix soon.
We've fixed this issue. ETA for getting the fix deployed to all regions is 11/15.
We've fixed this issue. ETA for getting the fix deployed to all regions is 11/15.
thanks for the update!
hi @luisdlp may I ask if the fix has roll out because we have met the same issue.
We've fixed this issue. ETA for getting the fix deployed to all regions is 11/15.
Unfortunately, all deployments are paused this month. Our new ETA is 12/9. I apologize for the inconvenience this may cause.
please deploy, we need this fix.
There is nothing wrong with the functionality of the registry cache, it's just that the UI in Azure tells you it's unhealty, at least as long as you have valid credentials set.
please deploy, we need this fix.
There is nothing wrong with the functionality of the registry cache, it's just that the UI in Azure tells you it's unhealty, at least as long as you have valid credentials set.
oops, I thought our pull issue from registry was related to this issue here. Thanks for pointing out.
Hello Everyone,
We do have a fix for this UI error. However, our deployments are currently paused. Please rest assured that your credential sets are working the error is a result of a bug we discovered in the Portal UI. My apologies for the confusion and inconvenience.
