feat(RELEASE-2177): ta stepactions support for self-signed certificate

[jinqi7]

Signed-off-by: Jing Qi jinqi@redhat.com

It's needed for push-to-external-registry pipeline to support self-signed
certificate in trusted artifact stepactions.

Related PR: konflux-ci/release-service-catalog#2133

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.54%. Comparing base (6b19c10) to head (f96e4d6).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #361   +/-   ##
=======================================
  Coverage   95.54%   95.54%           
=======================================
  Files          57       57           
  Lines        3863     3863           
=======================================
  Hits         3691     3691           
  Misses        172      172           

Flag	Coverage Δ
unit-tests	95.54% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[qodo-code-review]

Review Summary by Qodo

Add self-signed certificate support to trusted artifact stepactions

✨ Enhancement

Walkthroughs

Description

• Add self-signed certificate support to trusted artifact stepactions
• Introduce ConfigMap-based CA bundle configuration parameters
• Mount CA certificates to standard system paths for validation
• Pass CA certificate path to create-trusted-artifact step

Diagram

flowchart LR
  A["ConfigMap Parameters"] -->|"caTrustConfigMapName, caTrustConfigMapKey"| B["Volume Mount Configuration"]
  B -->|"Mount to /etc/pki/tls/certs/custom-ca"| C["CA Certificate Access"]
  C -->|"Pass caCertPath parameter"| D["create-trusted-artifact Step"]

Loading

File Changes

1. tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml ✨ Enhancement +24/-0

Add CA certificate configuration and mounting support

• Added two new parameters caTrustConfigMapName and caTrustConfigMapKey to configure CA bundle
 source
• Created trusted-ca volume from ConfigMap with optional flag for flexibility
• Mounted CA certificate to two standard system paths for SSL/TLS validation
• Passed CA certificate path to the create-trusted-artifact step invocation

tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml

---

[qodo-code-review]

Code Review by Qodo

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

1. Optional subPath mount fails 🐞 Bug ☼ Reliability

Description

The task marks the trusted-ca ConfigMap volume as optional but also mounts a file from it using
subPath; if the ConfigMap (or the referenced key) is absent, Kubernetes cannot resolve the subPath
and the step containers may fail to start. This breaks the task in clusters where the trusted-ca
ConfigMap is not present (despite optional: true).

Code

tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[R185-203]

+    - name: trusted-ca
+      configMap:
+        name: $(params.caTrustConfigMapName)
+        items:
+          - key: $(params.caTrustConfigMapKey)
+            path: ca-bundle.crt
+        optional: true

  stepTemplate:
    volumeMounts:
      - mountPath: /var/workdir
        name: workdir
+      - name: trusted-ca
+        mountPath: /etc/pki/tls/certs/custom-ca
+        readOnly: true
+      - name: trusted-ca
+        mountPath: /etc/ssl/certs/ca-custom-bundle.crt
+        subPath: ca-bundle.crt
+        readOnly: true

Evidence

The volume is explicitly optional, but a later volumeMount uses subPath: ca-bundle.crt, which
requires that file to exist inside the volume; if the ConfigMap/key is missing, the file won’t exist
and the mount can fail at container start.

tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[174-203]
Best Practice: Kubernetes volumeMounts subPath behavior

Agent prompt

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

### Issue description
`trusted-ca` is declared with `optional: true`, but the task also mounts `/etc/ssl/certs/ca-custom-bundle.crt` using `subPath: ca-bundle.crt`. When the ConfigMap (or that key) is missing, the file does not exist in the volume, and Kubernetes can fail to start the container due to an unresolved subPath.

### Issue Context
The task intends CA injection to be optional, but the subPath mount defeats that intent by making pod startup dependent on the presence of the file.

### Fix Focus Areas
- tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[185-203]

### Suggested fix approaches (pick one)
1. **Simplest:** remove the `/etc/ssl/certs/ca-custom-bundle.crt` mount that uses `subPath`, keep only the directory mount at `/etc/pki/tls/certs/custom-ca`.
2. If you truly need a fixed file path, don’t use an optional ConfigMap volume directly with `subPath`; instead, introduce an `emptyDir` + init step that conditionally copies the CA bundle when present (so the file always exists before the main steps start), then mount the `emptyDir` file without relying on missing ConfigMap content.

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

---

2. README missing new params 🐞 Bug ⚙ Maintainability

Description

The task adds caTrustConfigMapName and caTrustConfigMapKey parameters but the versioned README
does not document them. This makes the new CA configuration undiscoverable for users relying on the
task README for configuration.

Code

tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[R160-167]

+    - name: caTrustConfigMapName
+      type: string
+      description: The name of the ConfigMap to read CA bundle data from
+      default: trusted-ca
+    - name: caTrustConfigMapKey
+      type: string
+      description: The name of the key in the ConfigMap that contains the CA bundle data
+      default: ca-bundle.crt

Evidence

The YAML introduces two new params, but the 0.3 README parameter table does not include these names,
defaults, or descriptions.

tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[160-167]
tasks/augment-component-sboms-ta/0.3/README.md[5-30]

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 YAML adds `caTrustConfigMapName` and `caTrustConfigMapKey`, but `tasks/augment-component-sboms-ta/0.3/README.md` does not list them in the Parameters table.

### Issue Context
This task is versioned and the README is used as the primary configuration reference. Missing parameter documentation makes the new self-signed CA feature hard to use.

### Fix Focus Areas
- tasks/augment-component-sboms-ta/0.3/augment-component-sboms-ta.yaml[160-167]
- tasks/augment-component-sboms-ta/0.3/README.md[5-30]

### Suggested fix
Add two rows to the README Parameters table documenting:
- `caTrustConfigMapName` (default `trusted-ca`)
- `caTrustConfigMapKey` (default `ca-bundle.crt`)
Use the same descriptions as in the YAML.

ⓘ 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

[BorekZnovustvoritel]

This may replace #360 if it's ready.

However in the current state, the task won't work as the CA bundle is just mounted to the Mobster pod but not used. See this issue.

We can either merge this as-is (without deploying the change to release-service-catalog) or we can try to update the container's CA bundle in script like so:

ca_bundle=/mnt/trusted-ca/ca-bundle.crt
if [ -f "$ca_bundle" ]; then
  echo "[$(date --utc -Ins)] Using mounted CA bundle: $ca_bundle"
  cp -vf $ca_bundle /etc/pki/ca-trust/source/anchors/custom-bundle.crt  # changed name not to cause conflicts
  update-ca-trust
fi

(This snippet has been modified from buildah-oci-ta.yaml in build-definitions). Let us know if the mounting mechanism is final so we can work on top of these changes if that's the case.

[BorekZnovustvoritel]

Closing in favor of #363