You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: corporate CA trust for pipeline git-clone from internal hosts
Add support for the git-clone task to trust corporate/internal CA
certificates when cloning from private Git servers (e.g. GitLab behind
a corporate CA).
Supply-chain chart:
- Add conditional ssl-ca-directory workspace to pipeline and
pipelinerun templates (gated by git.sslCABundle.enabled)
- Add git.sslCABundle values (enabled, configMapName) defaulting to
the ztvp-trusted-ca ConfigMap
- Set CRT_FILENAME param so git-clone finds the CA bundle file
ztvp-certificates chart:
- Auto-detect internal Git hosts via customCA.remoteHosts: the
extraction Job connects to the host on port 443, extracts the full
CA chain from the TLS handshake, and merges it into the bundle
- Distribute ztvp-trusted-ca to the pipeline namespace via the
targetNamespaces list
Generator (gen-feature-variants.py):
- Auto-enable git.sslCABundle and customCA.remoteHosts when --git-repo
points to a non-public host (not github.com/gitlab.com/bitbucket.org)
- Add git.sslCABundle.enabled to the protected-repos feature fragment
and to the commented-out overrides in the base values-hub.yaml
values-hub.yaml:
- Replace hand-edited file with gen-feature-variants output for
consistent indentation and complete feature composition
Documentation:
- Add "Corporate CA trust for internal Git hosts" section to
docs/supply-chain.md covering enablement, auto-extraction, and
manual CA provisioning alternatives
Signed-off-by: Min Zhang <minzhang@redhat.com>
Copy file name to clipboardExpand all lines: docs/supply-chain.md
+66Lines changed: 66 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -323,6 +323,41 @@ spec:
323
323
- name: registry-auth-config
324
324
secret:
325
325
secretName: qtodo-registry-auth
326
+
- name: git-auth
327
+
secret:
328
+
secretName: qtodo-git-credentials
329
+
# Add this workspace when git.sslCABundle.enabled is true (internal Git hosts):
330
+
# - name: ssl-ca-directory
331
+
# configMap:
332
+
# name: ztvp-trusted-ca
333
+
```
334
+
335
+
**SSH mode** (leave `git-auth` unbound):
336
+
337
+
```yaml
338
+
apiVersion: tekton.dev/v1
339
+
kind: PipelineRun
340
+
metadata:
341
+
generateName: qtodo-manual-run-
342
+
namespace: layered-zero-trust-hub
343
+
spec:
344
+
pipelineRef:
345
+
name: qtodo-supply-chain
346
+
taskRunTemplate:
347
+
serviceAccountName: pipeline
348
+
timeouts:
349
+
pipeline: 1h0m0s
350
+
workspaces:
351
+
- name: qtodo-source
352
+
persistentVolumeClaim:
353
+
claimName: qtodo-workspace-source
354
+
- name: registry-auth-config
355
+
secret:
356
+
secretName: qtodo-registry-auth
357
+
# Add this workspace when git.sslCABundle.enabled is true (internal Git hosts):
358
+
# - name: ssl-ca-directory
359
+
# configMap:
360
+
# name: ztvp-trusted-ca
326
361
```
327
362
328
363
As was described previously, verify the values associated with the PVC storage and registry configuration.
@@ -463,6 +498,36 @@ When using the generator with `--git-repo`, the `qtodo.repository` override is s
463
498
value: "https://github.com/your-org/qtodo.git" # or SSH URL (git@github.com:your-org/qtodo.git)
464
499
```
465
500
501
+
#### 4. Corporate CA trust for internal Git hosts (HTTPS only)
502
+
503
+
When the private repository is hosted on an internal Git server (e.g. GitLab behind a corporate CA), the `git-clone` task will fail with `SSL certificate problem: self-signed certificate in certificate chain` because the pod does not trust the corporate CA.
504
+
505
+
The `ztvp-certificates` chart already extracts and distributes the cluster's CA bundle (ingress, service, and any custom/corporate CAs). When the `supply-chain` feature is enabled, the `ztvp-trusted-ca` ConfigMap is automatically distributed to the pipeline namespace (`layered-zero-trust-hub`) via ACM policy.
506
+
507
+
To make the `git-clone` task use this CA bundle, enable the SSL CA bundle mount:
508
+
509
+
```yaml
510
+
- name: git.sslCABundle.enabled
511
+
value: "true"
512
+
```
513
+
514
+
This binds the `ztvp-trusted-ca` ConfigMap as the `ssl-ca-directory` workspace on the `git-clone` task and sets the `CRT_FILENAME` parameter to `tls-ca-bundle.pem` (matching the key in the ConfigMap). The upstream `git-clone` ClusterTask uses this file to set `GIT_SSL_CAPATH`, so TLS verification succeeds against internal Git servers.
515
+
516
+
The corporate CA must be included in the `ztvp-trusted-ca` bundle. The easiest way is to use **automatic remote host extraction** -- add the Git host to `customCA.remoteHosts` in the `ztvp-certificates` overrides:
517
+
518
+
```yaml
519
+
# ztvp-certificates overrides in values-hub.yaml
520
+
- name: customCA.remoteHosts[0]
521
+
value: "gitlab.internal.example.com"
522
+
```
523
+
524
+
The `ztvp-certificates` extraction Job will connect to the host on port 443, extract the full CA chain from the TLS handshake (no authentication needed), and merge it into the CA bundle. The CronJob keeps it fresh automatically.
525
+
526
+
Alternatively, you can provide the CA certificate manually via `customCA.secretRef` or `customCA.additionalCertificates`. See the [ztvp-certificates documentation](./ztvp-certificates.md) for details.
527
+
528
+
> [!NOTE]
529
+
> This setting is only needed for HTTPS clones from internal Git hosts whose TLS certificates are signed by a corporate or self-signed CA. Public Git hosts (github.com, gitlab.com) use publicly trusted certificates and do not require this.
530
+
466
531
#### How it works
467
532
468
533
When `git.credentials.enabled` is `true`:
@@ -475,6 +540,7 @@ When `git.credentials.enabled` is `true`:
475
540
* **HTTPS mode**: the `git-auth` workspace **must** be bound to the `qtodo-git-credentials` secret. ServiceAccount-level credential injection alone is not sufficient -- without an explicit workspace binding, the `git-clone` ClusterTask cannot access the protected repository.
476
541
* **SSH mode**: the `git-auth` workspace must be left **unbound**. SSH credentials are injected automatically via the ServiceAccount. Binding the workspace triggers the `git-clone` ClusterTask's `prepare.sh`, which runs a recursive `chmod` on the copied secret volume; this fails on the read-only Kubernetes projected volume symlinks and aborts the step.
477
542
* The Vault policy `hub-supply-chain-jwt-secret` grants read access to `secret/data/hub/supply-chain/*` for the pipeline's SPIFFE identity.
543
+
* When `git.sslCABundle.enabled` is `true`, the pipeline mounts the `ztvp-trusted-ca` ConfigMap as the `ssl-ca-directory` workspace and sets `CRT_FILENAME` to `tls-ca-bundle.pem`. The `git-clone` ClusterTask uses this file to configure `GIT_SSL_CAPATH` so HTTPS clones trust the corporate CA. The CA bundle is populated automatically when `customCA.remoteHosts` is configured in the `ztvp-certificates` overrides -- the extraction Job fetches the CA chain from each host via TLS handshake (no authentication needed).
0 commit comments