[Kolla][kolla-ansible][HAProxy] Splitting the load balancer into internal and external?
All,
Was the idea of moving internal components deployed by kolla-ansible (like the MySQL database) to a load balancer separate to the one used by user-facing APIs discussed anywhere? This feels like a good option to have for security but, as far as I'm aware, it's not supported by kolla-ansible.
It should be possible to use existing Kolla HAProxy images, but mount config files from subdirectories of `/etc/kolla/haproxy/` for each container. I suspect the main hurtle here would be rewriting the user interface of kolla-ansible to account for the split whilst maintaining backward compatibility...
Mariusz Karpiarz
Hi,
For mysql you can use proxysql as a separate loadbalancer. But I don't understand your other questions... Does it mean that you want to run haproxy for some service (for example mariadb ..if proxysql is not used) in a mariadb container ? Or have a separate haproxy_mariadb container to do this ? If yes , both are bad ideas.
First option contradicts the idea of "one process per container". The Second option will just run multiple instances of haproxy containers.
Could you please explain in detail ?
Thanks, kevko Michal Arbet Openstack Engineer
Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic
+420 604 228 897 michal.arbet@ultimum.io *https://ultimum.io https://ultimum.io/*
LinkedIn https://www.linkedin.com/company/ultimum-technologies | Twitter https://twitter.com/ultimumtech | Facebook https://www.facebook.com/ultimumtechnologies/timeline
pá 11. 11. 2022 v 15:41 odesílatel Mariusz Karpiarz < m.karpiarz@eschercloud.ai> napsal:
All,
Was the idea of moving internal components deployed by kolla-ansible (like the MySQL database) to a load balancer separate to the one used by user-facing APIs discussed anywhere? This feels like a good option to have for security but, as far as I'm aware, it's not supported by kolla-ansible.
It should be possible to use existing Kolla HAProxy images, but mount config files from subdirectories of `/etc/kolla/haproxy/` for each container. I suspect the main hurtle here would be rewriting the user interface of kolla-ansible to account for the split whilst maintaining backward compatibility...
Mariusz Karpiarz
Michal, Thank you for your message.
To explain what I mean a little better, let’s look at a use case of a web-based service running in a cloud but not using a Database-as-a-Service offering. In this setup (a sample diagram: https://www.cozumpark.com/wp-content/uploads/2020/02/image-5.png) a good security practice is to use a different (“internal”) load balancer for database servers and different (“public”) - for all the web servers serving user requests. The database doesn’t need to be accessible from the outside world, so this split provides a physical separation of traffic and this is exactly what I’m suggesting here.
As for how to archive this, we can keep one HAProxy process in one container (and use regular Kolla images) but there will simply be two HAProxy containers (one “external” and one “public”) running either on the same controllers or on different ones.
I hope this explanation helps but please do let me know if you want me to elaborate on any particular aspect of it.
In a way kolla already does this by separating certain things onto "internal" VIPs vs "external" VIPs. So even though a single haproxy instance is running both internal and external, they are separated into their own connection paths that enforce segregation. Ultimately running a separate haproxy won't really add much security as you'll essentially be doing what kolla is already doing. ________________________________ From: Mariusz Karpiarz m.karpiarz@eschercloud.ai Sent: 16 November 2022 17:23 To: Michal Arbet michal.arbet@ultimum.io Cc: openstack-discuss openstack-discuss@lists.openstack.org Subject: Re: [Kolla][kolla-ansible][HAProxy] Splitting the load balancer into internal and external?
CAUTION: This email originates from outside THG
________________________________
Michal, Thank you for your message.
To explain what I mean a little better, let’s look at a use case of a web-based service running in a cloud but not using a Database-as-a-Service offering. In this setup (a sample diagram: https://www.cozumpark.com/wp-content/uploads/2020/02/image-5.pnghttps://www.cozumpark.com/wp-content/uploads/2020/02/image-5.png) a good security practice is to use a different (“internal”) load balancer for database servers and different (“public”) - for all the web servers serving user requests. The database doesn’t need to be accessible from the outside world, so this split provides a physical separation of traffic and this is exactly what I’m suggesting here.
As for how to archive this, we can keep one HAProxy process in one container (and use regular Kolla images) but there will simply be two HAProxy containers (one “external” and one “public”) running either on the same controllers or on different ones.
I hope this explanation helps but please do let me know if you want me to elaborate on any particular aspect of it.
Danny Webb Principal OpenStack Engineer The Hut Grouphttp://www.thehutgroup.com/
Tel: Email: Danny.Webb@thehutgroup.commailto:Danny.Webb@thehutgroup.com
For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries.
Confidentiality Notice This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company.
Encryptions and Viruses Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.
Monitoring Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes.
hgvyjuv
Hi,
Now i understand , but agree with Danny Webb, this is unnecessary ...
Michal Arbet Openstack Engineer
Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic
+420 604 228 897 michal.arbet@ultimum.io *https://ultimum.io https://ultimum.io/*
LinkedIn https://www.linkedin.com/company/ultimum-technologies | Twitter https://twitter.com/ultimumtech | Facebook https://www.facebook.com/ultimumtechnologies/timeline
st 16. 11. 2022 v 20:02 odesílatel Danny Webb Danny.Webb@thehutgroup.com napsal:
In a way kolla already does this by separating certain things onto "internal" VIPs vs "external" VIPs. So even though a single haproxy instance is running both internal and external, they are separated into their own connection paths that enforce segregation. Ultimately running a separate haproxy won't really add much security as you'll essentially be doing what kolla is already doing.
*From:* Mariusz Karpiarz m.karpiarz@eschercloud.ai *Sent:* 16 November 2022 17:23 *To:* Michal Arbet michal.arbet@ultimum.io *Cc:* openstack-discuss openstack-discuss@lists.openstack.org *Subject:* Re: [Kolla][kolla-ansible][HAProxy] Splitting the load balancer into internal and external?
- CAUTION: This email originates from outside THG *
Michal, Thank you for your message.
To explain what I mean a little better, let’s look at a use case of a web-based service running in a cloud but not using a Database-as-a-Service offering. In this setup (a sample diagram: https://www.cozumpark.com/wp-content/uploads/2020/02/image-5.png) a good security practice is to use a different (“internal”) load balancer for database servers and different (“public”) - for all the web servers serving user requests. The database doesn’t need to be accessible from the outside world, so this split provides a physical separation of traffic and this is exactly what I’m suggesting here.
As for how to archive this, we can keep one HAProxy process in one container (and use regular Kolla images) but there will simply be two HAProxy containers (one “external” and one “public”) running either on the same controllers or on different ones.
I hope this explanation helps but please do let me know if you want me to elaborate on any particular aspect of it.
Danny Webb Principal OpenStack Engineer The Hut Group http://www.thehutgroup.com/
Tel: Email: Danny.Webb@thehutgroup.com
For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries.
*Confidentiality Notice* This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company.
*Encryptions and Viruses* Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.
*Monitoring* Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes. hgvyjuv
participants (3)
-
Danny Webb
-
Mariusz Karpiarz
-
Michal Arbet