ASTIS Workload Secrets
Infrastructure access ≠ data access — for Kubernetes
Your secret decrypts only inside the attested pod it is bound to — in RAM, at use time. An admin's kubectl, a leaked etcd backup, or an AI agent with cluster-read gets ciphertext. A breached node exposes the services scheduled on it — not the cluster.
Don't take that on faith: the pod-side clients are open source, so you can verify yourself that plaintext — and even the business-data ciphertext — never leaves the pod. Only a wrapped key and a proof cross the wire.
Trust the math, not the vendor — see the round-trip ↓
WHAT WE BUILT
Separate infrastructure access from secret access
ASTIS adds a data-security boundary to Kubernetes. Only the application SDK inside an approved live pod can decrypt the secret locally, when needed. Stored Secrets, manifests, read-only Secret API access, and backups expose ciphertext only.
WHO SEES WHAT
Sealed-envelope pathKubernetes storage & readers
Secrets API, manifests, backups
Ciphertext only
ASTIS edge
Authenticate + route
Wrapped DEK only
Application SDK in approved pod
Decrypts locally when needed
Plaintext on demand
Who can read your secret?
ASTIS Workload Secrets
Only the attested pod the secret is bound to — verified against your cluster, fail-closed. Verifiable in the open client code.
Vault / OpenBao
Any client whose token and policy cover the path — plus whoever operates the server. Delivery into k8s commonly ends in plaintext files or Secrets.
Cloud KMS / Secrets Manager
Anything cloud IAM authorizes — with the provider operating the keys. Mounted results are plaintext in the workload.
Deployment patterns vary — see the row-by-row comparison with sources.
The problem
A Kubernetes Secret is base64-encoded, not encrypted by default — and even with etcd encryption-at-rest enabled, anyone with get secrets RBAC or node-root still reads the plaintext, because the API server decrypts it on every read. Encryption-at-rest protects etcd files and backups, not API access — and the key is held by the cluster, not you. A DevOps engineer, your hosting provider’s control plane, a compromised node — the blast radius of “infrastructure access” quietly includes your database passwords, API keys, and signing keys.
Three leaks that happen every year — before and after
Not a diagram — what the attacker actually reads in each case.
Over-scoped RBAC
An engineer, a CI job, or a vendor integration holds get secrets.
kubectl get secret db-creds -o json | base64 -d
Without ASTIS
password: hunter2… — usable plaintext, even with KMS encryption-at-rest on
With ASTIS
ASTIS:v2:eyJhbGc… — a sealed blob; read access is not decrypt access
etcd backup leaks
A snapshot lands in object storage; the bucket is misconfigured.
etcdctl snapshot restore backup.db && grep -a "password"
Without ASTIS
Every Secret in the dump, base64-decoded in seconds
With ASTIS
Sealed envelopes only — the org key never lived in the cluster
AI agent with kubectl
Your DevOps agent reads manifests, tails logs, runs pipelines.
agent → kubectl get secrets --all-namespaces
Without ASTIS
Cluster-read quietly includes every credential the agent can list
With ASTIS
It operates the cluster all day and never holds a decryptable secret
And the failure mode is bounded: one key per service, unsealed only in that service's pods — a breached node exposes the services scheduled on it, not the cluster. Verified by a negative control: a renamed pod on an unapproved image is refused at unseal.
Four-layer workload release policy
A workload must clear all four gates to establish a release session. Each unwrap then requires the bound API key, the projected JWT, and a fresh DPoP proof under that verified session — strict, fail-closed by default.
Bound API key
The key is scoped to cluster + namespace + serviceaccount. A stolen key used anywhere else is rejected.
Pod-bound ServiceAccount JWT
The pod presents its projected SA token — carrying namespace, ServiceAccount, and the pod’s own name + UID. ASTIS verifies issuer, audience, expiry, and signature against your pinned cluster JWKS, then binds that exact pod identity to the request. The control plane itself vouches for the pod.
RAM-only DPoP + single-credential pin
An ephemeral Ed25519 key, generated in the pod at boot, signs every request (anti-replay, never persisted). While a pod session is active, one credential is pinned per live Pod UID — stolen bearer credentials cannot enroll a second; rotation requires proof signed by the previous key.
Live pod + approved image digest
Strict and fail-closed by default: ASTIS reads YOUR Kubernetes API with a read-only token, confirms the live Pod UID, and checks that every running image — app, init, sidecar, and ephemeral (debug) — has a sha256 digest in your approved allowlist. An unapproved image, including an injected debug container, is refused. (Audit mode is available as an explicit preview/dev opt-in.)
The round-trip
One capsule crosses the trust boundary. CVS converts the DEK to the approved pod’s ephemeral key; the application ciphertext remains in your cluster. Under HYOK CVS, that conversion also runs on your infrastructure.
YOUR CLUSTER
Kubernetes Secret
Ciphertext + wrapped DEK capsule
Stored locally
ASTIS CONTROL PATH
no application ciphertextEDGE
Verify workload
Authenticate + authorize
CVS
Rewrap DEK
To pod ephemeral key
CVS holds the DEK transiently in memory.
APPROVED POD
Application SDK
Decrypt secret locally in RAM
Plaintext: this pod's RAM, at use time — nowhere at rest
Neither application ciphertext nor secret plaintext crosses the ASTIS boundary.
Two trust tiers
Tier 1 — Standard
ASTIS manages the org key. Trust separation by architecture: infrastructure operators cannot recover plaintext from stored Secrets, manifests, backups, or read-only Secret API access.
Tier 2 — HYOK
The org key never leaves your own infrastructure. A compelled disclosure to ASTIS yields ciphertext only — math, not promises.
Runtime security boundary
ASTIS stops infrastructure access from silently becoming secret access. Stored Secrets, manifests, read-only Secret API access, and etcd backups reveal only ciphertext — and a stolen SA token or API key alone cannot unwrap: establishing a release session requires all four gates, and every unwrap requires a fresh DPoP proof under that session. What it does not claim:
- •application-process or node-level memory access after the application SDK decrypts the secret in RAM (
kubectl exec, node-root) - •combined compromise of the cluster’s active SA-token signing key and Kubernetes live-pod identity view — enough to mint a JWT accepted by the pinned verifier and fake the Pod API read
Read-only etcd or backup access is exactly what this protects — it yields ciphertext only. Harden the rest with distroless images, restricted exec/ephemeralcontainers RBAC, admission policy, and image signing. To close node-root itself, run on confidential-computing nodes (AMD SEV-SNP / Intel TDX) — that boundary is orthogonal to ASTIS and composes with it; validated TEE deployment guidance is on the roadmap.
ASTIS MCP generates the Kubernetes manifests, projected-token config, SecOps encrypt command, and the pod-side SDK flow — wired to the workload contract — so your AI coding agent builds the integration correctly.
Generate workload integration with ASTIS MCPProven on a real Kubernetes cluster. Self-serve in Portal.
The end-to-end round-trip is proven on a real cluster. Onboarding is self-serve in Portal — create an organization, add a domain, and bind workloads. SLA is included by plan. The pod-side clients are open source (Apache-2.0): astis-sdk and a deployable example in astis-kubernetes.