Announcing Wardengate v2

Wardengate v2 is the largest release we have shipped. It is not a rewrite — your v1 policies import cleanly, your operators will not notice the change in their day-to-day workflow — but it is a serious consolidation. Eighteen months of field feedback, five major customers co-designing the audit surface, and a rebuilt policy engine that we have been running in shadow mode against production traffic for the last quarter.

This post is the marketing summary written by the person who actually wrote the code. It covers what changed, why, and what the upgrade looks like.

A new policy engine

The v1 policy engine was flexible. Sometimes it was too flexible. Customers wrote policies that took 400ms to evaluate under load, because the engine had no way to cache the intermediate results. The v2 engine is more opinionated: rules are compiled into a decision graph at load time, and every evaluation is a walk of that graph with memoized condition checks.

The practical effect: p99 policy evaluation latency on the beta cohort dropped from 180ms to under 8ms, measured against the same rule sets. Your rules do not change. The engine simply pre-computes more of the work before a session is ever requested.

Kubernetes as a first-class target

In v1, Kubernetes access was possible but bolt-on — you could broker kubectl through an SSH-ish tunnel and it mostly worked. In v2, the Kubernetes API is a native target type. Policies refer to namespaces, resources, and verbs directly. Session evidence captures the API calls the operator made, not just the kubectl command line.

• Native brokering of kubectl, including exec and port-forward, with per-verb policy enforcement.
• Command evidence captured at the API level, so an auditor can answer 'what did this operator do in the cluster' without reconstructing it from shell history.
• Scoped ephemeral service accounts minted at connect time, replacing long-lived kubeconfig files.

A redesigned admin console

The admin UI was the most common complaint in v1. It was functional, and nobody liked it. The v2 console is a clean rewrite. The primary surface is the session ledger — the list of every brokered session, filterable, searchable, and linkable to evidence. Policy editing is inline with syntax-aware suggestions. Integration configuration is, finally, not a YAML file hidden three menus deep.

Upgrade path

The upgrade path is the same as every Wardengate minor release, with one addition. The control plane upgrades in place; policies import automatically with a validation report; and the new policy engine runs in shadow for 48 hours by default before taking over primary evaluation. The shadow mode writes both decisions to the audit log so you can confirm parity before flipping the switch.

# Typical upgrade
$ wardengate upgrade --to 2.0
✓  control plane upgraded
✓  policies imported (42 rules, 0 warnings)
✓  shadow evaluation enabled for 48h

# After 48h, flip over
$ wardengate policy engine promote v2
✓  v2 engine is primary
✓  v1 engine retained for 7d, then removed

What is not in v2

We deliberately kept a few things out. There is no hosted offering yet — v2 remains self-managed or managed-by-partner. There is no new pricing shape; existing contracts carry forward. And there is no agent on the target hosts. The gateway still terminates protocols at the edge; the targets do not get a new sidecar. That was the right call in v1 and it is still the right call.

Thanks

A release of this size is the work of a lot of people who do not write the blog post. Thanks to the five design-partner customers who ran the beta in production, filed real bugs, and pushed back on ideas that sounded clever but would have shipped poorly. Thanks to the Wardengate engineering team for the long autumn of shadow-mode telemetry-chasing. And thanks to everyone running privileged access on us — v2 is what it is because of what you told us about v1.