RELEASE NOTES

Zanskar v1.3.0

Latest release

Administrators can now work from a command line inside the console. It runs Zanskar commands only, opens with a fresh authenticator code, and records every line in the audit log. Authenticator codes also become single-use.

• The console command line: the terminal-window icon at the top right of every admin page, or Ctrl+`, opens it. Thirty-four commands cover sessions, users, targets, policies, access requests, events, logs, settings, autoscaling groups and a restart. It is not a shell: pipes, variables and anything unlisted are refused, nothing takes a secret, and host operations stay on the host. See the guide and ADR 0027.
• Same permissions as the console: only administrators get it, and each command is the same API request a console page makes, through the same checks.
• A code that was just proved: it opens with a code from your authenticator, again after 15 idle minutes, and five wrong codes close it for 15 minutes. Signing in without a code, as an identity-provider account or when MFA is not required, does not count.
• Audited in words: every line is an event, shown on the Events page as ran “sessions --live” on the command line, with the API routes it called in the details.
• Each authenticator code works once: a code that was accepted, at sign-in, enrolment or the command line, is refused for the rest of its window, so a code read over a shoulder or a screen share cannot be used again. A reused code is recorded as one on the Events page. Before, a code could be replayed for about a minute and a half.
• Dependencies: the console's session player no longer pulls a serializer with published advisories; the vulnerable code was never in the built console.

Install Release on GitHub

Upgrading from 1.2.2 to 1.3.0

Install the new package, or set ZANSKAR_VERSION=1.3.0, and restart. Two migrations at start add one column each, to sign-in sessions and to authenticators, and rewrite no data. The command line is on for administrators straight away; an administrator without an authenticator sees why it will not open. To keep it off, set ZANSKAR_CONSOLE_CLI=off in /etc/zanskar/env before restarting.

Zanskar v1.2.2

4 October 2026, fixes on top of 1.2.1

Moving a target no longer looks like an attack, WinRM sessions on Windows autoscaling groups can fail over again, recordings waiting to upload to S3 cannot be swapped by another user on the machine, and the console reads in plain words throughout.

• Moving a target starts its trust afresh: saving a new address clears the trusted host key and pinned certificates, so you probe and trust it again. Before, the old key stayed trusted and the next connection was refused as a host key mismatch, audited like an attack. The console warns before you save.
• WinRM failover on autoscaling: when a Windows instance is lost, a WinRM session offers to move to another instance again.
• Private recording spool: with S3 storage, the gateway refuses a spool folder it does not own or that others can write to, so a recording cannot be swapped before upload. The package service and the containers were never exposed.
• Plain words: access requests read as sentences in Events, a deleted user is named as such, protocols read as SSH, RDP, VNC, WinRM and database, and dates read as dates.
• Smaller fixes: the session file panel works from the keyboard, long database endpoints no longer break names, confirming an already-confirmed authenticator answers 409 instead of 500, and the chart's migration job has limits.
• Tested more thoroughly: 80% of the gateway's own code is exercised by tests, including whole terminal, desktop, WinRM and database sessions; several of these fixes were found that way.

Install Release on GitHub

Upgrading from 1.2.1 to 1.2.2

Install the new package, or set ZANSKAR_VERSION=1.2.2, and restart. No migration runs and no setting needs to change. One behaviour change: saving a target with a different address clears its trusted host key and certificates; probe it and trust it again. If you run the gateway by hand with S3 recording storage on a shared machine, set ZANSKAR_RECORDINGS_SPOOL_DIR to a private directory such as /var/lib/zanskar/spool.

Zanskar v1.2.1

1 October 2026, a security update to 1.2.0

Database connections are verified by default, the master key can live in a file of its own, and every release file now comes with a software bill of materials, signed build provenance and a build anyone can repeat.

• Database TLS verified by default: a new database target checks the database's certificate and needs its CA bundle (for Amazon RDS, your region's bundle). Encrypted, not verified is still there as an explicit choice, with a warning on the target. Existing targets keep the setting they had.
• The master key in its own file: ZANSKAR_MASTER_KEY_FILE keeps the key out of the environment file. The file must be readable by its owner only, and zanskar key rotate-master rewrites it in place.
• Key rotation cannot strand the key: rotation used to re-encrypt the database before saving the new key, so a failed save could lose it. It now checks it can save first, and prints the key if the save still fails.
• Release files you can check: an SPDX bill of materials beside each archive, SLSA level 3 build provenance for every file (check it with slsa-verifier), and builds that give the same bytes when you rebuild the tag.

Install Release on GitHub

Upgrading from 1.2.0 to 1.2.1

Install the new package, or set ZANSKAR_VERSION=1.2.1, and restart. A migration at start writes prefer, the setting they already used, into database targets that had none, so no existing connection changes; move each to Verified once you have its CA bundle. API change: creating a database target without tls_mode now requires tls_ca; send "tls_mode": "require" to keep the old behaviour deliberately.

Zanskar v1.2.0

30 September 2026, after two release candidates

What the 1.0 manual QA round asked for. An install that serves HTTPS out of the box, MySQL and MariaDB alongside PostgreSQL, keyless SSH through a certificate authority as the recommended Linux path, guided AWS enrolment, and a console that owns its runtime settings, recording storage and logs.

• Install and TLS: zanskar init defaults to a gateway-managed certificate on 443 with plain HTTP redirected; a self-signed certificate at first start, the real one uploaded on the Settings page and served on the next connection. Existing installs keep their behaviour.
• Databases: MySQL and MariaDB sessions through the gateway's own relay sidecar, a Databases page separate from Hosts, a database name and a TLS mode per target up to verify-full, and a credential slot that can be vaulted, user-supplied or empty.
• Keyless SSH: the certificate authority is generated in the console, which prints the TrustedUserCAKeys commands for each target; one principal per session certificate, a key id naming the Zanskar user in the target's auth log, an allowlist of login users, and a two-phase rotation with a certificate login test per target.
• AWS: the gateway detects its own principal; enrolment previews the trust policy with the real principal, a CLI script and a CloudFormation template that create the role, and tests the role before saving, naming the failing stage. Windows autoscaling groups serve RDP and WinRM sessions, each instance pinned to the certificate it first presented.
• Access control: per-target protocol rules inside one policy, one open request per target with editable and extendable grants, retention per policy and per target.
• Operations: Settings applied live with install-time values read-only, a restart-required banner with a drain, recording storage in an S3-compatible bucket configured and moved from the console, a Logs page, zanskar key status | rotate | rotate-master.
• Onboarding and audit: a one-time password for new local users replaced at first sign-in, auditor accounts strictly review-only, recording and transcript download audited, targets retired rather than erased, names instead of ids everywhere.
• Console: Events and Recordings inside the admin console below Logs (the audit portal is for auditor-only accounts), audit details that read Authenticator enrolled rather than an action code, and a logo that takes you back to the first page.

Release on GitHub

Known limitations in 1.2

• Single instance only; more than one replica breaks cross-pod admin terminate and auditor shadowing, and the Helm chart stays a preview.
• Database sessions need Docker or Podman on the gateway host and are not available inside the Compose stack; the MySQL and MariaDB relay is the gateway's own image, pulled on first use.
• No SAML, SCIM or WebAuthn. Windows and database passwords are not rotated by Zanskar; the certificate authority removes the need for SSH key rotation.

Upgrading from 1.0.0

Install the new package or set ZANSKAR_VERSION=1.2.0 and restart. Migrations run at start and rewrite no data. TLS behaviour is unchanged for an existing install; only a fresh zanskar init defaults to managed TLS on 443. ZANSKAR_AWS_GATEWAY_PRINCIPAL can be dropped on EC2 and EKS gateways, which now detect it.

Zanskar v1.0.0

25 September 2026

The first stable release. Zanskar reached it after two release candidates: rc.1 caught a signing break in the release pipeline before anything was published, and rc.2 passed pipeline verification and a clean-machine install test on both documented paths.

• Sessions: SSH and WinRM terminals, RDP and VNC desktops through guacd, PostgreSQL through a credential-isolating proxy sidecar, SFTP file transfer beside the terminal.
• Access control: users, groups and three roles; local accounts with Argon2id and mandatory TOTP, or OIDC and LDAP/AD; tag-based policies with time windows, session limits and clipboard/file switches; host-key and certificate pinning with admin approval.
• Just-in-time access: approval-required policies, time-boxed grants, an Approvals queue, automatic expiry, full audit trail.
• Autoscaling: AWS Auto Scaling groups via a cross-account role and EC2 Instance Connect, with failover when an instance disappears.
• Audit: recorded sessions with command-seek playback, live shadowing and terminate, hash-chained audit log with verify, SIEM export, recording retention.
• Operations: zanskar init, hardened systemd unit in deb/rpm packages, Docker Compose stack with Caddy TLS, backup and restore.
• Supply chain: every artifact checksummed and keyless-signed with Sigstore, multi-arch image on ghcr.io, pinned CI, OpenSSF Scorecard and Best Practices badges, CodeQL clean.

GitHub release v1.0.0

Known limitations in 1.0

• Single instance only. More than one replica breaks cross-pod admin terminate and auditor shadowing; the Helm chart is a preview until that control channel lands.
• Database access supported PostgreSQL only; MySQL and MariaDB arrived in 1.2.0 through the gateway's own relay sidecar.
• Database sessions need Docker or Podman on the gateway host and are not available inside the Compose stack.
• No SAML, SCIM, WebAuthn or automatic credential rotation yet.

What comes next

Next, decided after 1.2: a restricted admin CLI in the console, opened from its top-right corner the way a firewall's is. It runs a fixed set of zanskar operations inside the gateway, never a system shell, and records every command in the audit log. It will ship with a reference of every command and how to use them.

Phase 4: the cross-pod control channel that unlocks high availability and makes the Helm chart a supported path, SAML and SCIM, WebAuthn, delegated and multi-step approvers, access reviews, and GCP and Azure scale sets. Follow the roadmap.

1.2.0 was reached through two release candidates. rc.1 was retired because saving a policy from the console failed and Windows autoscaling groups could not serve sessions; rc.2 was installed and tested on a clean Ubuntu 24.04 host, and what that test found (the cosign step, readable audit details, Events and Recordings in the admin console, the logo link) is in 1.2.0.

Upgrading from a release candidate: 1.0.0-rc.1 and rc.2 share the schema with 1.0.0. Install the new package, or set ZANSKAR_VERSION=1.0.0 and pull; migrations are a no-op.