ImagePolicy filterTags: ^latest$ reports Ready success — silent auto-update footgun

[RaviTharuma]

Describe the bug / problem (footgun)

An ImagePolicy that only matches the floating tag latest reports Ready=True forever and looks like healthy image automation — while effectively tracking a moving digest under a fixed tag name. Operators can believe auto-update is “working” when the policy will never select a new tag; it only ever “updates” if digest reflection moves under latest.

Concrete policy shape observed (generic):

• filterTags pattern: ^latest$
• policy / extract: alphabetical (only one candidate)
• digestReflectionPolicy: Always
• Status: Ready=True, latest tag literally latest + digest

That succeeds as automation UX: green conditions, ImageUpdateAutomation may report repository up-to-date or occasionally rewrite digests — but there is no signal that the filter only matches a floating channel tag (latest / similarly stable / current).

Why this hurts

• Dashboards show ImagePolicy Ready → “image automation is fine.”
• Semver-oriented mental model (“we auto-update when new versions appear”) does not apply; nothing will ever leave latest.
• Digest-always reflection can still rewrite Git with digest changes under the same tag, which may or may not be what the operator intended — either way, Ready success does not warn about floating-tag tracking.

Steps to reproduce

1. Create an ImageRepository that scans an image publishing a latest tag (any public image is enough).
2. Create an ImagePolicy:

# illustrative shape only
spec:
  imageRepositoryRef:
    name: example
  filterTags:
    pattern: '^latest$'
  policy:
    alphabetical:
      order: asc
  digestReflectionPolicy: Always

3. Observe Ready=True with selected tag latest and a digest.
4. Publish new version tags that are not latest — policy does not move.
5. Only digest changes under latest (if any) affect reflection — still Ready, still tag name latest.

Expected behavior

Surface the footgun explicitly:

1. Warning condition (or Ready with degraded secondary condition) when the effective filter only matches known floating tags such as latest / stable / current, e.g. reason=FloatingTag, message explaining that tag selection will not advance across versions.
2. Docs callout under ImagePolicy / image automation: filterTags that only match floating tags are not version auto-update; prefer semver filters or explicit version patterns.

If maintainers prefer docs-only, this can live on fluxcd/website — but a status reason is harder to ignore than a paragraph operators never open.

Environment

• Kubernetes: single-node (generic)
• Flux CLI: v2.9.4
• Distribution: flux-v2.9.1
• image-reflector-controller: v1.2.3
• image-automation-controller: v1.2.3 (ImageUpdateAutomation Ready, “repository up-to-date”)
• One ImagePolicy of the ^latest$ + alphabetical + Always digest shape as above

Non-goals

• Not naming a specific application image.
• Not claiming digest reflection under latest is always wrong — only that silent Ready success hides the floating-tag semantics.

Code of Conduct

• I agree to follow this project's Code of Conduct