Comparison · Kubernetes secrets · Verified July 2026
Workload Secrets vs the secrets stack
Vault, OpenBao, ESO, Sealed Secrets, SOPS, cloud secret managers — useful tools for storing, syncing, mounting, or rotating secrets. The practical question is where usable plaintext appears after delivery. ASTIS adds a workload-bound decrypt boundary around that moment. Keep your stack. Add the boundary.
TL;DR. Kubernetes KMS is real protection for etcd-at-rest, and Vault/OpenBao can be the right authority for dynamic secrets. But most Kubernetes delivery patterns still end with usable plaintext in a Kubernetes Secret, pod file, environment variable, or provider mount. ASTIS Workload Secrets changes that last step: stored and routed values stay ciphertext, and plaintext exists only in the RAM of a live pod that passed workload-bound checks — including a sha256 allowlist over every running image, injected debug containers included.
In their own words
Not our claims — their documentation.
“Kubernetes Secrets are, by default, stored unencrypted in the API server’s underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd.”
Kubernetes documentation“All data encryption keys (DEKs) will be cached in the clear once the server has unwrapped them via a call to the KMS.”
Kubernetes KMS v2 documentation“Containers are not a security boundary, and the use of IAM roles for service accounts does not change this.”
AWS EKS documentation (IRSA)Vault’s injector renders secrets as plaintext files into a shared volume at /vault/secrets — the docs’ own example shows a readable Postgres connection string.
HashiCorp Vault documentationThe plaintext boundary test
Each row asks where an operator, workload, pipeline, or agent can reach usable plaintext. Hover a mark for the deployment nuance.
| ASTIS Workload Secrets | k8s Secrets (+KMS) | Vault / OpenBao | ESO · Sealed · SOPS | Cloud SM + CSI | |
|---|---|---|---|---|---|
| Does the secret reach Kubernetes already encrypted? | Kubernetes receives a sealed value, not the application secret source | The API server receives the Secret value, then KMS/encryption-at-rest protects storage source | Direct app fetch can keep values outside Kubernetes; sync, injector, or template patterns can materialize plaintext in the cluster source | Git/CR input can be encrypted, but reconciliation commonly creates a normal Kubernetes Secret source | Direct CSI mounts avoid Kubernetes Secret objects; optional sync creates them source |
| If etcd or its backup leaks, are secret values still encrypted? | etcd stores the sealed value source | Yes when Kubernetes encryption at rest is enabled for Secrets and existing objects have been re-encrypted source | If no Kubernetes Secret is created, the value is not in etcd; synced or templated Secrets rely on Kubernetes encryption at rest source | Generated Kubernetes Secrets rely on Kubernetes encryption at rest, not on the original Git encryption source | Direct CSI mode keeps values out of etcd; sync-to-Secret relies on Kubernetes encryption at rest source |
| Does kubectl get secret return ciphertext instead of the usable secret? | Cluster readers see sealed values, not usable secrets source | KMS protects storage at rest; authorized API reads still receive decrypted Secret data source | If nothing is synced into Kubernetes, kubectl may show nothing useful; synced Secrets are readable source | The controller eventually writes a normal Kubernetes Secret in the common pattern source | No Kubernetes Secret object in direct CSI mode; sync mode creates one source |
| If someone can read all Kubernetes objects, do secret values stay unreadable? | Kubernetes object read access is not decrypt access source | get/list/watch on Secrets exposes the decoded Secret data through the API source | Cluster read alone is not necessarily Vault read; synced Secrets, pod files, or exec access change the answer source | Generated Kubernetes Secrets are readable by anyone with Secret read access source | Direct CSI references are safer than sync-to-Secret; node or pod access changes the answer source |
| Can GitOps and CI/CD stay ciphertext-only all the way into Kubernetes? | Pipelines and Kubernetes can move sealed payloads without handling plaintext source | KMS happens after the Kubernetes API receives the Secret source | Git can contain references only, but deploy patterns often still fetch, template, or sync plaintext into the workload source | Strong for encrypted Git, but the cluster commonly materializes normal Kubernetes Secrets source | Git can contain references; CSI mounts deliver plaintext to the pod and sync mode creates Kubernetes Secrets source |
| Does the workload avoid plaintext secret files and environment variables? | Plaintext is not materialized as a Kubernetes Secret volume or env var source | Pods normally consume Kubernetes Secrets as env vars or mounted files source | Direct application fetch can avoid files; Vault Agent templates and CSI-style mounts commonly write plaintext files source | These flows usually feed normal Kubernetes Secret env vars or volumes source | CSI avoids Kubernetes Secret objects, but the pod still receives plaintext files source |
| Does decrypt require more than Kubernetes RBAC or a copied ServiceAccount token? | Decrypt is bound to workload identity plus ASTIS policy, not just possession of Kubernetes credentials source | Kubernetes API authorization is the read gate; KMS does not add a workload-bound decrypt decision for kubectl get secret source | Depends on Kubernetes auth, token audience, Vault/OpenBao policy, and whether the copied token can authenticate as that service account source | Once the normal Kubernetes Secret exists, Kubernetes RBAC is the read gate source | Depends on workload identity, token exchange, cloud IAM, and CSI/provider configuration source |
| Can an AI agent get broad cluster-read access without becoming a secret reader? | It can inspect Kubernetes state and sealed values without receiving decrypt capability source | If the agent can read Secrets, API reads return decrypted data source | Safe with cluster read only; unsafe if it also has Vault access, pod exec, synced-secret access, or mounted file access source | Broad cluster-read commonly includes generated Kubernetes Secrets source | Direct CSI references are safer than sync-to-Secret, but pod/node access can still expose plaintext source |
| Does decryption require an explicit workload-bound authorization step? | Decrypt is a separate workload-bound decision source | Kubernetes API authorization is the main gate for reading Secret data source | Yes when applications fetch from Vault/OpenBao under a scoped auth method and policy source | The controller decrypts or fetches and writes a normal Kubernetes Secret source | Cloud IAM/provider authorization is separate, but mounted results are plaintext in the workload source |
✓ = yes by design · ✗ = no in the normal pattern · — = depends on deployment pattern or extra controls. Simplified on purpose; every nuance carries a tooltip and a source below.
Two different jobs
Our layer: decide who can open them
Secrets stay sealed everywhere they rest. Decryption happens in the pod’s RAM only after four independent checks pass: a bound API key (cluster + namespace + ServiceAccount), the pod’s own SA JWT verified against your pinned JWKS, a RAM-only DPoP key pinned to the live Pod UID, and a sha256 allowlist over every running image — sidecars and injected debug containers included. Fail-closed.
Infrastructure access stops implying secret access — for admins, backups, pipelines, and AI agents alike.
Their layer: get secrets to workloads
Central storage, dynamic database credentials, leases, rotation, git-safe encryption, multi-cloud sync. Real jobs, done well — keep the tools that do them.
In Kubernetes delivery patterns, success usually means handing plaintext to the workload — through a file, an env var, a provider mount, or a k8s Secret.
The 2026 row: your AI DevOps agent
Agents now hold kubectl access, read manifests, tail logs, and run pipelines. In common Kubernetes secret patterns, that access can become secret access through normal Secret reads, pod exec, synced Secrets, or plaintext files in pod filesystems. With ASTIS it reads what everyone else reads — sealed values. It can operate your cluster all day and never hold a decryptable secret, because cluster-read access is not decrypt capability.
When you should NOT buy this
Your threat model ends at RBAC. If you trust everyone with cluster access, your backup chain, and your pipelines — native Secrets with KMS encryption at rest, or ESO over a cloud store, is a reasonable free answer.
You need leased, per-instance dynamic credentials. Minting short-lived DB accounts on demand and auto-revoking them is Vault/OpenBao’s home turf — ASTIS does not replace that machinery. (Scheduled rotation is different: generate → seal with astis-cli → roll; each envelope rotates independently.)
Budget is zero. ASTIS starts at $18k/year. The OSS stack is free plus operations — an honest trade if the boundary above is not your requirement yet.
FAQ
Is ASTIS Workload Secrets a Vault replacement?
No. Leased dynamic database credentials and transit encryption — that is Vault/OpenBao’s job, and if you rely on those, keep them. (Scheduled rotation of static secrets, though, is a plain pipeline with ASTIS: generate, seal with astis-cli, roll — each envelope rotates independently.) ASTIS adds the layer none of the distribution tools have: a cryptographic boundary that decides which attested workload can turn a sealed blob into plaintext, in RAM, at use time.
Does anyone in this stack verify the container image before releasing a secret?
In the documented k8s integration paths we reviewed — no. Vault, OpenBao and Infisical bind trust to ServiceAccount + namespace (TokenReview); ESO, Sealed Secrets and SOPS end in regular k8s Secrets gated by RBAC; cloud workload-identity binds IAM to the ServiceAccount. ASTIS checks the live Pod UID and requires every running image — app, init, sidecar, injected debug container — to match a sha256 allowlist, fail-closed.
When is the free stack enough?
If your threat model ends at RBAC — you trust everyone with cluster access, your backups, and every pipeline — then k8s Secrets with KMS encryption at rest, or ESO over a cloud store, is a reasonable, free answer. ASTIS is for the moment “infrastructure access” and “secret access” must stop meaning the same thing: admins, backups, vendors, and AI agents can operate the cluster without being able to open the secrets.
What about high availability — what if the ASTIS edge is unreachable?
Workloads talk to ASTIS at unseal time, not continuously. A pod that has already opened its secrets holds them in its own RAM and keeps running through an edge outage. New unseals — fresh pods, restarts, rescheduling — are fail-closed by design: a pod does not start with secrets it cannot verify, and comes up once the edge is reachable again. The edge is covered by the plan SLA (99.9% on Workload Business and above); with HYOK CVS on Enterprise, the key authority runs inside your perimeter, so unseal-path availability is under your control.
What does it cost?
Workload Team is $18,000/year, self-serve via the portal; Workload Business is $60,000/year, and Enterprise starts at $120k. ASTIS prices the boundary — no metered per-secret or per-identity charges. Tiers are sized in bands of workload identities across all environments, so the bill steps by tier, not by every new secret or pod. Upgrades are pro-rated by month, the minimum billing unit: move up mid-term and the remaining full months of what you already paid are credited toward the new plan.
Sources — retrieved July 2026
- Kubernetes: Secrets and default storage behavior
- Kubernetes: Secrets good practices
- Kubernetes: encryption at rest and KMS
- Vault: Agent Injector
- Vault: Kubernetes auth
- OpenBao: Kubernetes auth
- External Secrets Operator overview
- Sealed Secrets
- Flux: SOPS guide
- Secrets Store CSI Driver
- AWS EKS: IRSA and container boundary note
- ASTIS Workload Secrets — how it works
All trademarks belong to their owners. Deployment patterns vary — verify against your own setup. Found an inaccuracy? [email protected] — verified corrections within one business day.
Keep your stack. Add the boundary.
Run the quickstart on a real cluster and watch an unapproved image get refused — the proof is the point.