Inconsistent best practices regarding the Database - Kubernetes interconnection

[sebastian-philipp]

Hi there,

In https://docs.ovh.com/de/publiccloud/databases/mysql/tutorial-connect-kubernetes-to-managed-mysql/#step-5-configure-your-options , you're recommending using a public network for the interconnection between Mysql and the Kubernetes cluster.

But In Discord, Bastien Verdebout mentioned:

Hello Sebastian Wagner indeed so far you need to select a private network option during DB creation. you cannot modify it once the clsuter is running. About best practices, having a private network will allow you to secure a bit more your infra, and benefit from more bandwidth. but you will need a gateway to connect to your DB (for example you cannot do laptop (postgre CLI ==> DB). you will need a vm inside you vrack with postgre CLI. that's not worse, it' in fact better since you can log this machine like a bastion, but it's something to know)

So, you should probably decide on a best practice.

https://docs.ovh.com/gb/en/kubernetes/vrack-k8s-custom-gateway/ also gave me some insights.

[fpillotovh]

Hello sebastian-philipp,

Regarding your question about best practices for connecting a Kubernetes service managed by OVHcloud to a MySQL service managed by OVHcloud, we don't necessarily specify best practices in our tutorials, as these are intended for all audiences (in this example: https://docs.ovh.com/de/publiccloud/databases/mysql/tutorial-connect-kubernetes-to-managed-mysql/#step-5-configure-your-options, we chose to document an example that is quick to set up and accessible to all audiences), unlike our guides where we recommend best practices for using our offerings.
Bastien Verdebout's answer on Discord is in my opinion the most accurate in terms of security, as your security needs depend on your services/products.
Furthermore, I would like to inform you that all Public Cloud Databases services are now available via a private network (vrack): https://docs.ovh.com/gb/en/publiccloud/databases/configure-vrack/

Sorry for the delay in responding