image-controller: push robot account granted pull-only access when Component is recreated #421

Summary

When a Konflux Component is deleted and recreated (e.g. to pick up a new SCM secret), the image-controller provisions new Quay robot accounts for the resulting ImageRepository resources but only grants them read (pull) access instead of read+write (push+pull). This causes all subsequent pipeline runs to fail at the clone-repository task (and any other task that pushes OCI trusted artifacts to Quay) with an authorization error.

Environment

• Konflux cluster: RHTAP production (stone-prod)
• Pipeline type: docker-build-oci-ta (OCI Trusted Artifacts)

Reproduction

1. Have one or more existing Konflux Component resources with working pipelines (push robot accounts correctly granted write access to their Quay repositories).
2. Delete and recreate those Component resources (e.g. to update the SCM secret referenced by their Repository resources).
3. Observe that new ImageRepository resources are created with status.state: ready and new push robot account names populated in status.credentials.push-robot-account.
4. Trigger a pipeline run (e.g. open a pull request).
5. The clone-repository task fails with:

   Error response from registry: unauthorized: access to the requested resource is not authorized: map[]
   warning: Command failed and will retry, 1 try
   error: Unauthorized error, wrong registry credentials provided, won't retry
   

Expected Behavior

The push robot account provisioned for an ImageRepository should be granted write (push+pull) access to the corresponding Quay repository, regardless of whether the Component/ImageRepository is being created for the first time or recreated.

Actual Behavior

The newly provisioned push robot account is only granted read (pull) access on Quay. Requesting a Quay auth token scoped for push,pull on the repository returns a JWT with only ["pull"] in the access[].actions field:

{
  "access": [
    {
      "type": "repository",
      "name": "redhat-user-workloads/<tenant>/<component>",
      "actions": ["pull"]
    }
  ]
}

The ImageRepository status reports state: ready despite the robot account lacking push access, so there is no signal that anything is wrong until a pipeline run fails.

Additionally, annotating the ImageRepository with image-controller.appstudio.redhat.com/image-credentials-generation-timestamp to force re-reconciliation did not fix the permissions — the controller re-ran but still did not grant push access to the existing robot account.

Workaround

Deleting the ImageRepository CRs causes the image-controller to fully re-provision them from scratch, this time correctly granting push+pull to the new robot accounts. Since ImageRepository resources are owned by their Component, this does not require deleting the Component again.

# Run for each affected component
oc delete imagerepository <component-name> -n <tenant-namespace>
# The Component controller recreates the ImageRepository automatically within ~60-90 seconds

Additional Context

• The Quay repositories themselves and any previously pushed images were unaffected — only the robot account permissions were wrong.
• The issue was reproduced on two independent prod clusters, suggesting it is not environment-specific.
• The *-image-push secrets in the namespace were updated with the new robot account credentials immediately after component recreation, but those credentials only had pull access on Quay from the start.
• The trigger for component recreation was updating the SCM (pipelines-as-code) secret referenced by the Repository resources — not a Konflux version upgrade or platform change.