Zanskar is an open-source, agentless access gateway. People sign in once, pick a target, and
get a terminal (SSH, WinRM), a desktop (RDP, VNC), a database session (PostgreSQL, MySQL,
MariaDB) or a web application, in the browser. The gateway authenticates to the target with a
credential the person never sees, records the session, and writes every step to a hash-chained
audit log. Access can be standing or granted just in time on approval, and it ends the moment
it is taken away.
Why Zanskar
- Agentless, and the browser never touches the target. Targets are reached over SSH, RDP, VNC,
WinRM or the database's own protocol, from the gateway only. No agent, no inbound exposure, no
client software.
- Fleets that change are first-class. Enrol an AWS Auto Scaling group through a read-only
role; Zanskar tracks the healthy pool and, when the instance you are on is terminated, offers a
switch to another instead of a dead terminal.
- Evidence for everything. Recorded sessions, audited reads of those recordings, a
hash-chained audit log anchored by signatures and verifiable from the command line, SIEM export,
and releases signed with Sigstore.
What you get
| Capability | What it does |
|---|
| Terminals | SSH to Linux and PowerShell over WinRM to Windows, streamed over WebSocket and recorded as asciicast. SFTP beside the terminal, gated per policy. |
| Desktops | RDP and VNC through a guacd sidecar, recorded as a pixel stream, shadowable live by auditors. Clipboard and drive redirection are policy switches. |
| Databases | psql, mysql and mariadb sessions through a per-session client container. The database credential lives in a sidecar and never reaches the client, not even from a shell escape. TLS to the database is per target, up to verify-full with your CA bundle. |
| Web applications | An internal web application opens in a sandboxed Chromium container beside the gateway, streamed and recorded like a desktop, on a private network that reaches the application's one port and nothing else. Needs a container runtime on the gateway host, as database sessions do. |
| Keyless SSH | An SSH certificate authority that mints a minutes-long certificate per session, naming the Zanskar user in the target's own log. One TrustedUserCAKeys line per target, and a two-step rotation that never locks a host out. Vaulted passwords and keys remain for everything else. |
| Just-in-time access | A policy can grant eligibility instead of standing access: the user asks with a reason and a duration, an administrator approves, and the grant is time-boxed, extendable and expires on its own. |
| Identity, kept separate | Local accounts with Argon2id and TOTP, or OIDC and LDAP / Active Directory sign-in with audited group-to-role mapping. Who you are to Zanskar is distinct from how Zanskar reaches a target. Three roles: admin, auditor, user. |
| Access taken away ends the session | Disabling an account, changing its groups or revoking a policy ends the live sessions that access allowed, and tells the user why. |
| Operated from the console | HTTPS out of the box with a certificate the gateway manages, runtime settings applied live, recordings on local disk or an S3-compatible bucket, restart, update and host actions behind a fresh authenticator code, a Logs page, and an audited command line inside the console. |
Install
Zanskar is one static binary with the console inside it. On a Linux server:
- Download the
.deb or .rpm for your architecture from the latest release and install it. Checksums are signed with Sigstore; the install guide has the cosign verify lines.
- Run
sudo zanskar init. It writes the configuration, serves HTTPS on 443 with a certificate it manages, creates the first administrator and prints what to do next.
- Open the gateway's address in a browser, sign in, enrol your authenticator, and add a target.
For a container: ghcr.io/albatroxxx/zanskar with deploy/docker-compose.yml brings up the gateway, guacd and Caddy for TLS. Desktops need the guacd sidecar; database and application sessions need Docker or Podman on the gateway host. The full picture, from topology to backups, is in docs/deploy.md.
To build from source you need Go 1.27 or newer and Node 22 or newer; CONTRIBUTING.md has the development setup.
A look inside
How it works
Browser ──HTTPS/WSS──▶ zanskar gateway ──SSH / WinRM / SFTP──────────────▶ Linux, Windows
│ │ │
│ │ └──Guacamole protocol──▶ guacd ──RDP/VNC─▶ Windows, VNC hosts
│ │ └─VNC──▶ isolated browser ──▶ web applications
│ └── per-session client container ─▶ relay sidecar ─PG / MySQL─▶ databases
│ (internal network; only the relay, which holds the
│ credential, reaches the database)
│
├── SQLite or PostgreSQL (state, sealed secrets, audit chain)
├── recordings: local disk or S3-compatible storage
├── identity providers: OIDC, LDAP / Active Directory
└── AWS APIs: STS AssumeRole, Auto Scaling, EC2
One Go process: the API, the embedded React console, the protocol bridges and the audit chain.
Secrets are sealed under a versioned master key; the audit log is hash-chained and anchored by
signatures, so even its newest events cannot be removed unnoticed. Every design choice links to an
architecture decision record, and docs/architecture.md walks
through a session end to end.
Status. Zanskar runs as a single instance: one gateway, embedded SQLite or your PostgreSQL,
a guacd sidecar for desktops. High availability is planned; the Helm chart deploys one pod and is
a preview until live sessions can be ended and watched across gateways.
Documentation
| Where | What it covers |
|---|
| Install | Packages, the container, zanskar init, TLS, updates |
| How-to guide | Every console page, from the first host to the audit log |
| Concepts | Targets, credentials, policies, grants, sessions, recordings |
| Troubleshooting | The exact messages a tester meets, and what they mean |
| docs/deploy.md | Topology, backups, recording storage, database access, AWS enrolment, the certificate authority, the security checklist |
| docs/architecture.md | How the gateway is built, package by package |
| docs/threat-model.md | Trust boundaries, what is defended against, what is not |
| docs/adr/ | The decisions behind the design, with their reasoning |
| docs/api/openapi.yaml | The HTTP API the console uses, which is the API you get |
| docs/console-cli.md | Every command of the console's command line |
| Release notes |
Quality and security signals
Every badge at the top is computed from this repository by an open-source tool and links to its evidence.
| Badge | What it measures | Source |
|---|
| CI | Build, go vet, race tests on SQLite and PostgreSQL, golangci-lint, govulncheck, gosec, gitleaks, OSV-Scanner, Trivy on the source tree and the built container image, a browser end-to-end suite, the third-party-notice check, on every push and pull request | ci.yml |
| CodeQL | Static analysis of the Go server and the TypeScript console with the security-extended query suite; alerts appear in the Security tab | codeql.yml |
| OpenSSF Scorecard | Supply-chain hygiene scored 0 to 10 by the OpenSSF: pinned dependencies, token permissions, branch protection, SAST, vulnerability status, and more | scorecard.yml |
| OpenSSF Best Practices | The OpenSSF Best Practices criteria for open-source projects: a documented contribution and vulnerability-reporting process, tests and CI, static and dynamic analysis, published cryptography, secure delivery. The answers are public and linked to their evidence | project 14924 |
| Test coverage | Statement coverage of the gateway's own code from the CI test run, written to the badges branch after each push to main | ci.yml |
| Go version | Read from go.mod | shields.io |
The published images are re-scanned by Trivy every week, because new advisories appear after a
release; findings land in the Security tab (image-scan.yml).
Releases carry an SBOM, SLSA provenance and Sigstore signatures, and the builds are reproducible
across machines.
Contributing
Contributions are welcome. To report a bug or suggest something, open an issue; the bug report
and feature request forms walk you through what to include. CONTRIBUTING.md
has the development setup, the checks that must pass before a pull request, and the project's
conventions. The short version:
make all # linters, race-detector tests, the console build and its tests, the binary
How the project is run and how decisions are made is in GOVERNANCE.md; everyone
taking part follows the code of conduct. The answers behind the project's
OpenSSF Best Practices badge are in docs/best-practices.md.
Security
Zanskar is an access gateway, so security reports matter. SECURITY.md says how to
report a vulnerability privately; never open a public issue for one. The
threat model describes what Zanskar defends against and what it does not.
License
Apache License 2.0; see LICENSE. The third-party components compiled into the binary
and their license texts are in THIRD_PARTY_NOTICES.md, and the bundled
non-code assets in THIRD_PARTY_LICENSES.md.
Zanskar is named after the Zanskar Valley in Ladakh, in
the Himalayas of northern India. The logo is a shell prompt redrawn as a summit and a cursor.
