Trying to enable TLS port on ambassador using helm chart's service.annotations option. However it is either turning into incorrect config (where tls context is attached to cleartext port) or trying to bind 80 and 443 ports.
I've ambassador as a sub chart to my main chart. And I've defined values for this subchart as follows -
ambassador:
replicaCount: 1
service:
annotations: {"getambassador.io/config": "---\napiVersion: ambassador/v1\nkind: Module\nname: tls\nconfig:\n server:\n enabled: true\n secret: ambassador-certs\n redirect_cleartext_from: 8080\n"}
This results in binding the listener to port 443 always ignoring the actual tls target port (8443).
requirements.yaml look like this
dependencies:
- name: ambassador
version: 2.0.*
repository: "#stable"
Checking the logs reveal that the listener is being created on port 443 and fails as it is not being run as root. If I keep both ambassador and tls modules, then the tls context is always attached to port 8080 and making it a tls port. /ambassador/envoy/envoy.json has always one listener (8080). The chart being is used is ambassador-2.0.2. Any idea why this behavior?
This issue addressed as part of the helm chart 2.5.x. Upgrading the dependencies to 2.5.* resolved this issue.
Related
I'm implementing a Frontend Loadbalancer which passthrough the traffic coming to port 80 and 443 to different backend ports. SSL termination is happening in the backend and HAproxy should not engage with anything other than forwarding the traffic coming to the frontend port 80 and 443 to the respective backend ports.
Port 80 forwarding seems fine and 443 is not working as expected and giving SSL handshake failure. Even my backend service is not coming up on the web browser with a warning saying this is not trusted. I have no clue why this is happening and my HAProxy experience is not that high and below is the current configuration. Please correct me if I'm wrong.
HAProxy is installed on Ubuntu 18.04.5 LTS
Config after the defaults section
frontend k8s_lb
mode tcp
bind x.x.x.x:80
default_backend kube_minions
frontend k8s_lb_https
mode tcp
bind x.x.x.x:443
default_backend kube_minions_https
backend kube_minions
mode tcp
balance roundrobin
server k8s_worker-01 x.x.x.x:32080
server k8s_worker-02 x.x.x.x:32080
backend kube_minions_https
mode tcp
balance roundrobin
server k8s_worker-01 x.x.x.x:32443
server k8s_worker-02 x.x.x.x:32443
The backend story:
I have a k8s cluster and traefik ingress which is running as a DaemonSet on each and every node, and minions are my backend servers. CertManager is in place to do the cert automation with Let's encrypt ACME protocol in the ingress resources, hence SSL termination should be happening through the ingress resources.
I have completed the certificates and everything seems perfect as I have already implemented a similar setup on AWS with a TCP loadbalancer and everything is perfectly working and running prod workloads.
So, I need to mention that backend services are all good and up and running. In this I replaced the AWS loadbalancer with HAProxy and need to implement the same.
Please assist me to fix this as I'm struggling with this and still no luck with the issue.
Thank you.
Sorry, I was able to figure it out and there is nothing to do with traefik and HAProxy for this SSL issue. My Client's DNS is configured in CloudFlare and they have enabled the universal SSL and it caused the issue.
I checked with a new DNS record from route53 working as expected so my HAProxy config do what I need.
I am trying to use Traefik as Loadbalancer for MQTT over tcp with TLS (1.2). I found some posts here for the topic how to setup traefik for mqtt, but nothing related or solving my special problem/case.
I have setup the following configuration for simulating locally the behaviour of Traefik as a Reverse Proxy & Loadbalancer for MQTT on my developer Windows 10 machine
Mosquitto_168_8883 on Windows locally on Port 8883 with TLS enabled/selfsigned certificates
Traefik 2.1.2 on Windows listening on Port 7883 for routing to mqqt (toml see below)
Node-Red 1.0.3 on Windows (NodeJs 12.14.1) client connecting (a) directly to Mosquitto (b) over Traefik to Mosquito
(a) Directly connecting and publishing is working for Node-Red Client (Port 8883)
(b) via Traefik: Node-Red can not connect or publish to MQTT (Port 7883)
My Traefik TOML Configuration is as follows:
[tracing]
serviceName = "mqtt"
[log]
level = "DEBUG" # --log.level
[entryPoints]
[entryPoints.mqtt]
address = ":7883"
[entryPoints.traefik]
address ="localhost:8091"
[api]
dashboard = true
insecure = true
[tcp] # YAY!
[tcp.routers]
[tcp.routers.mqtt]
entrypoints = ["mqtt"]
rule = "HostSNI(`*`)" # Catches every request
service = "mqtt"
[tcp.routers.mqtt.tls]
passthrough = true
[tcp.services]
[tcp.services.mqtt]
[tcp.services.mqtt.loadBalancer]
[[tcp.services.mqtt.loadBalancer.servers]]
address = "localhost:8883"
Currently, I see nothing of interest within the active tracing and logging output. The Traefik UI shows no connection attemps via port 7883/TCP/Entrypoint mqtt
Does anyone has this usecase implemented up & running?
What am I doing wrong / what am I missing?
Thank you in advance.
I have a Kubernetes Ingress, pointing to a headless service, pointing finally to an Endpoints object that routes to an external IP address. The following is the configuration for the endpoint
apiVersion: v1
kind: Endpoints
metadata:
name: my-chart
subsets:
- addresses:
- ip: **.**.**.**
ports:
- port: 443
However, the upstream connection fails with 'connection reset by peer', and on looking at the logs I see the following error in the Kubernetes nginx-ingress-controller:
2020/01/15 14:39:50 [error] 24546#24546: *240425068 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: *****, server: dev.somehost.com, request: "GET / HTTP/1.1", upstream: "http://**.**.**.**:443/", host: "dev.somehost.com"
My theory is that the combination of http:// and the 443 port is what is triggering this (tested with cURL commands). How do I either 1) Specify a different protocol for the endpoint object or 2) just prevent the prepending of http://
Additional notes:
1) SSL is enabled on the target IP, and if I curl it I can set up a secure connection
2) SSL passthrough doesn't really work here. The incoming and outgoing requests will use two different SSL connections with two different certificates.
3) I want the Ingress host to be the SNI (and it looks like this may default to being the case)
Edit: Ingress controller version: 0.21.0-rancher3
We were able to solve this by adding the following to the metadata of our Ingress
annotations:
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
nginx.ingress.kubernetes.io/configuration-snippet: |-
proxy_ssl_server_name on;
proxy_ssl_name $host;
The first command turns on HTTPS for the backend protocol, and the second command enables SNI
I'm trying to set up a Redis with docker-compose for different environments.
Therefore I need to expose two domains with traefik on the same port:
domain.com:6379
domain-dev.com:6379
I can't expose those ports on the container, because they are running on the same server.
My docker-compose file (for domain-dev) looks like this:
version: '2'
services:
redis:
container_name: redis-signalr-dev
image: redis
volumes:
- ./redis-signalr-data:/data
restart: always
labels:
- traefik.enable=true
- traefik.backend=redis-signalr-dev
- traefik.frontend.rule=Host:domain-dev.com
- traefik.port=6379
- traefik.docker.network=traefik_default
- traefik.frontend.entryPoints=redis
networks:
- traefik_default
volumes:
redis-signalr-data:
networks:
traefik_default:
external: true
I also tried to configure the treafik to use the following endpoint:
--entrypoints='Name:redis Address::6379'
When connecting to "domain-dev.com:6379" a connection cannot be astablished.
Does anyone know a solution to this problem?
Traefik is a reverse proxy for http, not a tcp load balancer. So traefik itself (usually) opens ports 80 and 443 for ingress and forwards incoming http requests to the given http-able backends. The port you specify in your compose service labels is the port of the container, the traffic should be passed to.
So if you run a nodejs (http) server on port 3000, you would connect to http://yourdomain:80 and traefik would forward the requests to your nodejs container on port 3000. This means that by specifying a port on a compose service, you will not open this port on your host.
In your example running redis with its custom protocol, traefik is not a solution as traefik only does http proxying. To expose redis on your host (if you really want to do that), just use regular docker port mappings and point your domains to your docker hosts. Doing this, there is no way to use the same port with different domains, just specify two different ports for your both instances. For http this works by traefik inspecting the http requests and doing routing based on the host header.
Traefik 2.0 will have TCP support: https://github.com/containous/traefik/pull/4587
Until then you'd have to use NGINX or similar.
I want to use ssl in my springboot app. I use this tutorial but when I try up start my app gives me this error:
***************************
APPLICATION FAILED TO START
***************************
Description:
The Tomcat connector configured to listen on port 8443 failed to start. The port may already be in use or the connector may be misconfigured.
Action:
Verify the connector's configuration, identify and stop any process that's listening on port 8443, or configure this application to listen on another port.
And my application.properties
#ssl
server.port=8443
server.ssl.key-alias=alias
server.ssl.key-password=password
server.ssl.key-store=classpath:keystore.jks
server.ssl.key-store-provider=SUN
server.ssl.key-store-type=JKS
Or do you know another way to do SSL trusted?
Generate the key with command line running in admin mode.