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
If the WEBHOOK_SECRET_NAME env var isn't set on the webhook container, it should listen on plain HTTP, with no TLS.
Actual Behavior
If the WEBHOOK_SECRET_NAME env var isn't set, a default value of webhook-certs is used instead. If that secret does not exist, it'll error out. As a result, there's no way to have the webhook controller serve plain HTTP.
Steps to Reproduce the Problem
Delete the webhook-certs secret
Remove the WEBHOOK_SECRET_NAME env var from the tekton-pipelines-webhook deployment.
Change the WEBHOOK_PORT env var in the tekton-pipelines-webhook deployment to something other than 8443, like 8088 (8080 is already in use), just for clarity. =)
Change the https-webhook in ports in the tekton-pipelines-webhook deployment to http-webhook, with the value set to the same port you used in the WEBHOOK_PORT env var above.
In the tekton-pipelines-webhook service, add a new entry in ports with name set to http-webhook, port set to 80, and targetPort set to http-webhook.
This part requires that you have some sort of TLS termination setup - we've got an internal system that does this via a sidecar, and I don't have enough familiarity with, say, how you would do this with Istio, but the end result should be that the TLS setup should serve on 443 (with the https-webhooktargetPort in the tekton-pipelines-webhook service changed from https-webhook to whatever port your TLS terminator is serving on), in front of the WEBHOOK_PORT you specified above. This is because admission controller webhook services have to be on https on port 443.
Now that everything's set up, an attempt to create a new Tekton resource should fail because port 8088 or whatever isn't actually open on the webhook container.
Additional Info
Tekton Pipeline version:
Tested directly on v0.45.0 and the latest release, v0.61.1.
We're trying to switch from the k8s secret webhook-certs for TLS to instead using our internal TLS proxying tooling, and that, well, does not work. The reason for this is
- if WEBHOOK_SECRET_NAME is empty, it is defaulted to webhook-certs, rather than leaving it empty, and the Knative webhook tooling will always serve on TLS, trying to use that secret.
The text was updated successfully, but these errors were encountered:
This would retain the current behavior in any case where the WEBHOOK_SECRET_NAME env var isn't present at all, but would let a user explicitly set WEBHOOK_SECRET_NAME to "" in order to just serve HTTP without TLS.
Expected Behavior
If the
WEBHOOK_SECRET_NAME
env var isn't set on the webhook container, it should listen on plain HTTP, with no TLS.Actual Behavior
If the
WEBHOOK_SECRET_NAME
env var isn't set, a default value ofwebhook-certs
is used instead. If that secret does not exist, it'll error out. As a result, there's no way to have the webhook controller serve plain HTTP.Steps to Reproduce the Problem
webhook-certs
secretWEBHOOK_SECRET_NAME
env var from thetekton-pipelines-webhook
deployment.WEBHOOK_PORT
env var in thetekton-pipelines-webhook
deployment to something other than8443
, like8088
(8080
is already in use), just for clarity. =)https-webhook
inports
in thetekton-pipelines-webhook
deployment tohttp-webhook
, with the value set to the same port you used in theWEBHOOK_PORT
env var above.tekton-pipelines-webhook
service, add a new entry inports
withname
set tohttp-webhook
,port
set to80
, andtargetPort
set tohttp-webhook
.443
(with thehttps-webhook
targetPort
in thetekton-pipelines-webhook
service changed fromhttps-webhook
to whatever port your TLS terminator is serving on), in front of theWEBHOOK_PORT
you specified above. This is because admission controller webhook services have to be on https on port 443.Additional Info
Tested directly on v0.45.0 and the latest release, v0.61.1.
We're trying to switch from the k8s secret
webhook-certs
for TLS to instead using our internal TLS proxying tooling, and that, well, does not work. The reason for this ispipeline/cmd/webhook/main.go
Lines 238 to 241 in 95fbf31
WEBHOOK_SECRET_NAME
is empty, it is defaulted towebhook-certs
, rather than leaving it empty, and the Knative webhook tooling will always serve on TLS, trying to use that secret.The text was updated successfully, but these errors were encountered: