trinodb / charts

Apache License 2.0
151 stars 173 forks source link

added hostAliases support for coordinator and worker deployment #255

Open hosseinabaiyani opened 5 days ago

hosseinabaiyani commented 5 days ago

Adding hostAliases template and values for coordinator deployment and worker deployment

This is useful for connect to databases with selfsigned certificate and invalid domain name

cla-bot[bot] commented 5 days ago

Thank you for your pull request and welcome to the Trino community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. Continue to work with us on the review and improvements in this PR, and submit the signed CLA to cla@trino.io. Photos, scans, or digitally-signed PDF files are all suitable. Processing may take a few days. The CLA needs to be on file before we merge your changes. For more information, see https://github.com/trinodb/cla

nineinchnick commented 5 days ago

Which data sources you need this for? For example, in PostgreSQL, you can disable host verification by setting sslmode=verify-ca instead of sslmode=verify-full. Maybe other data sources also have an option like this?

hosseinabaiyani commented 5 days ago

Which data sources you need this for? For example, in PostgreSQL, you can disable host verification by setting sslmode=verify-ca instead of sslmode=verify-full. Maybe other data sources also have an option like this?

for my situation it was MongoDB but the key is that I wanted to use SSL verification for security reasons and I think it may be useful for other users, so I've added support for it in chart

nineinchnick commented 5 days ago

It doesn't add any security, if you fake the hostname. That's why there are options to disable hostname verification. MongoDB has tlsAllowInvalidHostnames.

hosseinabaiyani commented 5 days ago

I think I did not properly present my point. this is not a security feature, I'm sorry.

Imagine we have a ha MongoDB cluster with private IPs which is inaccessible from the internet, and we have to reach it through a router server. the router sends traffic to a desired internal server by the requested hostname.

for example I have a server with ip 10.2.5.1(assume it is a valid public ip) and have 3 mongo servers with ips
192.168.1.1 192.168.1.2 192.168.1.3

and 10.2.5.1 configured to send traffic to 192.168.1.2 if it comes with hostname mongo-2

in this case to reach that database server, we have to set hostname in trino server for it

nineinchnick commented 5 days ago

Could you achieve the same with a headless service, with one endpoint?

hosseinabaiyani commented 5 days ago

headless service isn't the point in this particular architecture think of one proxy server in front of multiple databases with private ips :

mongo-prod , mongo-sgate , mariadb-users , etc all are can be connected using one IP address but with different hostnames

nineinchnick commented 4 days ago

WDYM it isn't the point? Have you tried it to set aliases for other hostnames?

hosseinabaiyani commented 4 days ago

dude this headless service is useful when database is hosted in a Kubernetes cluster beside trino not in another network , look at the diagram I made

image

we set proxy server address in host alias and in aliases enter the internal hostname proxy server determine which server send traffic to based on passed hostname

hosseinabaiyani commented 1 day ago

Have you checked my last comment?

nineinchnick commented 16 hours ago

Sorry, I couldn't respond earlier. I was suggesting using services, but I was not specific enough - you could use them with external names to manage aliases: https://kubernetes.io/docs/concepts/services-networking/service/#externalname

There might be some limitations to services names - like you might not be able to use IP addresses there.

I'm only trying to make sure the use case for this feature is well-defined, and useful to the wider community. Every new feature in the chart adds testing overhead.