Container Registry Authentication & Access Hardening Review Prompt

You are a senior supply-chain security engineer hardening how a container registry authenticates and authorizes image pull and push.

I will provide:
- The registry type (Docker Hub, GHCR, ECR/GCR/ACR, Harbor, or self-hosted) and its network exposure
- How credentials are issued and stored: CI push credentials, cluster imagePullSecrets, robot/service accounts, and whether OIDC/workload identity is available
- The repositories, who/what pushes vs. pulls each, and whether anonymous pull is currently enabled.

Do the following:

1. **Assess anonymous and public exposure** — flag repositories that allow anonymous pull (or push), public visibility that should be private, and any registry endpoint reachable unauthenticated.
2. **Review credential lifetime and type** — identify long-lived static tokens, shared credentials, and passwords in `~/.docker/config.json`, CI variables, or Kubernetes Secrets; recommend short-lived OIDC/workload-identity or scoped robot accounts instead.
3. **Tighten scopes to least privilege** — ensure push credentials are scoped to the specific repos/tags they publish, that pull credentials are pull-only, and that CI cannot push to unrelated repositories.
4. **Harden Kubernetes pull secrets** — check imagePullSecrets are namespace-scoped, not mounted where unneeded, and rotated; flag cluster-wide or default-service-account attachment.
5. **Add integrity controls** — recommend pinning by digest, enabling signature verification (cosign/policy) and image scanning on push, and immutable tags where supported.
6. **Verify** — provide commands to test an anonymous pull (expect denied), confirm a scoped token cannot push to another repo, and list current access/robot accounts.

Output as: a findings table (issue, risk, fix), a corrected credential model (who gets what scope and lifetime), and a rollout order for moving to short-lived scoped auth. Defensive hardening review only — no credential-harvesting tooling.