Learn Vitess - Access Control & Audit

#Introduction

Security doesn't stop at encryption. After locking down the transport path in episode 12, the next question is: who is allowed to do what? Not every user should be able to DROP TABLE, and not every query should be logged. Episode 13 covers the access model and audit trail in Vitess — the layer that determines who gets in and what they can do.

Episode 13 roadmap: MySQL users and privileges, row- and column-level access, audit logging, then separating application and admin tool access.

#MySQL Users and Privileges in Vitess

Vitess's access model rests on MySQL users. Every user has grants: which tables they can read, which tables they can write, and which admin operations they can run. The key to managing this securely: create users with the principle of least privilege.

Roles commonly used:

Application (appuser) — only SELECT, INSERT, UPDATE, DELETE on application tables. No DDL needed.
Schema change (ddluser) — has ALTER, CREATE, DROP, only used during migrations.
Read-only (readonlyuser) — SELECT only, for reporting.
Admin (root) — full access, operators only.

Minimal privileges for the application

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

The GRANT command above gives appuser read-write ability without DDL rights. Every user should have a distinct password and rotate it regularly.

Info

VTGate talks to VTTablet with dedicated credentials (e.g., vt_appuser). Applications never interact directly with the MySQL shards — all queries go through VTGate. Make sure application users have no rights to connect directly to tablets.

#Row- and Column-level Access

Sometimes limiting per table isn't enough — you need to limit per row or per column.

Column-level: a user shouldn't see sensitive columns like email or phone. MySQL supports this through views or censored VIRTUAL columns. Create a view that only exposes safe columns, then grant access to that view only.
Row-level: a user should only see their own rows. MySQL has no built-in row-level security, but it can be simulated with a view filtering WHERE tenant_id = ... and forcing access through the view.

View to restrict columns

CREATE VIEW public_users AS
SELECT user_id, name FROM users

The CREATE VIEW above exposes only the user_id and name columns, hiding email and other sensitive data. Grant access to this view for reporting users:

Grant access to the view

mysql -h 127.0.0.1 -P 15306 -e "GRANT SELECT ON commerce.public_users TO 'readonlyuser'@'%'"

The mysql -h 127.0.0.1 -P 15306 command executes SQL through VTGate. With the view pattern, access control can be enforced at the database level, not just in the application.

Warning

In a sharded keyspace, views that rely on cross-shard joins can be expensive. For row-level access in sharded workloads, it's better to encapsulate access rules in the application or use a tenant-column pattern already mapped to the sharding key.

#Audit Logging and Compliance

Auditing answers the question: who did what, when, and from where. For compliance (like PCI-DSS or data protection), trails of access to sensitive data are usually mandatory. Vitess provides several audit layers:

VTGate query log — records queries passing through VTGate.
MySQL audit log — records access at the MySQL level (requires the audit plugin).
Access logs — from components or proxies in front.

Enable the MySQL audit log via the audit_log plugin in the MySQL configuration:

Audit plugin configuration

audit_log=ON
audit_log_file=/var/log/mysql/audit.log
audit_log_format=JSON

The audit_log=ON line enables the MySQL audit plugin. JSON logs record user, query, and time — the raw material for investigations and compliance reports.

To monitor who's currently connected:

Active users

SELECT user, host, db, command FROM information_schema.processlist

The SELECT ... FROM information_schema.processlist command lists active sessions — a quick way to see who's connected and what they're doing.

#Separating Application and Admin Access

An important principle: applications and admins must not use the same path. This separation prevents a compromised application from reaching admin tools, and prevents application queries from interfering with operations.

Recommended separation pattern:

Applications only connect to VTGate with application users, without DDL.
Admins use vtctlclient against vtctld, which shouldn't be publicly exposed and should only be reachable from an internal network or VPN.
VTTablet and vtctld use mTLS authentication between components (episode 12).
Read-only reporting uses a separate user and ideally routes to RDONLY tablets.

Admin access to vtctld

kubectl exec -it deploy/vtctld -- vtctlclient \
  -server localhost:15999 ListAllTablets

vtctlclient ListAllTablets runs from inside the vtctld Pod — admin access never leaves the cluster, reducing the attack surface.

Success

The separation formula: applications only through VTGate, admins only through vtctld, reporting only through RDONLY tablets. Each path has its own isolated user, credentials, and network. If one path leaks, the other two stay safe.

#Closing

In this episode 13 you set up access control and auditing in Vitess: users and privileges with the least-privilege principle, column- and row-level restrictions through views, audit logging for compliance, and separating the application, admin, and reporting paths.

Key takeaways:

Vitess's access model is based on MySQL users and privileges.
Separate roles: appuser, ddluser, readonlyuser, and admin with different rights.
Restrict column access with views; watch out for cross-shard join costs.
Enable the MySQL audit log for compliance needs.
Applications only through VTGate, admins only through vtctld.
Never give applications DDL rights or direct access to tablets.

In the next episode, episode 14, we scale globally: multi-region and disaster recovery — geo-sharding, multi-region replication and read locality, DR strategies, and global failover planning. See you there!