ASTIS Workload Secrets
Infrastructure access ≠ data access — for Kubernetes
Your pod decrypts its secret in RAM. Stored Secrets, manifests, and etcd backups stay ciphertext — cluster-read and backup access reveal only sealed blobs, never plaintext.
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
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.
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 Hybrid, 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 exists here only
Neither application ciphertext nor secret plaintext crosses the ASTIS boundary.
Two trust tiers
Tier 1 — Standard
ASTIS manages the org key. Audit-grade trust separation: 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.
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. Onboarding now.
The end-to-end round-trip is proven; packaged pod SDK, GA, and SLA are in progress. Early customers onboard as design partners, direct with engineering.