Platform Security Engineer — IAM · Secrets · PKI

Zero-Trust access, for every kind of identity that shows up

A human at a terminal, a browser session behind SSO, an AI agent running Terraform on my behalf — none of them get a standing key. Every one of them authenticates, is issued a short-lived credential, and is audited the same way. This is that access model, the infrastructure it protects, and a real application running on top of it.

Scope
Hybrid — 2 hypervisors, 2 Raspberry Pi's, and a cloud VPS, interconnected
Operator
Solo — design, build, and day-2 operations
Status
Live — this page is served through the tunnel described below
Access model

Three kinds of identity, one boundary

"Zero trust" is easy to say about SSH and forget everywhere else. Here it applies uniformly — to the person operating the infrastructure, to whoever uses the application running on it, and to the AI tooling that now writes a good share of the Terraform and Ansible itself.

Human — operator

MacBook, Terraform, Ansible

Every change starts on one workstation with no fixed credential. A client certificate buys a session-scoped Vault token. Away from home, a Tailscale mesh makes the LAN reachable first — the same Vault/Boundary flow then runs exactly as if I were physically there.

Human — end user

Browser → tunnel → SSO

The public domain resolves through Cloudflare's edge into an outbound-only tunnel running inside the cluster — no port ever opened on the home network. From there, login is one OIDC exchange against the identity provider; the app never handles a password.

AI — coding agents

Same laptop, same boundary

Claude, Gemini, and local models via Ollama write and run Terraform, Ansible, and Kubernetes changes on this environment — through the same workstation, under the same short-lived Vault credential as a human session. No separate service account, no wider scope, no standing key issued just because the operator is an AI this time.

Topology

One private network, fully brokered

Two hypervisors carry a Ceph-replicated storage pool underneath a kubeadm-built Kubernetes cluster and a dedicated identity stack. Nothing is reachable except through the broker below.

brokered session, no standing tunnel
Ceph RBD, replica ×2

Click any box for detail · open the full network diagram ↗

Select a node above to see what runs there and why it matters.

Access flow

Every session is issued, never standing

There is no VPN client and no key sitting on disk. Reaching any host — even the ones I administer daily — goes through the same three-step exchange.

01

Certificate login to the vault

The workstation authenticates with a client certificate. In exchange it receives a token — nothing longer-lived than the task at hand.

02

An SSH certificate is signed, not stored

The vault's SSH engine signs a fresh client certificate scoped to one principal. It self-invalidates five minutes later, no revocation step needed.

ttl 05:00
03

The broker authorizes and tunnels the session

Identity is confirmed via the single sign-on provider, the broker opens an audited tunnel to the target, and the certificate expires the moment the session ends.

Controls

What "zero trust" means here, concretely

Zero trustEvery SSH session is brokered and audited; no standing VPN exists to the network.
Internal PKIA private root and intermediate CA issue every internal TLS certificate, propagated into Kubernetes automatically.
Centralized secretsOne versioned secrets store; nothing sensitive is ever committed to Git in the clear.
Temporary credentialsSSH access rides on five-minute certificates — there is no long-lived key to leak.
Federated identityA single sign-on provider fronts every internal application and the access broker itself.
Infrastructure as codeThe entire environment is defined in version control and rebuildable from it.
GitOpsCluster state is continuously reconciled from Git — no manual `kubectl apply` for anything it manages.
Deployed system

Not just infrastructure — a running product

The cluster above isn't idle. It currently runs a full-stack athlete-performance tracking application I designed, built, and ship updates to on the same pipeline — including the SSO login flow from the access model above.

An athlete-tracking platform, in production

A FastAPI backend and a React frontend, backed by Postgres and object storage for progress photos, with an LLM integration and a scheduled reporting job.

build image push to private registry rolling deploy schema migration health check
Read the full case study ↗
Stack

Tools, not buzzwords

Terraform Ansible HashiCorp Vault HashiCorp Boundary Tailscale Cloudflare Tunnel Keycloak Kubernetes (kubeadm) Argo CD Rancher Prometheus Grafana Ceph Docker FastAPI React PostgreSQL

Next: an OpenShift single-node instance alongside the kubeadm cluster — same workload model, in progress alongside a Red Hat OpenShift certification.