<p>I'm currently trying to build my services on kubernetes using istio and have trouble trying to whitelist all host IPs that are allowed to connect to the Mysql database through mysql.user table. </p>

<p>I always get the following error after a new deployment:
Host 'X.X.X.X' is not allowed to connect to this MySQL server</p>

<p>Knowing that every time i deploy my service a new pod IP always pops out and i have to add replace the old user with the new host IP. I would really like to avoid using '%' for the host.</p>

<p>Is there any way how i could just register the node IP instead to keep its persistence?</p>

Radhian Amri
<p>Both Kubernetes and Istio provide network-level protections and setting the allowed hosts to "all" is safe.</p>

<p>A Kubernetes <a href="https://kubernetes.io/docs/concepts/services-networking/network-policies/" rel="nofollow noreferrer">network policy</a> is probably the best cluster-level match for what you're looking for.  You'd set the database itself to accept connections from all addresses, but then would set a network policy to refuse connections except from pods that have a specific set of labels.  Since you control this by <em>label</em>, any new pods that have the appropriate set of labels will be automatically granted access without manual changes.</p>

<p>Depending on your needs, the default protection given by a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types" rel="nofollow noreferrer"><code>ClusterIP</code> service</a> may be enough for you.  If a service is <code>ClusterIP</code> but not any other type, it is unreachable from outside the cluster; there is no network path to make it accessible.  This is often enough to prevent casual network snoopers from finding your database.</p>

<p>Istio's <a href="https://istio.io/docs/concepts/security/#authorization" rel="nofollow noreferrer">authorization</a> system is a little bit more powerful and robust at a network level.  It can limit calls by the Kubernetes service account of the caller, and uses TLS certificates rather than just IP addresses to identify the caller.  However, it doesn't come enabled by default, and in my limited experience with it it's very easy to accidentally configure it to do things like block Kubernetes health checks or Prometheus metric probes.  If you're satisfied with IP-level security this might be more power than you need.</p>
