feat(RELEASE-2158): Support self-hosted Quay

[querti]

Verify Conforma task should support images that are in a self-hosted Quay instance. This instance has a self-signed CA cert which is implicitly not trusted by 3rd party tools. This can be fixed by mounting the CA bundle to /etc/ssl/certs/, making it trusted. Mount to /mnt/trusted-ca is added to be consistent with other tasks in the pipeline.

[querti]

This PR adds the cert to other tasks in the push-to-external-registry pipeline: konflux-ci/release-service-catalog#2031

[qodo-code-review]

Review Summary by Qodo

Support self-hosted Quay with trusted CA certificates

✨ Enhancement

Walkthroughs

Description

• Add trusted CA certificate mounting for self-hosted Quay support
• Mount CA bundle to both /mnt/trusted-ca and /etc/ssl/certs/ca-custom-bundle.crt
• Enable Verify Conforma task to work with self-signed certificates

Diagram

flowchart LR
  A["Verify Conforma Task"] -- "mounts CA bundle" --> B["Trusted CA Volume"]
  B -- "maps to /mnt/trusted-ca" --> C["CA Bundle Location 1"]
  B -- "maps to /etc/ssl/certs/ca-custom-bundle.crt" --> D["CA Bundle Location 2"]
  C --> E["Self-hosted Quay Support"]
  D --> E

Loading

File Changes

1. tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml ✨ Enhancement +7/-0

Add CA certificate mounts for self-hosted Quay

• Added trusted-ca volume mount at /mnt/trusted-ca for consistency with other pipeline tasks
• Added trusted-ca volume mount at /etc/ssl/certs/ca-custom-bundle.crt for system-wide CA trust
• Both mounts are read-only and reference the same ca-bundle.crt subPath
• Enables task to work with self-signed certificates from self-hosted Quay instances

tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. CA mount not consumed 🐞 Bug ✓ Correctness

Description

The new stepTemplate mounts the CA bundle into /etc/ssl/certs and /mnt/trusted-ca, but the task does
not set any SSL_CERT_* env for the early use-trusted-artifact step, and the repo’s existing pattern
mounts the bundle under /etc/pki/tls/certs. As a result, the build-trusted-artifacts step may still
fail to trust a self-hosted Quay CA, so the PR may not achieve its stated goal.

Code

tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[R227-233]

+      - name: trusted-ca
+        mountPath: /mnt/trusted-ca
+        readOnly: true
+      - name: trusted-ca
+        mountPath: /etc/ssl/certs/ca-custom-bundle.crt
+        subPath: ca-bundle.crt
+        readOnly: true

Evidence

The PR adds trusted-ca mounts into the stepTemplate at /mnt/trusted-ca and
/etc/ssl/certs/ca-custom-bundle.crt. The step that needs to reach the registry early is
use-trusted-artifact (build-trusted-artifacts image), but the only SSL trust configuration in this
Task is scoped to the later validate step (SSL_CERT_DIR env), and even that step mounts the CA
into /etc/pki/tls/certs (not /etc/ssl/certs). Other tasks in this repo also consistently mount
custom CA under /etc/pki/tls/certs, suggesting /etc/ssl/certs may not be the expected location here.

tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[223-233]
tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[250-257]
tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[348-362]
tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[373-377]
tasks/verify-enterprise-contract/0.1/verify-enterprise-contract.yaml[302-306]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The task now mounts the trusted CA bundle into `/etc/ssl/certs/ca-custom-bundle.crt` and `/mnt/trusted-ca` for all steps, but the step most likely to need it first (`use-trusted-artifact` using the build-trusted-artifacts image) has no explicit SSL trust env configuration. Additionally, the repo’s existing convention mounts custom CA under `/etc/pki/tls/certs/ca-custom-bundle.crt`.

### Issue Context
- `validate` already sets `SSL_CERT_DIR` and mounts CA under `/etc/pki/tls/certs/...`, but earlier steps (notably `use-trusted-artifact`) may still fail against self-hosted Quay.
- The PR’s new mount path `/etc/ssl/certs/...` is inconsistent with other tasks.

### Fix Focus Areas
- tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[223-240]
- tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[250-257]
- tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[348-377]

### Concrete changes to implement
1. Add a stepTemplate env `SSL_CERT_DIR` (or another explicit mechanism your tooling actually honors) so `use-trusted-artifact` can trust the CA. If setting `SSL_CERT_DIR` at stepTemplate level, preserve Tekton’s required defaults as done in `validate` (include `/tekton-custom-certs:/etc/ssl/certs:/etc/pki/tls/certs:/system/etc/security/cacerts` plus any additional paths).
2. Consider also mounting the same CA bundle into `/etc/pki/tls/certs/ca-custom-bundle.crt` in the stepTemplate (matching existing tasks) so both common trust locations are covered consistently across images.
3. Optionally update README to document `/mnt/trusted-ca` usage if it is part of the contract.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. VSA task not updated 🐞 Bug ⛯ Reliability

Description

The PR only updates verify-conforma-konflux-ta; the verify-conforma-konflux-vsa-ta variant still
runs build-trusted-artifacts without mounting trusted-ca in its stepTemplate. If the registry CA
problem affects trusted artifact retrieval (same pattern), pipelines using the VSA task may still
fail against self-hosted Quay.

Code

tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[R227-233]

+      - name: trusted-ca
+        mountPath: /mnt/trusted-ca
+        readOnly: true
+      - name: trusted-ca
+        mountPath: /etc/ssl/certs/ca-custom-bundle.crt
+        subPath: ca-bundle.crt
+        readOnly: true

Evidence

The PR adds trusted-ca mounts to the verify-conforma-konflux-ta stepTemplate, but the VSA variant’s
stepTemplate still mounts only workdir while also using the same build-trusted-artifacts image for
use-trusted-artifact. This indicates the self-hosted Quay CA support is not consistently applied
across closely related tasks in the repo.

tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[223-233]
tasks/verify-conforma-konflux-vsa-ta/0.1/verify-conforma-konflux-vsa-ta.yaml[208-218]
tasks/verify-conforma-konflux-vsa-ta/0.1/verify-conforma-konflux-vsa-ta.yaml[222-229]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Self-hosted Quay support appears to be implemented only for `verify-conforma-konflux-ta`, but the VSA variant `verify-conforma-konflux-vsa-ta` still runs the `use-trusted-artifact` step without mounting the `trusted-ca` ConfigMap (and without equivalent trust configuration).

### Issue Context
Both tasks use the same `quay.io/redhat-appstudio/build-trusted-artifacts:...` image for `use-trusted-artifact`, so if that step needs the custom CA to talk to a self-hosted registry, the VSA variant likely needs the same setup.

### Fix Focus Areas
- tasks/verify-conforma-konflux-vsa-ta/0.1/verify-conforma-konflux-vsa-ta.yaml[208-229]
- tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml[223-233]

### Concrete changes to implement
1. Mirror the `trusted-ca` volumeMounts (and any required SSL trust env settings) from `verify-conforma-konflux-ta` into the `stepTemplate` of `verify-conforma-konflux-vsa-ta`.
2. Ensure the mount paths and env are consistent with the conventions used elsewhere in the repo (notably `/etc/pki/tls/certs/ca-custom-bundle.crt` if that remains the standard).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[querti]

@simonbaird @joejstuart @st3penta can I request a review? Thanks!