Explore No-Credentials "Authentication" For Blocking Misbehaving Clients

[BenTheElder]

Unfortunately the OCI Distribution spec doesn't talk much about auth, however it's relatively common to require obtaining an auth token even for public read registries that don't otherwise require credentials from the client. Roughly: Clients ping /v2/, receive 401, and fetch a token scoped to the image, which is used in subsequent API calls within a pull. Tokens don't cross redirects.

We could phase in some relatively cheap token handler just to make it easier to reject poorly behaved clients automatically.

E.G. perhaps we could simply encrypt the image scope and current time with a key common to all instances and require a valid and sufficiently recently signed value in order to make API calls.

I'm not sure this is a good idea yet, but we've been getting a ton of /v2/$image/list? calls for images we don't host,from an Artifactory client that does not appear to every hit /v2/ or other APIs (it does request various /.jfrog/....) which had me thinking:

• we could try to reach out to the user
• we could configure cloud armor to block this misconfigured instance

.... but none of those scale to the next N instances, and we don't want people regularly poking around the logs anyhow. I'm only looking at our logs currently as part of monitoring https://kubernetes.io/blog/2023/03/10/image-registry-redirect/

NOTE: This needs to wait until after the Code Freeze #181 , but going ahead and filing this so we're tracking.

cc @jonjohnsonjr

/sig k8s-infra
/kind feature

[ameukam]

/milestone v1.28
/priority backlog

[BenTheElder]

To clarify: we currently never require an auth token of any sort, which is unusual and limiting for future direction, but supported. See the request handling doc.

[BenTheElder]

... And all major clients handle the no-credentials auth workflow, it's required for most major registries. GCR/AR are seemingly unusual in permitting public read with truly no auth if configured for public read (and registry.k8s.io currently). cc @jonjohnsonjr 🙏

GCR/AR under normal usage serve 401 at /v2/ and have a token request.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[BenTheElder]

cc @sftim per prior conversation: if we combined this (pseudo-auth at the root of image download request) + only allow signed URLs to backing hosts we could put ourselves more in control of rate limits / spam blocking.

will file another issue for signed-urls

[sftim]

We'd certainly have more visibility over requests if we do that.

[BenTheElder]

We block a lot of nonsense now by way of the WAF only accepting requests with valid API paths.

We could switch to signed URLs without doing this change, but doing this change would also make it slightly more straightforward to track pulls.

On balance, I don't think this is worthwhile. However we should consider #278 or #194