Phase E · Secrets

Stop copying secrets.
Start fetching them.

How Greentic is changing the way a cloud worker gets its passwords and API keys — in plain words.

?What is this even about

A Greentic "digital worker" runs in the cloud (on Kubernetes) and needs secrets to do its job — things like a Slack bot token, a webhook password, or an API key. The whole question of Phase E is simple:

The one question: How do those secrets reach the worker without leaving copies lying around where someone could steal them?

1The problem with how it works today

Right now, when you deploy a worker to a cluster, the tool takes the secret file from your laptop and copies it straight into the cluster, where it sits as a plain "Kubernetes Secret". The actual passwords live inside the cluster.

Think of it like: photocopying your house keys and taping a copy to the front door of every building you visit. Convenient for demos — but anyone who gets into that building now has your keys.

2The new idea

Don't copy any secret values into the cluster at all. Instead:

Keep the real secrets in a proper, locked safe — HashiCorp Vault.
Give the worker an ID badge (a Kubernetes "ServiceAccount") instead of the keys themselves.
When the worker starts, it shows its badge to Vault. Vault checks the badge and hands back a short-lived key — only for the secrets that worker is allowed to read.
Nothing sensitive is ever stored in the cluster. If someone breaks in, there's nothing to steal.

Left: the laptop's secret file is copied into the cluster. Right: only an ID badge lives in the cluster; the worker fetches secrets from Vault on demand.

3What's been built so far

The work is split into a "train" of small steps, one per part of the system. Here's where each one stands.

E.1

✓ Done · merged

The Vault connector learned to log in with a badge

The piece that talks to Vault can now authenticate using the worker pod's badge (Kubernetes auth) and trade it for a short-lived Vault key — no long-lived passwords baked in anywhere.

repo: greentic-secretsPR #94 merged

E.2

✓ Done · merged

The runtime learned to fetch secrets from Vault

While a worker runs, it now resolves its secret:// references straight from Vault — read-only, and locked to the correct team so one team can't read another's secrets.

repo: greentic-startPR #303 merged44 tests

E.3

◐ In progress · this session

The deployer learned to set up the badge — and stop copying secrets

When deploying to Kubernetes, the deployer now gives the worker its Vault ID badge and connection details, and skips copying the secret file into the cluster for Vault-backed environments. It picks dev-store vs. Vault automatically from the environment's settings.

repo: greentic-deployer 13 new tests pass format clean compiles PR: not opened yet

E.3b

⏳ Next

Connect the last wire in the runtime's boot path

One startup path still defaults to the old dev-store. It needs to read the "use Vault" signal and resolve secrets for the worker's tenant/team — the gap a review flagged during E.2.

repo: greentic-start

E.4

⏳ Next

Auto-configure Vault itself

A setup step that turns on badge-login inside Vault and maps each badge to a permission policy (what it's allowed to read), so an operator doesn't wire it by hand.

E.5

⏳ Next

Prove it end-to-end in a real cluster

A full demo in a local Kubernetes (kind) cluster: the worker pulls a real secret from Vault, and a check confirms there are zero secret values stored in the cluster.

→The bottom line

Half the journey is done and shipped (E.1 and E.2). The deployer change (E.3) is written and tested in this session and just needs its final checks and a pull request. After that, two wiring/setup steps and a final live demo will make the whole thing work end-to-end — at which point Greentic can deploy real customer workers without ever putting secret values inside the cluster.