Skip to content

fix: use registry.access.redhat.com for Azure workload images - #141

Merged
butler54 merged 1 commit into
validatedpatterns:mainfrom
butler54:fix/azure-workload-images-registry-access-redhat-com
Sep 1, 2026
Merged

fix: use registry.access.redhat.com for Azure workload images#141
butler54 merged 1 commit into
validatedpatterns:mainfrom
butler54:fix/azure-workload-images-registry-access-redhat-com

Conversation

@butler54

@butler54 butler54 commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

Problem

The three Azure workload charts (hello-openshift, kbs-access-curl, kbs-access-sealed) all default to registry.redhat.io/ubi9/httpd-24@sha256:..., which requires registry authentication. On Azure, these run as peer-pods (kata-remote) where the image is pulled via guest-pull inside the confidential VM rather than by the host container runtime — getting a working pull secret threaded through that path has been an ongoing source of image-pull failures.

Fix

Override image for these three Applications in values-azure.yaml to the same digest served from registry.access.redhat.com instead, which doesn't require authentication:

registry.access.redhat.com/ubi9/httpd-24@sha256:68a91ff691092f455fea682330c499588747231c16516cd4f35aff821e6847f2

Verified this resolves to the identical manifest (same Docker-Content-Digest) as the registry.redhat.io reference, unauthenticated:

$ curl -sI "https://registry.access.redhat.com/v2/ubi9/httpd-24/manifests/sha256:68a91ff691092f455fea682330c499588747231c16516cd4f35aff821e6847f2"
HTTP/1.1 200 OK
Docker-Content-Digest: sha256:68a91ff691092f455fea682330c499588747231c16516cd4f35aff821e6847f2

This mirrors existing precedent in the repo: kbs-access-curl's initImage already uses registry.access.redhat.com/ubi9/ubi:latest for the same reason (charts/coco-supported/kbs-access-curl/values.yaml:5).

Scope

Connected Azure (values-azure.yaml) only, per request. Baremetal (values-baremetal.yaml) and Azure spoke/mirror topologies are unchanged.

hello-openshift, kbs-access-curl, and kbs-access-sealed all default to
registry.redhat.io/ubi9/httpd-24, which requires authentication.
Peer-pods (kata-remote) CVMs on Azure pull images via guest-pull inside
the guest, and threading a working registry.redhat.io pull secret
through that path has been an ongoing source of failures.

Override the image to the same digest served from
registry.access.redhat.com instead (verified: same
sha256:68a91ff691092f455fea682330c499588747231c16516cd4f35aff821e6847f2
manifest digest, no authentication required). kbs-access-curl's
initImage already uses registry.access.redhat.com for the same reason.

Connected Azure (values-azure.yaml) only -- baremetal and the Azure
spoke/mirror topologies are unchanged.
@butler54
butler54 requested a review from a team September 1, 2026 14:28
@butler54
butler54 merged commit 8c2aa7e into validatedpatterns:main Sep 1, 2026
5 checks passed
@butler54
butler54 deleted the fix/azure-workload-images-registry-access-redhat-com branch September 1, 2026 14:28
@butler54
butler54 restored the fix/azure-workload-images-registry-access-redhat-com branch September 1, 2026 14:29
@butler54
butler54 deleted the fix/azure-workload-images-registry-access-redhat-com branch September 1, 2026 14:30
butler54 added a commit that referenced this pull request Sep 2, 2026
…kbs-access-sealed (#144)

* Revert "fix: use registry.access.redhat.com for Azure workload images (#141)"

This reverts commit 8c2aa7e.

* fix: kbs-access-sealed uses debug-initdata, matching kbs-access-curl

kbs-access-curl already mounts the debug-initdata ConfigMap (both the
coco.io/initdata-configmap annotation and the initdata volume). Switch
kbs-access-sealed to the same debug-initdata ConfigMap for consistency
between the two kbs-access test workloads.

Both initdata and debug-initdata are generated by the same
init-data-gzipper.yaml playbook, and the RVPS init_data reference value
already includes both variants' hashes (see rvps-values-policies.yaml's
init_data entry: pcr8Hash, debugPcr8Hash, rawHash, debugRawHash), so this
does not affect attestation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant