Blog · 2026-10-30 · Gardience Engineering

Keep your Salt master, add a console: a blueprint for Salt and Tanzu Salt shops

Run Gardience next to the Salt master you already operate. Your agents, states, and pillars stay where they are, setup is one command with a plan you confirm first, and one command undoes it.

If you already run Salt, the expensive part of changing tools is moving agents. This blueprint skips it. Gardience attaches to the Salt master you run today: your agents stay connected to it, your states and pillars stay in your file roots, and Gardience adds the console, approvals, audit log, patching, and compliance on top.

It fits teams on open-source Salt, and teams on Tanzu Salt (formerly VMware Aria Config and SaltStack Config) who want to keep their Salt estate but not the licence.

What stays and what you add#

The steps#

1. Install Gardience on its own Linux server, pointed at your salt-api. It needs no Salt ports of its own.

sudo ./install/install.sh \
  --attach https://salt-master.example.com:8000 \
  --eauth pam \
  --attach-master-ip 10.0.0.10 \
  --master-address salt-master.example.com \
  --admins alice --approvers bob,carol \
  --hostname gardience.example.com \
  --license /path/to/gardience-license.json

2. Set up the master with one command.

sudo /opt/gardience/gardience attach-setup admin@salt-master.example.com --admins alice --approvers bob,carol

It reads your master's configuration with Salt's own loader, shows a plan, and changes nothing until you confirm. --dry-run shows the plan only. Gardience's settings go in one drop-in file, master.d/zz-gardience.conf, which keeps your settings and adds to them. It restarts salt-master and salt-api, then stops with a clear message if any agent that answered before no longer does.

3. Check the dashboard. Within a few minutes your nodes appear in the console.

To undo it, run setup-master.sh --undo on the master. It removes everything it added and puts your configuration back as it was.

How rights work#

People get a gdn: grant in your eauth, which Salt itself never matches. So their changes work only through Gardience, which applies approvals, change tickets, windows, and locks first. Raw Salt access stays with root on the master. Gardience's two service accounts get named functions, never .*.

What you give up compared with the all-in-one install#

Be clear about these before you choose:

• Your master runs your own Salt build, so Gardience's hardening of the master (refusing forged job returns and events, keeping console sign-ins across restarts) is not applied to it. The attach guide shows a one-line change to Salt that closes the forged-return gap; repeat it after each Salt upgrade.
• Event rules and system locks write pillar data on the Gardience server. Point your pillar_roots at that folder on shared storage, or manage the same data in your own pillar.
• Syndic setups and eauth types other than PAM, file, or LDAP need the manual steps instead of the one command.

If you stop#

Nothing about your Salt estate depends on Gardience. Run setup-master.sh --undo and your master keeps running exactly as before. See your exit plan.

Full steps: Attach to an existing Salt master.