search

voyagermesh / voyager

🚀 Secure L7/L4 (HAProxy) Ingress Controller for Kubernetes
https://voyagermesh.com
Apache License 2.0
1.35k stars 134 forks source link

Issues with custom templates #1439

Open ssro opened 4 years ago

ssro commented 4 years ago

Hi everyone,

I'm having an issue updating voyager when using custom templates. I've created a global.cfg custom template on which I disable TLSv1.1, applied it and install/update voyager. The steps are as follows:

$ kubectl create configmap -n kube-system voyager-templates --from-file=global.cfg
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/v11.0.1/hack/deploy/voyager.sh     | bash -s -- --provider=$provider --template-cfgmap=voyager-templates --run-on-master

The output of installing/updating voyager hangs and in the end it's timing out:

...output truncated...

waiting until voyager operator deployment is ready
waiting until voyager apiservice is available
waiting until voyager crds are ready
checking whether admission webhook(s) are activated or not
timed out waiting for the condition

However, if I pass --enable-validating-webhook=false voyager gets deployed with no issues

Another issue is if I want to update an ingress resource i get the following error: Internal error occurred: failed calling webhook "admission.voyager.appscode.com": the server is currently unable to handle the request

It seems related with https://github.com/appscode/voyager/issues/1203 because if I run kubectl delete validatingwebhookconfiguration admission.voyager.appscode.com, I can update ingress resources.

Also, on voyager-operator I see a lot of tls errors like the one below:

http: TLS handshake error from 100.99.0.0:39152: remote error: tls: bad certificate

My global.cfg contents:

global
    daemon
    stats socket /var/run/haproxy.sock level admin expose-fd listeners
    server-state-file global
    server-state-base /var/state/haproxy/
    {{ if .MaxConnections }}maxconn {{ .MaxConnections }}{{ end }}
    # log using a syslog socket
    log /dev/log local0 info
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-server-options ssl-min-ver TLSv1.2 no-tls-tickets
    lua-load /etc/auth-request.lua
    hard-stop-after {{ .HardStopAfter }}

Kubernetes 1.14.6 deployed with kops on aws

IllanFed commented 4 years ago

Same issue with custom config(defaults.cfg).

Workaround(pass --enable-validating-webhook=false) also works.