fix(RELEASE-2383): update trusted-ca volume mount to custom directory#2133
fix(RELEASE-2383): update trusted-ca volume mount to custom directory#2133jinqi7 wants to merge 1 commit intokonflux-ci:developmentfrom
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
jinqi7
force-pushed
the
ta_custom_cert
branch
2 times, most recently
from
ee59654 to
1e75216
Compare
|
/retest |
PR Reviewer Guide 🔍(Review updated until commit 952f1e2)Here are some key observations to aid the review process:
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt |
There was a problem hiding this comment.
Suggestion: Add readOnly: true to the trusted-ca volume mount to explicitly prevent writes. [general, importance: 4]
New proposed code:
- name: trusted-ca
mountPath: /etc/ssl/certs/ca-custom-bundle.crt
subPath: ca-bundle.crt
+ readOnly: true| | caTrustConfigMapName | The name of the ConfigMap to read CA bundle data from | Yes | trusted-ca | | ||
| | caTrustConfigMapKey | The name of the key in the ConfigMap that contains the CA bundle data | Yes | ca-bundle.crt | | ||
| | addImplicitTimestampTag | When "true", for each repository the resolved {{ timestamp }} value is added to the list of tags after translation (deduplicated). Fails if timestamp is empty. Only pipelines referencing the check-labels task should set this to "true" | Yes | false | | ||
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | |
There was a problem hiding this comment.
Suggestion: Add a short note explaining why the CA bundle default moved to /mnt/trusted-ca (and any compatibility expectations), since this is a behavioral/environment assumption that may surprise task consumers. [organization best practice, importance: 6]
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| **Note:** The trusted CA bundle is mounted as a directory at `/mnt/trusted-ca` (containing `ca-bundle.crt`) to avoid mounting over system certificate paths; consumers should use `$(params.caCertPath)` when configuring TLS verification. |
jinqi7
changed the title
| type: string | ||
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | ||
| default: /etc/pki/tls/certs/ca-bundle.crt | ||
| default: /mnt/trusted-ca/ca-bundle.crt |
There was a problem hiding this comment.
/ask is it enough to just mount the ca bundle to this location or we should do do something in addition so the script in this task will use it. Same questions for the changes for the other tasks.
There was a problem hiding this comment.
Just mounting the bundle at /mnt/trusted-ca/ca-bundle.crt is only enough if the task’s script/commands actually reference that path (directly or via the caCertPath param). Changing the param default alone doesn’t automatically make tools use it.
What to verify/update in this task (and similarly in the other tasks):
-
Does the script/command use
$(params.caCertPath)?- If the script currently hardcodes
/etc/pki/tls/certs/ca-bundle.crt, it will keep using the old path and your mount + default change won’t help. - If it already uses
$(params.caCertPath)(e.g., passes it into a CLI flag), then the default change is sufficient.
- If the script currently hardcodes
-
Does the underlying tool/library automatically pick up a custom CA path?
- Many tools do not automatically look at “some file mounted somewhere”. They need either:
- an explicit flag (preferred), e.g.
--cacert $(params.caCertPath)(curl),--certificate-authority=$(params.caCertPath)(some CLIs), etc. - or a well-known environment variable, e.g.:
SSL_CERT_FILE=$(params.caCertPath)(common OpenSSL consumers)REQUESTS_CA_BUNDLE=$(params.caCertPath)(Pythonrequests)GIT_SSL_CAINFO=$(params.caCertPath)(git)
- an explicit flag (preferred), e.g.
- If the task uses Java, Node, etc., those often require their own configuration (truststore /
NODE_EXTRA_CA_CERTS, etc.).
- Many tools do not automatically look at “some file mounted somewhere”. They need either:
-
Ensure the mount matches the new default
- The Task/TaskRun needs a volume mount that actually places the bundle at
/mnt/trusted-ca/ca-bundle.crt(or places a directory at/mnt/trusted-cacontainingca-bundle.crt). - Also confirm file permissions allow the task container user to read it.
- The Task/TaskRun needs a volume mount that actually places the bundle at
So: No, the param default change is not automatically enough by itself. It’s enough only when the task implementation is wired to use $(params.caCertPath) (or appropriate env vars/flags). You should perform the same check for the other tasks: search for /etc/pki/tls/certs/ca-bundle.crt hardcoding and ensure each task either uses the param in its command or exports an env var that the used tooling respects.
There was a problem hiding this comment.
The PR is focus on the custom ca being used in trusted-artifact stepactions and in these stepactions, the environment variable CA_FILE is set with the value of caCertPath (for example here). Then it will be passed to https://github.com/konflux-ci/build-trusted-artifacts/blob/main/oras_opts.sh.
There was a problem hiding this comment.
The PR is focus on the custom ca being used in trusted-artifact stepactions and in these stepactions, the environment variable CA_FILE is set with the value of caCertPath (for example here). Then it will be passed to https://github.com/konflux-ci/build-trusted-artifacts/blob/main/oras_opts.sh.
@jinqi7 can you please include this explanation in the commit message? it's not clear right now that this PR is only for the support of custom ca bundle for the trusted-artifacts stepaction.
There was a problem hiding this comment.
Yes. Updated the commit message.
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true | ||
| - name: trusted-ca |
There was a problem hiding this comment.
why do we still have this mount?
There was a problem hiding this comment.
The mount makes the volume can be accessed by the steps (use-trusted-artifact/ create-trusted-artifact) of the tasks.
| @@ -91,8 +91,7 @@ spec: | |||
| - mountPath: /var/workdir | |||
| name: workdir | |||
| - name: trusted-ca | |||
There was a problem hiding this comment.
/ask what is the reason we need two mounts for the trusted-ca?
There was a problem hiding this comment.
We typically end up with two mounts for trusted-ca when the same CA bundle needs to be visible in two different filesystem locations inside the container:
- Legacy / OS trust-store path: some images/tools expect the CA bundle in a “standard” location (e.g.,
/etc/pki/ca-trust/...,/etc/ssl/certs, etc.). If the container (orupdate-ca-trust/update-ca-certificates) relies on that path, you need a mount there. - Application-specific/custom path: other components (or our own scripts) may be hardcoded/configured to read CAs from a custom directory (what this PR title suggests). To support that without breaking existing behavior, we mount the same volume again at the custom location.
In Kubernetes, that’s done by mounting the same volume (name: trusted-ca) multiple times with different mountPaths (often with subPath), so the container sees the same underlying content in both places.
If both mounts are still present after this change, it’s worth double-checking:
- whether both consumers still exist (OS-level + app-level), and
- whether one can be removed by standardizing on a single path (preferred long-term), assuming nothing in the image/tooling expects the old location.
There was a problem hiding this comment.
The one with "/mnt/trusted-ca" as mount point is used by my PR. The other one is added by RELEASE-2158. We may need eventually merge them into one? But it's no conflict to have two from our testing.
There was a problem hiding this comment.
I'm a bit confused. This pr mentions a ticket about making the trusted ca bundle optional. In order to do it, the mount that uses a subpath should be removed.
There was a problem hiding this comment.
The mount of trusted-ca to "/etc/pki/tls/certs/ca-bundle.crt" can't work well when the configmap doesn't exist. But we still need mount the configmap in another way so that the stepactions can access it.
| - name: caCertPath | ||
| type: string | ||
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | ||
| default: /etc/pki/tls/certs/ca-bundle.crt | ||
| default: /mnt/trusted-ca/ca-bundle.crt |
There was a problem hiding this comment.
Suggestion: Revert the default caCertPath to the original system path (/etc/pki/tls/certs/ca-bundle.crt) to prevent potential TLS failures when the optional trusted-ca ConfigMap is not available. [possible issue, importance: 8]
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /etc/pki/tls/certs/ca-bundle.crt | |
| default: /mnt/trusted-ca/ca-bundle.crt | |
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /etc/pki/tls/certs/ca-bundle.crt |
| type: string | ||
| description: The name of the key in the ConfigMap that contains the CA bundle data | ||
| default: ca-bundle.crt |
There was a problem hiding this comment.
Suggestion: Re-add the removed caCertPath parameter to the task definition to maintain backward compatibility and prevent validation errors for existing pipelines that may still use it. [possible issue, importance: 6]
New proposed code:
- name: caTrustConfigMapKey
type: string
description: The name of the key in the ConfigMap that contains the CA bundle data
default: ca-bundle.crt
+- name: caCertPath
+ type: string
+ description: Path to CA certificate bundle for TLS verification with self-signed certificates
+ default: /mnt/trusted-ca/ca-bundle.crt
| stepTemplate: | ||
| volumeMounts: | ||
| - name: trusted-ca | ||
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| readOnly: true | ||
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true |
There was a problem hiding this comment.
Suggestion: Restore the caCertPath parameter and the volume mount for the CA bundle in verify-access-to-resources.yaml to maintain consistency with other tasks and prevent potential TLS failures. [possible issue, importance: 8]
New proposed code:
+params:
+ - name: caCertPath
+ type: string
+ description: Path to CA certificate bundle for TLS verification with self-signed certificates
+ default: /mnt/trusted-ca/ca-bundle.crt
volumes:
- name: trusted-ca
configMap:
name: $(params.caTrustConfigMapName)
items:
- key: $(params.caTrustConfigMapKey)
path: ca-bundle.crt
optional: true
stepTemplate:
volumeMounts:
- 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| | caTrustConfigMapName | The name of the ConfigMap to read CA bundle data from | Yes | trusted-ca | | ||
| | caTrustConfigMapKey | The name of the key in the ConfigMap that contains the CA bundle data | Yes | ca-bundle.crt | | ||
| | addImplicitTimestampTag | When "true", for each repository the resolved {{ timestamp }} value is added to the list of tags after translation (deduplicated). Fails if timestamp is empty. Only pipelines referencing the check-labels task should set this to "true" | Yes | false | | ||
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | |
There was a problem hiding this comment.
Suggestion: Add a short note near the parameters table explaining why the default CA bundle path moved to /mnt/trusted-ca/ca-bundle.crt (directory mount) and call out that any consumers relying on the old /etc/pki/... path must update. [organization best practice, importance: 5]
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| **Note:** The trusted CA bundle is now mounted as a directory at `/mnt/trusted-ca` (default bundle path: `/mnt/trusted-ca/ca-bundle.crt`) instead of being mounted directly at `/etc/pki/tls/certs/ca-bundle.crt`. Pipelines or scripts that referenced the old path must be updated to use `caCertPath`. |
| stepTemplate: | ||
| volumeMounts: | ||
| - name: trusted-ca | ||
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| readOnly: true | ||
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true | ||
| securityContext: | ||
| runAsUser: 1001 |
There was a problem hiding this comment.
Suggestion: Restore the caCertPath parameter and the volume mount for the CA bundle to /etc/ssl/certs/ca-custom-bundle.crt in verify-access-to-resources.yaml to maintain consistency and prevent potential TLS errors. [possible issue, importance: 9]
| stepTemplate: | |
| volumeMounts: | |
| - name: trusted-ca | |
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | |
| subPath: ca-bundle.crt | |
| readOnly: true | |
| - name: trusted-ca | |
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | |
| subPath: ca-bundle.crt | |
| mountPath: /mnt/trusted-ca | |
| readOnly: true | |
| securityContext: | |
| runAsUser: 1001 | |
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /mnt/trusted-ca/ca-bundle.crt | |
| ... | |
| stepTemplate: | |
| volumeMounts: | |
| - 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 | |
| securityContext: | |
| runAsUser: 1001 |
| value: $(params.dataDir) | ||
| - name: sourceDataArtifact | ||
| value: $(params.sourceDataArtifact) | ||
| - name: orasOptions | ||
| value: $(params.orasOptions) | ||
| - name: caCertPath | ||
| value: $(params.caCertPath) |
There was a problem hiding this comment.
Suggestion: Verify that the use-trusted-artifact StepAction defines orasOptions and caCertPath parameters to prevent runtime errors when they are passed from the collect-tpa-params task. [possible issue, importance: 6]
New proposed code:
-- name: use-trusted-artifact
- ...
- params:
- - name: workDir
- value: $(params.dataDir)
- - name: sourceDataArtifact
- value: $(params.sourceDataArtifact)
- - name: orasOptions
- value: $(params.orasOptions)
- - name: caCertPath
- value: $(params.caCertPath)
+| spec: | ||
| description: >- | ||
| This stepaction extracts a Trusted Artifact into a folder. | ||
| image: quay.io/konflux-ci/build-trusted-artifacts:653578444c73afc32b3a865fee9869a09f96c1a2 | ||
| image: quay.io/konflux-ci/build-trusted-artifacts:8b09217702ec665d4fae6d09f6a7910421f15b69 |
There was a problem hiding this comment.
Suggestion: Pin the container image quay.io/konflux-ci/build-trusted-artifacts to its digest (@sha256:...) instead of a mutable tag to improve security and ensure reproducible builds. [security, importance: 7]
| spec: | |
| description: >- | |
| This stepaction extracts a Trusted Artifact into a folder. | |
| image: quay.io/konflux-ci/build-trusted-artifacts:653578444c73afc32b3a865fee9869a09f96c1a2 | |
| image: quay.io/konflux-ci/build-trusted-artifacts:8b09217702ec665d4fae6d09f6a7910421f15b69 | |
| spec: | |
| description: >- | |
| This stepaction extracts a Trusted Artifact into a folder. | |
| image: quay.io/konflux-ci/build-trusted-artifacts@sha256:<insert_resolved_digest> |
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca |
There was a problem hiding this comment.
I noticed here we remove the other trusted-ca volume mount, but in the other places we don't, is this correct?
There was a problem hiding this comment.
In fact, that volume mount is not needed in the task. In some other tasks, it's needed. So, I removed it here.
| stepTemplate: | ||
| volumeMounts: | ||
| - name: trusted-ca | ||
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| readOnly: true | ||
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true |
There was a problem hiding this comment.
Suggestion: Restore the caCertPath parameter and the /etc/ssl/certs/ca-custom-bundle.crt volume mount in verify-access-to-resources.yaml to maintain consistency with other tasks in the PR. [possible issue, importance: 7]
| stepTemplate: | |
| volumeMounts: | |
| - name: trusted-ca | |
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | |
| subPath: ca-bundle.crt | |
| readOnly: true | |
| - name: trusted-ca | |
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | |
| subPath: ca-bundle.crt | |
| mountPath: /mnt/trusted-ca | |
| readOnly: true | |
| - name: caTrustConfigMapKey | |
| type: string | |
| description: The name of the key in the ConfigMap that contains the CA bundle data | |
| default: ca-bundle.crt | |
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /mnt/trusted-ca/ca-bundle.crt | |
| volumes: | |
| - name: trusted-ca | |
| configMap: | |
| name: $(params.caTrustConfigMapName) | |
| items: | |
| - key: $(params.caTrustConfigMapKey) | |
| path: ca-bundle.crt | |
| optional: true | |
| stepTemplate: | |
| volumeMounts: | |
| - 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 |
| | caTrustConfigMapName | The name of the ConfigMap to read CA bundle data from | Yes | trusted-ca | | ||
| | caTrustConfigMapKey | The name of the key in the ConfigMap that contains the CA bundle data | Yes | ca-bundle.crt | | ||
| | addImplicitTimestampTag | When "true", for each repository the resolved {{ timestamp }} value is added to the list of tags after translation (deduplicated). Fails if timestamp is empty. Only pipelines referencing the check-labels task should set this to "true" | Yes | false | | ||
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | |
There was a problem hiding this comment.
Suggestion: Add a brief note explaining that the trusted-ca ConfigMap is now mounted as a directory at /mnt/trusted-ca (and why), so users understand the new default and how to override it. [organization best practice, importance: 6]
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| **CA bundle note:** the `trusted-ca` ConfigMap is mounted at `/mnt/trusted-ca`, so the default CA bundle path is `/mnt/trusted-ca/ca-bundle.crt` (override `caCertPath` if your pipeline mounts a different location). |
|
/retest |
1 similar comment
|
/retest |
| - name: caCertPath | ||
| type: string | ||
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | ||
| default: /etc/pki/tls/certs/ca-bundle.crt | ||
| default: /mnt/trusted-ca/ca-bundle.crt |
There was a problem hiding this comment.
Suggestion: Revert the default caCertPath to a system path, such as /etc/ssl/certs/ca-bundle.crt, to prevent failures when the optional trusted-ca ConfigMap is not provided. [possible issue, importance: 8]
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /etc/pki/tls/certs/ca-bundle.crt | |
| default: /mnt/trusted-ca/ca-bundle.crt | |
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /etc/ssl/certs/ca-bundle.crt |
| stepTemplate: | ||
| volumeMounts: | ||
| - name: trusted-ca | ||
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| readOnly: true | ||
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true |
There was a problem hiding this comment.
Suggestion: Restore the caCertPath parameter and the compatibility volume mount for trusted-ca to /etc/ssl/certs/ca-custom-bundle.crt to ensure custom CA functionality is not broken. [possible issue, importance: 9]
| stepTemplate: | |
| volumeMounts: | |
| - name: trusted-ca | |
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | |
| subPath: ca-bundle.crt | |
| readOnly: true | |
| - name: trusted-ca | |
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | |
| subPath: ca-bundle.crt | |
| mountPath: /mnt/trusted-ca | |
| readOnly: true | |
| - name: caCertPath | |
| type: string | |
| description: Path to CA certificate bundle for TLS verification with self-signed certificates | |
| default: /mnt/trusted-ca/ca-bundle.crt | |
| ... | |
| stepTemplate: | |
| volumeMounts: | |
| - 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 |
| - 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 |
There was a problem hiding this comment.
Suggestion: Remove the volumeMount that uses subPath on the optional trusted-ca volume. This prevents potential pod startup failures when the corresponding ConfigMap is absent. [possible issue, importance: 8]
New proposed code:
volumeMounts:
- mountPath: /var/workdir
name: workdir
- 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| stepTemplate: | ||
| volumeMounts: | ||
| - name: trusted-ca | ||
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| readOnly: true | ||
| - name: trusted-ca | ||
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | ||
| subPath: ca-bundle.crt | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true | ||
| securityContext: | ||
| runAsUser: 1001 |
There was a problem hiding this comment.
Suggestion: Add an environment variable like SSL_CERT_FILE to the stepTemplate. This will point tools to the custom CA bundle, preventing TLS failures in environments that require it. [possible issue, importance: 8]
| stepTemplate: | |
| volumeMounts: | |
| - name: trusted-ca | |
| mountPath: /etc/pki/tls/certs/ca-bundle.crt | |
| subPath: ca-bundle.crt | |
| readOnly: true | |
| - name: trusted-ca | |
| mountPath: /etc/ssl/certs/ca-custom-bundle.crt | |
| subPath: ca-bundle.crt | |
| mountPath: /mnt/trusted-ca | |
| readOnly: true | |
| securityContext: | |
| runAsUser: 1001 | |
| stepTemplate: | |
| volumeMounts: | |
| - name: trusted-ca | |
| mountPath: /mnt/trusted-ca | |
| readOnly: true | |
| env: | |
| - name: SSL_CERT_FILE | |
| value: /mnt/trusted-ca/ca-bundle.crt | |
| securityContext: | |
| runAsUser: 1001 |
| | caTrustConfigMapName | The name of the ConfigMap to read CA bundle data from | Yes | trusted-ca | | ||
| | caTrustConfigMapKey | The name of the key in the ConfigMap that contains the CA bundle data | Yes | ca-bundle.crt | | ||
| | addImplicitTimestampTag | When "true", for each repository the resolved {{ timestamp }} value is added to the list of tags after translation (deduplicated). Fails if timestamp is empty. Only pipelines referencing the check-labels task should set this to "true" | Yes | false | | ||
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | |
There was a problem hiding this comment.
Suggestion: Add a short note clarifying that the trusted-ca ConfigMap is now mounted as a directory at /mnt/trusted-ca and that caCertPath should point to /mnt/trusted-ca/ca-bundle.crt to reduce confusion for users migrating from the previous file mount. [organization best practice, importance: 6]
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| | caCertPath | Path to CA certificate bundle for TLS verification with self-signed certificates | Yes | /mnt/trusted-ca/ca-bundle.crt | | |
| **Note:** The `trusted-ca` ConfigMap is mounted at `/mnt/trusted-ca` (directory mount). Set `caCertPath` to `/mnt/trusted-ca/ca-bundle.crt` (or override it) when using a custom CA bundle. |
elenagerman
force-pushed
the
ta_custom_cert
branch
from
952f1e2 to
0227271
Compare
The PR is focus on the custom ca being used in trusted-artifact stepactions and in these stepactions, the environment variable CA_FILE is set with the value of caCertPath (for example here). Then it will be passed to oras_opts.sh in https://github.com/konflux-ci/build-trusted-artifacts repo. It changes trusted-ca ConfigMap mount to use a custom directory to prevent conflicts with system certificate paths. The ConfigMap is now mounted back to: /mnt/trusted-ca (directory mount) And the caCertPath parameter default is updated to: /mnt/trusted-ca/ca-bundle.crt The PR also removed the unnecessary volume mount in verify-access-to-resources task. It also update to new build-trusted-artifacts image reference in stepactions. Signed-off-by: Jing Qi Assisted-By: Claude
elenagerman
force-pushed
the
ta_custom_cert
branch
from
0227271 to
60493a4
Compare
|
Sorry, I have to open a new one to have full control over the code: |
4 participants
The PR is focus on the custom ca being used in trusted-artifact
stepactions and in these stepactions, the environment variable
CA_FILE is set with the value of caCertPath (for example here).
Then it will be passed to oras_opts.sh in
https://github.com/konflux-ci/build-trusted-artifacts repo.
The ConfigMap is now mounted back to /mnt/trusted-ca (directory mount)
And the caCertPath parameter default is updated to: /mnt/trusted-ca/ca-bundle.crt
Signed-off-by: Jing Qi
Assisted-By: Claude
Related PR: konflux-ci/mobster#361
Describe your changes
Relevant Jira
Checklist before requesting a review
do not mergelabel if there's a dependency PRrelease-service-maintainershandle if you are unsure who to tagSigned-off-by: My name <email>.github/scripts/readme_generator.shand verified the results using.github/scripts/check_readme.sh