Learn Vitess - Secure Connectivity

#Introduction

The data in a Vitess cluster is your most valuable asset. If the communication paths aren't secured, data can leak in transit: application to VTGate, VTGate to VTTablet, and VTTablet to MySQL. Episode 12 builds the transport and identity security layer across all those paths, plus traffic restrictions at the network level.

Episode 12 roadmap: TLS between components, client authentication and MySQL user management, then network policies for isolating services in Kubernetes. By the end, your data paths are encrypted and controlled.

#TLS Between VTGate, VTTablet, and MySQL

TLS encrypts data as it moves between components. Three hops need securing:

1. Client to VTGate — applications connect over the MySQL protocol. Enable TLS at VTGate so application connections are encrypted.
2. VTGate to VTTablet — internal traffic. Must be encrypted on untrusted networks.
3. VTTablet to MySQL — the last hop before data hits disk. Use MySQL TLS connections.

VTGate and VTTablet use certificates configured in their deployments. The common approach: store the CA and certificates as a Secret, then mount them into the containers.

kubectl create secret tls vitess-vtgate-tls \
  --cert=tls.crt --key=tls.key \
  --namespace vitess

kubectl create secret tls creates a secret from a certificate and key pair. In values.yaml, point VTGate and VTTablet at this secret:

vtgate:
  extraFlags:
    mysql_server_ssl_cert: /etc/tls/tls.crt
    mysql_server_ssl_key: /etc/tls/tls.key

For VTTablet-to-MySQL communication, use the SSL flags in the tablet configuration so its connections use TLS:

vtctlclient SetTabletConnectionInfo <tablet-alias> \
  -ca /etc/ssl/vitess-ca.crt

#Client Authentication and MySQL User Management

TLS encrypts, but who gets to enter? That's determined by authentication. VTGate can authenticate clients in several ways, one of which is with a MySQL username and password validated against the user table in the MySQL shards.

Vitess supports vtgateclientcredentials for static credentials, or validating users directly against MySQL. For dynamic needs, Vitess has auth plugins such as static auth (from JSON) and MySQL-based auth. Example of static auth:

{
  "vt_appuser": [
    { "Username": "appuser", "Password": "sha256:...", "UserData": "appuser" }
  ]
}

The Username and Password above define the credentials VTGate accepts. Passwords are stored as hashes, not plaintext.

For user management on the MySQL side, manage normal MySQL users — user differences across shards must stay consistent, so it's best managed through schema automation:

CREATE USER 'appuser'@'%' IDENTIFIED BY 'rahasia-kuat'
GRANT SELECT, INSERT, UPDATE ON commerce.* TO 'appuser'@'%'

The CREATE USER and GRANT commands above run on MySQL. In Vitess, DDL like this runs per shard — make sure the user is created consistently on all shards of the keyspace.

#Network Policies for Service Isolation

TLS and authentication protect identity; NetworkPolicy protects the perimeter — restricting who can talk to which component at the network level. In Kubernetes, a NetworkPolicy restricts traffic based on labels and ports, and requires a CNI that supports it (e.g., Calico or Cilium).

Example: only applications in the backend namespace may talk to VTGate in the vitess namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-vtgate
  namespace: vitess
spec:
  podSelector:
    matchLabels:
      app: vtgate
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 3306

The policy above allows incoming traffic to VTGate only from the backend namespace, on port 3306. Other default-deny rules can be installed at the namespace level.

Recommended isolation:

• Separate namespaces: vitess for database components, backend for applications.
• Minimal ports: only the ports actually needed are opened between namespaces.
• Separate admin and app: vtctld is only accessible to operators, not applications.

#Closing

In this episode 12 you secured the communication paths of a Vitess cluster: TLS on the three hops (client-VTGate, VTGate-VTTablet, VTTablet-MySQL), client authentication with static auth or MySQL-based auth, and network policies that isolate services at the network level.

Key takeaways:

• Encrypt every hop: client to VTGate, VTGate to VTTablet, VTTablet to MySQL.
• Store certificates as a Secret and mount them into the components that need them.
• VTGate client authentication can be static auth or MySQL user based.
• MySQL users must be consistent across all shards — manage them via automation.
• NetworkPolicy restricts the perimeter: only needed namespaces and ports.
• Make sure the CNI supports NetworkPolicy enforcement before relying on it.

In the next episode, episode 13, we set who can do what: access control and audit — MySQL users and privileges, row- and column-level access considerations, audit logging, and separating application and admin access. See you there!