DevOpsPadDownload

Create least-privilege accounts

The safest way to use any database client against production is an account that cannot write. DevOpsPad’s read-only modes help, but the server’s permissions are what actually stop a DROP TABLE. Give DevOpsPad its own account per engine with only the read access listed below, and keep write-capable accounts out of it.

A dedicated account also makes DevOpsPad’s activity easy to find in server logs and easy to revoke.

MySQL

MySQL’s read-only transaction does not block DDL (see What is read-only in DevOpsPad), so this one matters most.

CREATE USER 'devopspad'@'%' IDENTIFIED BY 'use-a-long-random-password';
GRANT SELECT, SHOW VIEW ON shop.* TO 'devopspad'@'%';

Grant on each database you want to browse, or on *.* for all of them. SHOW VIEW lets the DDL view show view definitions. Restrict the host part ('%') to your bastion or office network where you can.

ClickHouse

DevOpsPad already sends readonly=1 with every request, which the server enforces. Still give the user only read grants:

CREATE USER devopspad IDENTIFIED BY 'use-a-long-random-password';
GRANT SELECT, SHOW ON analytics.* TO devopspad;

MongoDB

Use the built-in read role on the databases you need:

db.getSiblingDB("admin").createUser({
  user: "devopspad",
  pwd: "use-a-long-random-password",
  roles: [{ role: "read", db: "shop" }]
})

Create the user in admin and leave authSource at its default, admin, in DevOpsPad. See Connect to MongoDB.

Redis

With Redis 6 or later, create an ACL user limited to read commands:

ACL SETUSER devopspad on >use-a-long-random-password ~* resetchannels -@all +@read +@connection +info

+@read covers the key and value commands DevOpsPad uses (SCAN, TYPE, TTL, GET, HSCAN and so on), +@connection covers PING and the client handshake, and +info allows INFO. Click Test connection to confirm the handshake works with your Redis version. Named ACL users are covered in Redis ACL users and TLS.

Kafka

DevOpsPad only reads cluster metadata: topics, partitions, leaders and replicas. If your cluster uses ACLs, the principal needs Describe on the topics it should see. It does not need Read or Write, because DevOpsPad does not consume or produce messages.

Kubernetes and K3s

Grant get and list on the types you browse, plus pods/log and events. A complete Role and the per-view breakdown are in Kubernetes permissions DevOpsPad needs. Do not grant access to Secrets.

If you also use the Infra console to release, use a separate context with the extra Deployment, Lease and ConfigMap permissions, so day-to-day browsing does not carry write access.

Checklist

  • One DevOpsPad account per engine and environment, never a shared admin user.
  • Read-only grants as above; no DDL, no write, no admin roles.
  • Label production connections clearly with the Environment field.
  • Prefer replicas or read endpoints for exploration.
  • Rotate the passwords like any other credential; DevOpsPad keeps them in the OS keychain (how secrets are stored).