Restrict accessing host for user in the initializer job

[tennix]

Feature Request

Is your feature request related to a problem? Please describe:

The initializer job always creates users with @% which allows any host IP to access the TiDB cluster. This is not secure

Describe the feature you'd like:

Restrict the host to 127.0.0.1, and add instruction to allow users using kubectl port-forward -n svc/<cluster-name>-tidb 4000:4000 to change the accessing host IP ranges.
Note: The client source IP may be different when using different ways to access the cluster.

Describe alternatives you've considered:

Using network policy to restrict access, but this is complicated to setup and not enabled in many k8s clusters.

Teachability, Documentation, Adoption, Migration Strategy:

This enhances the security of TiDB cluster, protect it accessing from an unknown host.

[gregwebs]

Should users configure the initializer job itself with the desired root access? So this is just the default if they don't configure anything?

What is the threat model? Currently we advise users to put their password into a K8s secret where the initiliazer job can access it.

This may create usability issues for non-production setups (new users testing things out). I think it would break some of our tutorials.

[kolbe]

If we base tutorials around port forwarding and other mechanisms that give users localhost access to TiDB nodes, we can use root@127.0.0.1 accounts without creating usability problems. For setups that require access through a bastion or lb, there is probably a way to identify a range of addresses a user would be connecting from.

[gregwebs]

Kubernetes access restriction is fundamentally based around namespace restriction (other more fine-grained restrictions may be circumventable). We could restrict access to the TiDB cluster namespace (with a host wildcard), particularly if the installation is into a new namespace.

For the bastion we can probably create it with a stable IP address and whitelist that IP. But I don't think it makes sense to open up that access point if kubectl port-forward is going to be available.

[tennix]

We may use the bastion machine to run sysbench for benchmark, I don't think kubectl port-forward is appropriate for this. So we need to whitelist the bastion IP in the default setup.

[gregwebs]

I don't think we can use the bastion for sysbench. Sysbench needs resources for its task, but the bastion is always on and should be as small as possible. I run sysbench as a K8s job.

[tennix]

With #779, it's possible to restrict accessing host now.