Supported Paths¶
The hosted relay is demo only. Customers choose and configure their own relay; hosted customer and pilot enrollment are unavailable. See Beacon Installation.
This page states, path by path, what works today and what does not. It is a status page, not a roadmap: it lists known gaps in the current releases so that you can plan around them. Other pages describe the intended design; where they differ from this page, use the evidence and its limits recorded here. Inferred rows describe source review, not a measured installation.
Status values:
- Measured pass: a dated qualifying cell and run establish the named path.
- Observed limitation; cell record pending: an earlier observation whose qualifying cell record is not yet linked.
- Inferred fix; live verification pending: source contains the correction, but no dated cell result qualifies the pinned deployment.
- Not yet supported: do not rely on it today.
- Historical observation; qualifying cell pending: an earlier observed result without a linked qualifying cell and run.
- Offline until beta: the hosted service is unavailable; use a separately qualified self-hosted path.
- Unsupported: a required capability is unavailable on this platform; do not deploy protected workloads through this path.
| Path | Status | What happens today | Workaround |
|---|---|---|---|
| Hosted demo topology (managed GKE target, EU beacon relay, EU OpenBao), operated by CloudTaser | Offline until beta | The hosted demo is offline until beta. Its historical topology is not a current service or a customer installation procedure. | Use the documented self-hosted procedure within its qualification limits. |
| GKE Autopilot or EKS Fargate protected workloads | Unsupported | Autopilot agent admission is blocked by default; no CloudTaser allowlist deployment is qualified. Fargate cannot run the required node-agent DaemonSet. Without a Ready node agent the default admission/binding gate refuses protected workloads. | Choose separately verified GKE Standard nodes or EKS node groups. No wrapper-only fallback is qualified; keep enforcement enabled. |
| AKS protected workloads | Requires a verified node configuration; unqualified live | Assessed stock AKS Ubuntu 22.04/24.04 and Azure Linux 3 defaults omit active BPF LSM, so the default agent is expected to refuse (assessed, not run). Actual enforcement/refusal needs live evidence. The dated Azure Linux running-node record conflicts with the vendor default; see the record. Kernel compilation flags or confidential VM labels do not establish readiness. | Independently verify active BPF LSM, required vectors, node-agent readiness and CNI enforcement on the exact node image/release. Keep strict protection enabled; see platform compatibility. |
Direct mode on k3s (target install --mode direct, or the direct Helm profile) |
Not yet supported | Protected workloads cannot start or restart under strict eBPF enforcement because the wrapper's own startup is blocked. The CLI side of direct mode is in place: target connect --mode direct registers the in-cluster API endpoint and gives the secret store a token reviewer that may only create TokenReviews, and target install --mode direct renders the vault backend with reverse-connect and the beacon off, the auth/kubernetes auth path and the operator's egress to the secret store (an IP-literal address, or networkPolicy.vaultCIDR for a hostname; without it a hostname stops with exit code 4). A cluster registered by an older CLI can show a latched cluster-identity mismatch in target status; target fingerprint clear-latch recovers it. See the CLI reference. |
None that keeps strict enforcement on. Do not disable eBPF, seccomp or the fail-closed health gate to get around it. See the operator installation for the Helm path. |
| Linux host Port + customer relay + US cluster + EU store | Historical observation; qualifying cell pending | On 1.0.358: denial cases, explicit rotation, outages and enforcing policies. On 1.0.359: no-resources delivery and sizing, with operator policies off. Both used pre-release CLIs and a private-CA IP relay; DNS/public-CA relays and released CLI v0.19.176 were not tested end to end. GKE COS 6.12.105+/Calico, one operator. |
Fresh install with chart 1.0.359 and its matched cohort; skip 1.0.357 and 1.0.358. Follow the procedure. Port is a supervised finite session (longest tested about 35 min); operator RAM loss needs reintroduction. Install in cloudtaser-system. |
| Managed S3 proxy, DB proxy and Volume Shield through host Port | Not yet supported | S3 proxy was refused before serving; Volume Shield failed admission before PVC binding. DB proxy has not been shown to work with a store on this path. | Do not enable them here. |
| Multiple wrapped containers per Pod | Not yet supported | Envelope identity fails closed with two wrapped consumers, observed on the S3 sidecar shape; two app containers were not run. | Use one wrapped container and set cloudtaser.io/containers; its default is the first container. |
Port on Kubernetes (source install port, target install --install-port) |
Not yet supported | No run on this release; neither Port nor OpenBao Kubernetes chart was exercised. source install port defaults to Kubernetes. |
Use the explicit Linux host-Port procedure. |
| Application memory on host-Port path | Observed limitation; cell record pending | About 42 MB injected tmpfs, Pod cgroup 67–69 MB for idle Python. Manifest 1Mi plus operator overhead 64Mi became effective 65Mi and OOMKilled; manifest 192Mi became 256Mi and passed. | The 64Mi addition covers the tmpfs; size effective limits well above 69 MB plus app headroom. No limit is added if absent. |
| Broker CA rotation on host Port | Not yet supported | No supported host-Port broker CA rotation runbook is available in this release. A rehearsal retired the old CA using hand-built enrollment and material; that does not qualify a customer procedure. | Plan source/cluster maintenance with the administrators; do not infer support from webhook TLS or JWT signing-key refresh. |
| Pod deletion revokes issued store tokens | Observed limitation; cell record pending | Issued tokens can outlive the deleted Pod until TTL, up to 15 minutes. The live test measured 13 minutes 48 seconds of remaining life and denied product revocation attempts; it did not test a post-deletion secret read. | Do not use Pod deletion as immediate credential invalidation. Use reviewed source-administrator incident handling. |
| Linux 7.0 kernels | Not yet supported | Stock GCE Ubuntu 24.04 LTS booted 7.0.0-1014-gcp and crash-looped. GKE COS 6.12.105+ passed delivery; Ubuntu 6.8.0-1071-gcp with active BPF LSM passed admission/startup only, without a store. |
Check uname -r on each node; a distribution LTS label does not pin its kernel. See kernel compatibility. |
| Automatic rotation of KV-v2 secrets | Historical observation; qualifying cell pending | In direct-Vault mode the wrapper reads the KV-v2 data path on each renewal tick and applies the rotation strategy when metadata.version changes. In broker/beacon mode the sealed payload carries no KV version, so a new value reaches a running workload only after a re-fetch. |
For the managed broker/beacon path, use explicit target rotate and verify the application after rollout. Direct-mode SIGHUP behavior has a separate contract. See the rotation annotation. |
| Volume Shield PVC opt-in on a pod without wrapper injection | Historical observation; qualifying cell pending | From operator v0.13.190 the webhook refuses such a pod and names the missing prerequisite. Before v0.13.190, a pod that mounts a PVC annotated cloudtaser.io/encrypt-pvc: "true" but requests no wrapper injection is admitted without the Volume Shield sidecar, and its writes reach the backing storage unencrypted with no error. |
Upgrade the operator to v0.13.190 or later. On older operators, request wrapper injection on every pod that mounts an encrypted PVC, and confirm the sidecar is present and the data on the backing storage is ciphertext before storing real data. See Volume Shield. |
| Volume Shield with TSDB, ClickHouse or hard-link workloads | Not yet supported | Trusted freshness is mandatory. Directory renames fail with EXDEV and hard links with EOPNOTSUPP, which breaks Prometheus TSDB compaction, ClickHouse part commits, VictoriaMetrics and Cassandra snapshots. See unsupported workloads. |
Keep that data on a volume that Volume Shield does not manage. |
DB proxy: binary (bytea) data |
Inferred fix; live verification pending | Code decodes text-format bytea before decryption and re-encodes plaintext in the requested text format; binary results retain raw bytes. Source: cloudtaser-db-proxy v0.1.55. |
Use binary result format; qualify text bytea results with your client. |
| DB proxy: default PostgreSQL SCRAM authentication | Inferred fix; live verification pending | Code withholds channel-bound -PLUS mechanisms from the plaintext application leg. This does not qualify an upstream offering only -PLUS. Source: cloudtaser-db-proxy v0.1.55. |
Use non-PLUS SCRAM on the upstream; do not rely on a PLUS-only upstream. |
S3 proxy: object keys with a space, non-ASCII characters, + or % |
Inferred fix; live verification pending | The published proxy preserves escaped upstream paths; this does not establish correct signing for every special key. Source: cloudtaser-s3-proxy v0.2.61. |
Use plain ASCII key characters without spaces, plus or percent until the special-key path is qualified. |
Uninstall (helm uninstall) on the measured host-Port path |
Historical observation; qualifying cell pending | In the live customer-path test, uninstall hooks completed, node attachments were retired and the shared-resource inventory matched the baseline. This does not prove expired host-grant reconciliation on a retained store. | Drain protected workloads, use chart hooks, inspect node/webhook residue and retire only owned resources. See customer teardown. |
| Kernels without a synchronous deny path for every required vector | Observed limitation; cell record pending | With the default chart the eBPF agent returns HTTP 503 and protected workloads are refused. This is intended protection behaviour, not a defect. BPF LSM availability alone does not make a node ready. See Kernel Compatibility. | Use a kernel with CONFIG_BPF_KPROBE_OVERRIDE=y, or one whose BPF LSM hooks cover every required vector. |
Reading this page¶
The host-Port results come from the 31 October 2026 US GKE COS/Calico test with EU Linux VMs; other rows include earlier k3s and Ubuntu/Debian tests. The follow-up on chart 1.0.359 proved no-resource delivery and measured memory overhead, with operator NetworkPolicies disabled. Default policies and no-resource delivery on that chart together remain untested. A row that says Not yet supported means a complete run could not be demonstrated, not that the feature is permanently absent. Behaviour on other distributions or Kubernetes versions has not been separately verified.
Proxy platform qualification¶
| Platform | S3 proxy | DB proxy |
|---|---|---|
| GKE Standard COS/Calico | Planned; qualification pending | Planned; qualification pending |
| GKE Standard Ubuntu | Planned; qualification pending | Planned; qualification pending |
| EKS node groups | Planned; qualification pending | Planned; qualification pending |
| AKS | Planned; qualification pending | Planned; qualification pending |
| k3s and other distributions | Planned; qualification pending | Planned; qualification pending |