Azure / acr

Azure Container Registry samples, troubleshooting tips and references
https://aka.ms/acr
Other
164 stars 114 forks source link

Docker.io Cache Registry Credential does not work as expected #779

Open m-soltani opened 1 month ago

m-soltani commented 1 month ago

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:

  1. Create a credential set from a paid docker subscription (docker.io)
  2. Assign the identity to the key vault
  3. Associate the credential set with the caching rule

Expected behavior Caching rule works as documented

Screenshots image

image

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/ image

m-soltani commented 1 month ago

Someone willing to take a look into this issue?

luisdlp commented 1 month ago

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.

m-soltani commented 1 month ago

Thank you. I will try pulling new image tags to see the pull works as expected.

ahojman commented 2 weeks ago

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!!

conilas commented 2 weeks ago

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.

JXavierMSFT commented 2 weeks ago

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.

luisdlp commented 2 weeks ago

We've fixed this issue. ETA for getting the fix deployed to all regions is 11/15.

m-soltani commented 2 weeks ago

We've fixed this issue. ETA for getting the fix deployed to all regions is 11/15.

thanks for the update!