Replies: 4 comments 9 replies
-
|
Yes, it should be. If you're terminating TLS at the load balancer level and Teleport doesn't need a certificate, set proxy_service:
acme:
enabled: falseTeleport will generate and use a self-signed certificate for communications from LB -> Teleport. You may need to configure the LB not to validate the backend certificate for targets. |
Beta Was this translation helpful? Give feedback.
-
|
Would an LB(https) -> teleport connection work with the self-signed certificate? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, as long as the LB either does or can be told to skip validation on the Teleport HTTPS cert. Usually this is documented behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
One more question @webvictim, according to this guide: https://goteleport.com/docs/architecture/tls-routing/#how-it-works Do we need to set the port here to 443 as well? |
Beta Was this translation helpful? Give feedback.
-
|
No, you don't need to set That guide should probably be updated to mention that it's not needed when using the Helm chart - I'll take a look at that. |
Beta Was this translation helpful? Give feedback.
-
|
@webvictim The HTTPS healthcheck wasn't working for me so I decided to hit /healthz instead. It succeded and I was able to access the Web UI. I tested Teleport Agent fails to join the cluster as well. |
Beta Was this translation helpful? Give feedback.
-
|
I have some notes on this. I currently have an ingress configured like this: I configure a custom backend to ensure the health check is configured correctly. The issue I have ran in to is GCP adding both the Client IP and Load Balancer IP to the 'X-Forwared-For' header described here https://cloud.google.com/load-balancing/docs/https#x-forwarded-for_header. It seems Teleport cant parse multiple X-Forwarded-For IPs. It would be great if we could specifcy which IP to use within the header. |
Beta Was this translation helpful? Give feedback.
-
|
@jamesagarside Did the teleport Web UI and subsequent |
Beta Was this translation helpful? Give feedback.
-
|
I've gotten around this by disabling |
Beta Was this translation helpful? Give feedback.
-
|
No, all requests with multiple X-Forwarded-For IPs are rejected as documented here: https://goteleport.com/docs/reference/config/#proxy-service |
Beta Was this translation helpful? Give feedback.
-
|
I managed to switch from default ingress to ClusterIP, GCP Global LB (L7) with these values : ingress:
enabled: true
proxyListenerMode: "multiplex"
acme: false
proxy:
teleportConfig:
proxy_service:
trust_x_forwarded_for: false
annotations:
ingress:
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
ingress:
spec:
ingressClassName: nginx-lb-l7
service:
type: ClusterIP
proxyListenerMode: multiplex |
Beta Was this translation helpful? Give feedback.
-
|
@webvictim hello, I Deploy the V16 on GKE, but got errors, please help. I use Gateway and httproute, the yaml file below: and after deployed, got the error: |
Beta Was this translation helpful? Give feedback.
-
|
You'll probably need to configure the HTTP route to use HTTPS communication with the backend - Teleport's proxy service expects HTTPS traffic. Also, the pods themselves listen on port 3080 but the Service (ClusterIP) listens on 443. I don't know enough about HTTP routes to say where it's sending the traffic, but try port 3080 if it's communicating directly with the Pod rather than the Service. |
Beta Was this translation helpful? Give feedback.
-
With reference to this guide, is GCP Application LB supported when running teleport behind it?
https://goteleport.com/docs/architecture/tls-routing/#working-with-layer-7-load-balancers-or-reverse-proxies-preview
Resources used:
Application LB (with ManagedCertificate) -> teleport
Note that teleport is not running with any certifcates.
Same error as above.
Beta Was this translation helpful? Give feedback.
All reactions