How does a Flux ImageRepository authenticate to a private container registry, and what changes when that registry belongs to a cloud provider such as Amazon ECR?

## Who is actually authenticating The first thing to get straight is that this credential belongs to **image-reflector-controller**, running in the cluster and talking to the registry's HTTP API to list tags. It is not the kubelet pulling an image. That distinction explains a recurring surprise: a workload that pulls fine using an `imagePullSecrets` entry can sit next to an ImageRepository that cannot scan at all, because nothing shares that secret with the controller. They are two different clients with two different credentials, and both must be configured. It also shapes the least-privilege answer. The scanner never needs push rights and never needs to pull layers; read access sufficient to list tags is the whole requirement, and the credential should be scoped that narrowly. ## Option one: a static secret ```yaml apiVersion: image.toolkit.fluxcd.io/v1beta2 kind: ImageRepository metadata: name: app namespace: flux-system spec: image: ghcr.io/org/app interval: 5m secretRef: name: registry-creds ``` The referenced secret is an ordinary `kubernetes.io/dockerconfigjson`, the kind `kubectl create secret docker-registry` produces. It must live in the same namespace as the ImageRepository. This is the right answer for a registry that issues long-lived robot accounts — a self-hosted registry, or a token-based account on a public registry. The cost is the usual one for static credentials: it sits in the cluster, it must be rotated, and rotating it is a change nobody remembers to schedule. If it is committed to Git it needs sealing or encryption like any other secret. ## Option two: contextual cloud login Cloud registries mostly do not issue long-lived credentials at all. Amazon ECR hands out an authorisation token valid for about twelve hours; Azure and Google have their own short-lived token flows. Storing one in a secret means it stops working the same day, which is why the older Flux pattern involved a CronJob that re-ran the cloud CLI every few hours and rewrote the secret — a moving part that fails quietly at 3 a.m. `spec.provider` removes it: ```yaml spec: image: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/app interval: 5m provider: aws ``` The controller now authenticates using the identity it already has on the platform — the workload identity or instance role attached to it — and refreshes tokens on its own. There is no registry credential in the cluster to leak or rotate, and access is granted by cloud IAM policy, where it is auditable alongside everything else. The prerequisite is that the controller actually has such an identity: on a self-managed cluster off-platform, contextual login has nothing to bind to and a static secret is still the answer. ## Transport details Two smaller fields exist for awkward registries. `spec.certSecretRef` supplies a CA certificate for a registry serving a certificate your cluster does not trust, which is common for internal registries with a private PKI. `spec.insecure` allows plain HTTP; it disables transport security for that scan, which means credentials and responses cross the network in the clear, so it belongs in a lab and nowhere else. ## Failure signature An authentication problem surfaces on the ImageRepository object itself: a ready condition of false with the registry's error, visible from `flux get image repository`. What makes it worth recognising is the downstream effect. The ImagePolicy keeps ranking the tag list from the last successful scan and keeps reporting a perfectly plausible selected image; the automation keeps running and finds nothing to change. So the system looks healthy everywhere except one object, while quietly serving results from an increasingly stale cache. When someone says a new tag was never picked up, the scanner's own condition is the first thing to read. ## Scoping the blast radius Because the credential is per-ImageRepository through `secretRef`, you can give different teams' scanners different credentials in different namespaces rather than one cluster-wide registry account. With contextual login the equivalent control lives in IAM. Either way the goal is the same: a scanner credential that can list tags on the repositories that team owns and nothing else.