04 · Zero-Trust Security & Automated Governance

Milestones of the roadmap items in this theme

As of 2026-10-22 · today

Gantt

Milestones

#	Milestone	Start	Target	Status	Waits for	Team	Epic	Derived
12 · Dynamic Secrets Engine (Vault)
12.1	Vault highly available and audited, with no long-lived root tokens	2026-08-03	2026-11-27	in progress	—	SRE	—	—
12.2	Database credentials issued dynamically	2026-09-24	2027-01-29	in progress	12.1	SRE	—	waiting 12.1
12.3	Application secrets out of config and into Vault	—	2027-09-10	planned	12.2	SRE	—	waiting 12.2
12.4	SSH certificates, short-lived and issued per session	—	2028-01-14	planned	12.3	SRE	—	waiting 12.3
12.5	Backstage carries the request and approval; Vault grants without showing	—	2028-05-19	planned	12.3, 22.3	SRE	—	waiting 12.3, 22.3
12.6	阿諾 contained — interim controls on what exists today	2026-10-12	2027-03-21	planned	—	SRE	—	—
12.7	Oracle changes through Superset on per-person Vault accounts; 阿諾 retired	—	2027-09-10	planned	12.2	SRE	—	waiting 12.2
13 · Zero-Trust Network Access (NetBird)
13.1	NetBird control plane self-hosted, highly available, and built from code	2026-09-01	2026-12-18	in progress	—	SRE	—	—
13.2	Reachability by policy group and device posture, not network location	—	2027-07-16	planned	13.1	SRE	—	waiting 13.1
13.3	NetBird required for all access; Warpgate brokers the services that need it	—	2028-03-10	planned	12.4, 13.2	SRE	—	waiting 12.4, 13.2
13.4	Sites, servers and people on the NetBird overlay	—	2028-07-14	planned	13.3	SRE	—	waiting 13.3

Details

12.1Vault highly available and audited, with no long-lived root tokens2026-11-27in progress · 1/4

• Vault deployed and serving its first application consumersowner · Charles

  The starting point, not the milestone — what follows is what makes it safe to put every other credential behind it.
• Seal, unseal and recovery rehearsed, not merely configuredowner · TBD

  Every credential in this item ends up behind Vault, so an unseal nobody has practised is an outage with no way back in.
• Login through Zitadel OIDC; no long-lived root tokensowner · TBD

  A root token that outlives a session is exactly the kind of credential this item exists to eliminate — starting with the one guarding the engine itself.
• Audit device shipping to the log platformowner · TBDarchitecture →

  The audit-log architecture already lists Vault (ssh / db) as an event source; this is where that becomes true rather than drawn.

12.2Database credentials issued dynamically2027-01-29in progress · 2/8

• A secrets engine per database, with a TTL short enough to matterowner · TBD

  A one-year TTL is a static password with extra steps; the length is what decides whether a leaked credential is an incident or a non-event.
• Static application database passwords retired, not merely rotatedowner · TBD

  Rotation leaves the mechanism in place and buys one cycle. Retiring the static path is what makes the dynamic one the only one.
• Databases provisioned under item 06 issue through Vault from the startowner · TBD

  A database that arrives with a static password has to be cleaned up later; wiring the two at provisioning time costs less than a second sweep.
• Access revocable per identity, and revocation actually testedowner · TBD
• Oracle served by Vault's database plugin — Instant Client built into the Vault image and the plugin registeredowner · TBD

  Oracle's plugin is not built into Vault and needs the Oracle client libraries beside it, so the Vault image has to carry them. Every production change in 12.7 runs on a credential issued this way.
• The primary and its DataGuard standby both coveredowner · TBD

  Accounts are created and dropped on the primary only; the standby receives them through redo, and sessions left on it are closed by the profile within 15 minutes. Verified 2026-09-30 together with issue, expiry and revocation of a connected account.
• Separate read and write Oracle accounts from the DBA's RO and RW roles, with a one-hour TTL and no renewalowner · TBD
• The Vault configuration for Oracle merged to the IaC repository's main branch, so main can be applied againowner · TBD

  Until then the live configuration exists only on a branch and main is stale; applying from main would undo it.

12.3Application secrets out of config and into Vault2027-09-10planned · 0/4

• Inventory of where secrets live today: config files, images, CI variablesowner · TBD
• Applications read secrets at runtime instead of having them baked at buildowner · TBD

  A secret baked into an image is published to every registry that image reaches, and rotating it means a rebuild.
• CI receives short-lived tokens rather than holding standing credentialsowner · TBD
• Item 21's secrets scanner used as the independent checkowner · TBD

  Self-reporting that the secrets are gone is weaker than a scanner that was already looking for them and stops finding any.

12.4SSH certificates, short-lived and issued per session2028-01-14planned · 0/4

• SSH CA in Vault issuing host and user certificatesowner · TBD
• Static keys removed from hosts once certificates carry the trafficowner · TBD

  1.2 replaced shared keys with per-user ones, but those still outlive a session; this is the step that ends that.
• Issuance recorded per session in the log platformowner · TBDarchitecture →
• The milestones that named this as their target, and why no dependency is drawnowner · TBD

  1.2 (2027-03-12) and 5.2 (2027-01-01) both name Vault as the eventual issuer, but both fall due long before this milestone — SSH is third in the agreed order. An edge would have to point forward in time, so in those two the target stays text.

12.5Backstage carries the request and approval; Vault grants without showing2028-05-19planned · 0/5

• Request and approval are a Backstage flow, not a ticket or a chat messageowner · TBD

  A request has to be a record with a shape before it can be approved consistently, or audited at all. 22.3 builds that flow and this milestone waits on it; item 12 decides what an approval is allowed to hand over.
• The approver is named and the reason recordedowner · TBD

  An approval nobody is named for is a rubber stamp; the name is what makes the record worth keeping.
• Approval binds a Vault policy to the requester's identity with an expiry — it never copies a secretowner · TBD

  The same Zitadel identity 12.1 establishes, carried through. If approval hands over a copied value, every approval is permanent whatever was intended, because a copy has no expiry — so this is the difference between an approval that means "for a period" and one that means "forever".
• Backstage shows where a secret lives, never its valueowner · TBD

  A value shown in a portal is a value in browser history, in a screenshot, and in whatever the reader pasted it into. This is the line between authorising access and handing out the secret, and it gets traded away as a convenience if it is not written down.
• Request, approval and issuance readable as one trailowner · TBDarchitecture →

  The audit-log architecture already lists Backstage and Vault side by side as M2M sources; a request and the issuance it caused should be readable as one story rather than joined by hand afterwards.

12.6阿諾 contained — interim controls on what exists today2027-03-21planned · 0/6

• Baseline published and re-measured monthly from 阿諾's own execution logowner · TBD

  12 months to 2026-10-08: 23,290 executions, 85.7 % of them writes, by 73 people on 7 Oracle databases; 41 % of writes carried no request number and 13 UPDATE / DELETE statements had no WHERE. The monthly re-measure is what shows whether the controls below are holding.
• A request number is mandatory for every write — 阿諾 refuses a write without oneowner · TBD
• Write permission limited to named people per database; everyone else read-only; leavers removedowner · TBD
• UPDATE and DELETE without WHERE refusedowner · TBD
• Oracle Unified Auditing records DML by 阿諾's database accountowner · TBD

  A check independent of the tool's own log: a log the tool writes about itself cannot show what the tool failed to record.
• Reads move off 阿諾 to Superset's read account as soon as it is open to engineersowner · TBD

12.7Oracle changes through Superset on per-person Vault accounts; 阿諾 retired2027-09-10planned · 0/8

• Superset is the one entry for Oracle, reading and writing, with OIDC loginowner · TBD
• Read and write are separate database accounts; each engineer gets the one matching the permission applied for, and write permission is approved by a named approver with the reason recordedowner · TBD

  The approver is the data owner, with a DBA added for high-impact changes. The application is recorded now and moves onto the Backstage flow when 12.5 lands.
• Superset logs in to Vault per person over OIDC, replacing the AppRole whose secret_id never expires; account names carry the personowner · TBD

  A secret_id that never expires is a standing credential held by the tool — the thing item 12 exists to remove. With per-person login, Oracle's own audit names the engineer rather than a random account.
• Guardrails on the write path — UPDATE and DELETE without WHERE, and DDL, refusedowner · TBD

  DDL goes through the schema migrations of 6.2.
• Decision recorded on per-statement approval and backup before execution — accepted as a stated risk, or covered by a review tool in front of writesowner · TBD

  Superset provides neither. Leaving the gap unstated would let the move to Superset read as if it closed it; either answer is acceptable, an unrecorded one is not.
• Superset's query log, Vault's audit and Oracle Unified Auditing land in the audit logowner · TBDarchitecture →
• Emergency changes through Warpgate (13) with the session recorded, reviewed afterwardsowner · TBD
• 阿諾 retired — its write path closed, then the tool removed; its log kept as historyowner · TBD

13.1NetBird control plane self-hosted, highly available, and built from code2026-12-18in progress · 1/4

• NetBird trialled in the develop environmentowner · Charles
• Control plane self-hosted and highly availableowner · TBD

  Self-hosting swaps a dependency on someone else's uptime for a dependency on ours; HA is what makes that a gain rather than a trade.
• Every peer carries an identity from Zitadel SSOowner · TBD
• The control plane itself provisioned from code, not hand-builtowner · TBD

  It becomes the way in to everything else — a hand-built one is precisely the host you cannot reach when you most need to rebuild it.

13.2Reachability by policy group and device posture, not network location2027-07-16planned · 0/4

• Policy groups expressed as code and reviewed like any other changeowner · TBD
• Device posture checked at connection timeowner · TBD
• Being on the office network grants nothing by itselfowner · TBD

  This is the sentence that separates zero trust from a VPN. Until location grants nothing, the overlay is just a longer cable.
• Exceptions are entries with an owner and a review dateowner · TBD

13.3NetBird required for all access; Warpgate brokers the services that need it2028-03-10planned · 0/5

• No path in that does not start with NetBird, except 1.3's sealed break-glassowner · TBD

  This is the property that makes the milestone true, and it belongs to NetBird. 1.2 built the bastion path; this puts NetBird in front of it rather than removing it — and the claim only holds once the other ways in are shut.
• Which services require a broker, decided and written downowner · TBD

  "Some services" is not a specification. Without a written rule the set becomes whatever was convenient as each service was onboarded, and the exceptions cannot be reviewed because there is nothing to review them against.
• Warpgate deployed for those services, reachable only through NetBirdowner · TBD

  Most services are reached directly once a peer is on NetBird. Warpgate is the extra layer for the ones where the session itself must be recorded, or where credentials must not reach the client.
• Brokered sessions carried by the SSH certificates from 12.4owner · TBD

  The layer and the short-lived credential that passes through it arrive together — which is why 12.4 is scheduled ahead of this milestone rather than after it.
• Brokered sessions recorded to the log platformowner · TBDarchitecture →

13.4Sites, servers and people on the NetBird overlay2028-07-14planned · 0/4

• Site-to-site and server connectivity carried by NetBirdowner · TBD

  This traffic rides no overlay at all today, so nothing is being migrated — it is the first time these paths carry an identity rather than just an address.
• People access on NetBird, with the same identity and posture rulesowner · TBD
• Tailscale's separate job stated and left alone: DNS forwarding between sitesowner · TBDarchitecture →

  The two overlays never overlapped, so NetBird neither absorbs Tailscale nor obsoletes it. Every site forwards corp.internal to its own Route 53 inbound endpoint across it — removing it as tidy-up would take private resolution down at all three sites at once.
• That scope written into the DNS architecture pagesowner · TBDarchitecture →

  So the next person to find a Tailscale dependency reads why it is there instead of removing it.

Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.