feat(tls): inject centrally managed TLS config into pipelines webhook

[jkhelil]

The tekton-pipelines-webhook managed its own TLS configuration locally, preventing Post-Quantum Cryptography (PQC) readiness. Changes to the cluster's APIServer TLS profile had no effect on the webhook.

Solution

Wire the OpenShift APIServer TLS security profile into the webhook deployment via environment variables (WEBHOOK_TLS_MIN_VERSION, WEBHOOK_TLS_CIPHER_SUITES, WEBHOOK_TLS_CURVE_PREFERENCES), and ensure any future profile changes automatically re-reconcile the webhook.

Changes:

openshift/tektonpipeline/extension.go — resolve TLS profile in PreReconcile, inject it via Transformers into the tekton-pipelines-webhook Deployment
openshift/tektonconfig/controller.go — watch APIServer resource; on TLS profile change, re-enqueue TektonConfig
openshift/tektonconfig/extension.go — GetPlatformData() returns a SHA-256 hash of the resolved TLS profile
shared/tektonconfig/tektonconfig.go — stamp the hash as operator.tekton.dev/platform-data-hash on the TektonPipeline CR
shared/tektonconfig/pipeline/pipeline.go — propagate the annotation during CR updates
kubernetes/tektoninstallerset/client/ — include PlatformDataHashKey in the InstallerSet spec hash so manifest re-application is triggered when the TLS profile changes
Feature is opt-in via TektonConfig.spec.platforms.openShift.enableCentralTLSConfig

Evidence

Enabling the feature injects the cluster's TLS profile into the webhook:

$ oc patch tektonconfig config --type=merge \
    -p '{"spec":{"platforms":{"openShift":{"enableCentralTLSConfig":true}}}}'
$ oc get deploy tekton-pipelines-webhook -n openshift-pipelines \
    -o jsonpath='{range .spec.template.spec.containers[0].env[*]}{.name}={.value}{"\n"}{end}' | grep TLS_
TLS_CIPHER_SUITES=TLS_AES_128_GCM_SHA256,...,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_MIN_VERSION=1.2

Changing the APIServer TLS profile automatically updates the webhook (no operator restart):

# Restrict to 3 ciphers
$ oc patch apiserver cluster --type=merge -p '{
  "spec":{"tlsSecurityProfile":{"type":"Custom","custom":{
    "ciphers":["ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256","ECDHE-RSA-AES256-GCM-SHA384"],
    "minTLSVersion":"VersionTLS12"
  }}}}'
# Operator log:
# "APIServer TLS security profile changed, triggering TektonConfig reconciliation"
# PlatformDataHashKey updated:  d96e4890 → 89c859ef
$ oc get deploy tekton-pipelines-webhook -n openshift-pipelines \
    -o jsonpath='{range .spec.template.spec.containers[0].env[*]}{.name}={.value}{"\n"}{end}' | grep TLS_
TLS_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_MIN_VERSION=1.2
# Restore default → webhook reverts automatically, hash returns to d96e4890

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Run make test lint before submitting a PR
• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

Release Notes

The tekton-pipelines-webhook now inherits TLS configuration (minimum version and cipher suites) from the OpenShift cluster's APIServer TLS security profile when enableCentralTLSConfig is set in TektonConfig. Changes to the cluster TLS profile are automatically propagated to the webhook without operator restarts, enabling PQC readiness (SRVKP-9614).

[jkhelil]

/kind feature

[anithapriyanatarajan]

@jkhelil - The env vars for weebhook are different from the ones expected for Results api.

The PR injects TLS_MIN_VERSION and TLS_CIPHER_SUITES into the tekton-pipelines-webhook deployment. However, the tekton-pipelines-webhook binary uses the Knative webhook framework (https://github.com/tektoncd/operator/blob/main/vendor/knative.dev/pkg/webhook/webhook.go#L193) which reads WEBHOOK_TLS_MIN_VERSION and WEBHOOK_TLS_CIPHER_SUITES (with WEBHOOK_ prefix).

Verified the effect of of injecting the correct variable with following steps:

Step 1: Applied this PR changes to openshift cluster and verified the default propagation

$ oc get deploy tekton-pipelines-webhook -n openshift-pipelines -o yaml 

Step 2: Port forwarded and attempted to make a client connection to webhook service

$ oc port-forward -n openshift-pipelines svc/tekton-pipelines-webhook 18443:443 &
$ openssl s_client -connect localhost:18443 -tls1_2

Connection errored:

Step 3: kill the port forward, reduce the deployment replica to 0 so that tektonconfig does not override the env var manually set to deployment and set the new var WEBHOOK_TLS_MIN_VERSION

$ pkill -f "port-forward.*tekton-pipelines-webhook"
$ oc scale deploy openshift-pipelines-operator -n openshift-operators --replicas=0
$ oc patch deploy tekton-pipelines-webhook -n openshift-pipelines --type=json -p='[
  {"op":"add","path":"/spec/template/spec/containers/0/env/-",
   "value":{"name":"WEBHOOK_TLS_MIN_VERSION","value":"1.2"}}]'
$ oc rollout status deploy/tekton-pipelines-webhook -n openshift-pipelines

Step 4: Port forwarded agains and attempted to make a client connection to webhook service (repeated step 2)

$ oc port-forward -n openshift-pipelines svc/tekton-pipelines-webhook 18443:443 &
$ openssl s_client -connect localhost:18443 -tls1_2

Handshake successful.

[anithapriyanatarajan]

webhook's env vars are prefixed with WEBHOOK_. please consider having a prefix based extension for this.

[jkhelil]

fixed now

echo "=== 1. WEBHOOK DEPLOYMENT ENV VARS (spec) ===" && oc get deployment tekton-pipelines-webhook -n openshift-pipelines -o jsonpath='{.spec.template.spec.containers[?(@.name=="webhook")].env}' | python3 -m json.tool 2>/dev/null
=== 1. WEBHOOK DEPLOYMENT ENV VARS (spec) ===
[
    {
        "name": "CONFIG_FEATURE_FLAGS_NAME",
        "value": "feature-flags"
    },
    {
        "name": "CONFIG_LEADERELECTION_NAME",
        "value": "config-leader-election-webhook"
    },
    {
        "name": "CONFIG_LOGGING_NAME",
        "value": "config-logging"
    },
    {
        "name": "CONFIG_OBSERVABILITY_NAME",
        "value": "config-observability"
    },
    {
        "name": "KUBERNETES_MIN_VERSION",
        "value": "v1.0.0"
    },
    {
        "name": "METRICS_DOMAIN",
        "value": "tekton.dev/pipeline"
    },
    {
        "name": "PROBES_PORT",
        "value": "8080"
    },
    {
        "name": "SSL_CERT_DIR",
        "value": "/tekton-custom-certs:/etc/ssl/certs:/etc/pki/tls/certs"
    },
    {
        "name": "SYSTEM_NAMESPACE",
        "valueFrom": {
            "fieldRef": {
                "apiVersion": "v1",
                "fieldPath": "metadata.namespace"
            }
        }
    },
    {
        "name": "WEBHOOK_ADMISSION_CONTROLLER_NAME",
        "value": "webhook.pipeline.tekton.dev"
    },
    {
        "name": "WEBHOOK_PORT",
        "value": "8443"
    },
    {
        "name": "WEBHOOK_SECRET_NAME",
        "value": "webhook-certs"
    },
    {
        "name": "WEBHOOK_SERVICE_NAME",
        "value": "tekton-pipelines-webhook"
    },
    {
        "name": "WEBHOOK_TLS_CIPHER_SUITES",
        "value": "TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
    },
    {
        "name": "WEBHOOK_TLS_MIN_VERSION",
        "value": "1.2"
    }
]

echo "=== 2. TLS 1.2 CHECK (Intermediate profile) ===" && echo | openssl s_client -connect 127.0.0.1:18443 -tls1_2 -brief 2>&1 | grep -E "Protocol|Cipher|CONNECTED|ERROR|alert"
=== 2. TLS 1.2 CHECK (Intermediate profile) ===
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-AES128-GCM-SHA256

[anithapriyanatarajan]

Thanks @jkhelil. tls 1_2 and 1_3 are correctly accepted and 1_1 is rejected on a Openshift cluster with default profile. Could not evaluate for propagation by patching a hosted cluster. With the core feature working, proceeding to approve.

[anithapriyanatarajan]

/lgtm

[anithapriyanatarajan]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anithapriyanatarajan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [anithapriyanatarajan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment