CLI Reference

One section per command, mirroring the flag definitions in the c8s source. Each table lists every flag of the command above it.

The c8s binary also responds to the symlink aliases get-cert, ratls-mesh, and nri-image-policy (each auto-prepends the matching subcommand).

c8s install

Install the c8s operator, CRDs, attestation-api, and component charts via Helm. Flags are registered with cobra/pflag.

c8s uninstall

Uninstall the c8s Helm release and, for a --cvm-mode=pod install, sweep the host-side kata artifacts off every node. helm uninstall unwinds the release resources; the host sweep then removes what that path cannot guarantee (/opt/kata, the containerd drop-in, the multi-GB kata-guest-base image, the RKE2 prep template, and the kata-runtime node labels). Requires the helm and kubectl CLIs on PATH.

c8s render-values

Print the resolved Helm values an install would apply, to stdout — without contacting a cluster. Useful for feeding a GitOps consumer (e.g. a Flux HelmRelease's valuesFrom) instead of recomputing digests and device mappings. Unlike install, the host distro isn't autodetected — pass --distro to pin it. Still needs the registry reachable for the default digest resolution (--resolve-digests=true).

c8s operator

Run the c8s controller-manager and admission webhook.

c8s cds

Run the Certificate Distribution Service (CDS). Requires --attestation-api-url and --allowlist-db.

c8s cds request-handoff

Drive the client side of the attested mesh-CA handoff (/handoff) end to end: generate an in-memory signer key, obtain a TEE-bound EAR for it from the peer's /attest-key, pull the recipient-encrypted CA material, and confirm the handed-off CA certificate is the trust root the peer serves on GET /ca. Runs standalone as a live-cluster rollout-continuity probe, inside an attested TEE with access to the local attestation-api. The peer admits only the launch measurements pinned in its --handoff-measurements. Prints a one-line JSON report on stdout; the pulled CA private key never leaves process memory.

Exit codes: 0 verified · 1 usage · 2 handoff or verification failed · 3 endpoint unavailable (unreachable / disabled / still bootstrapping past --timeout).

c8s allowlist

Read and mutate the CDS-served allowlist that nri-image-policy / policy-monitor enforce. It has two layers: a floor of image digests admitted by digest alone, and named workload entries that pin an init/main container set with per-container argv and path policy. Reads are unauthenticated; writes are signed with the operator EC private key whose public half the CDS pins (cds.operatorKeys, set by install --operator-keys). See The Allowlist for usage.

Persistent flags, registered on every subcommand:

Per-subcommand flags:

c8s secrets

Write operator-supplied values into the CDS secret store, and report why a sandbox does or does not receive them. CDS releases a value to a pod when the containers running in that pod's sandbox match a workload entry whose secrets grant covers the path; the grant is written with c8s allowlist workload apply. Values are held in the CDS process and nowhere else, so a CDS restart empties the store. See Secrets.

put sends the bytes exactly as read, including any trailing newline, and prints the byte count. Both subcommands sign their request with the operator EC private key whose public half the CDS pins (cds.operatorKeys, set by install --operator-keys).

Persistent flags, registered on every subcommand:

Per-subcommand flags:

c8s volume

Build an encrypted volume and store its key in the CDS secret store. create packages --source into an erofs image, formats a dm-verity tree over it, encrypts the pair to --out, writes the key blob to --escrow-out, and puts the key at --path in the store. It then prints the pod annotations and the allowlist grant to apply; it modifies no workload. The image is ciphertext and can reach the node by any route, including through the untrusted host, attached as a raw block device with virtio serial c8s-vol-<name>. Needs mkfs.erofs and veritysetup on PATH. The key exists in exactly two places — the CDS process and the escrow file — and a key path is create-only: CDS refuses a --path that already holds a value. See Volumes.

Persistent flags, registered on every subcommand:

create flags:

c8s cds-attest

Run the tls-lb attestation + over-encryption sidecar (the c8s-verify/v1 server side). Fronted by the tls-lb nginx (chart flag tlsLb.attest.enabled), it serves the LB's attestation at /.well-known/c8s/attestation, runs the post-quantum handshake, and forwards decrypted tunnel traffic to the backend. It's a chart-managed component, not normally run by hand — see Consumer Verification for the protocol.

c8s allowlist-proxy

Publish the CDS allowlist API through tls-lb. Public TLS terminates at the tls-lb nginx; this process makes the second trust hop, verifying CDS's RA-TLS serving certificate before forwarding the request. Path, query, and Authorization header are forwarded byte-for-byte, so the operator token's method/path/body binding survives the hop. It routes /allowlist and /allowlist/ to CDS, answers /healthz itself, and binds loopback only. A chart-managed component, not run by hand — see c8s allowlist for the client side.

c8s verify

Verify a deployed component's TEE attestation evidence (AMD SEV-SNP or Intel TDX) against the hardware signature chain plus a measurement, TCB, and policy check. Verification runs in-process with attestation-go (the Go port of the attestation-rs engine the cluster runs) — no container runtime is needed; a bare SEV-SNP report needs outbound HTTPS to AMD KDS (kdsintf.amd.com) to fetch its VCEK, bounded by --timeout. Takes a [target] (a URL or host:port) as its positional argument, or --url. c8s cds verify is the same command with CDS presets (--kind cds, default port 8443); --mode stays auto, which resolves to ratls-cert for a CDS target. See the verification guide for the end-to-end workflow.

Exit codes are a CI contract: 0 verified · 1 usage · 2 verification/policy failed · 3 evidence unavailable (unreachable / unparseable).

c8s get-cert

Obtain a signed certificate via the CDS attestation flow. Requires --cds-url, --attestation-api-url, and --san.

c8s get-secret

Fetch the secrets this pod is granted and write each one to a file under --out-dir. Injected by the webhook as a native sidecar. It authenticates to CDS with the pod's CDS-issued certificate and a sandbox token redeemed from the node's admission inventory over a compiled-in socket path, and CDS releases only once every main container in the sandbox is running — earlier attempts are refused and retried, so the files appear shortly after the workload starts and a consumer must wait for them. A path the store does not hold yet is created with a CDS-generated value, which does not survive a CDS restart. After writing, the process idles until the pod is torn down. See Secrets.

c8s get-volume

Fetch the key for each encrypted volume this pod is granted and hand it to c8s volumed on the node, which opens the device and mounts it read-only into this pod. Injected by the webhook as a native sidecar, with the same authentication, release rule, and retry behavior as c8s get-secret: the volume appears shortly after the workload starts. The key must already be in the store, put there by c8s volume create; nothing here creates one. Linux only — the subcommand is registered only in Linux builds of the CLI. See Volumes.

c8s volumed

Node agent that opens encrypted volumes for the pods on its node. An injected c8s get-volume sidecar hands it a key over volumed.sock, created inside the admission inventory's socket directory; the daemon resolves the calling pod from kernel peer credentials, opens dm-crypt and dm-verity, and mounts the result read-only into that pod and no other. The mount target is never taken from what the caller reports about itself. Teardown is driven by the pod's cgroup slice disappearing. Runs privileged on every node, and takes no positional arguments. Linux only — the subcommand is registered only in Linux builds of the CLI. See Volumes.

c8s cred-release

Issue a short-lived kube client certificate to a caller that proves possession of the operator key whose public half was measured into RTMR[3] at node launch. It serves POST /release-credential over RA-TLS — the endpoint c8s get-kubeconfig consumes — signing the caller's CSR with the cluster's client CA and returning a kubeconfig anchored to the serving CA. Startup fails closed if the measured key does not match RTMR[3], and an empty --platform is rejected because RA-TLS is mandatory here. Intel TDX only: the operator-key binding lives in RTMR[3]. Baked as a systemd unit in the c8s node image; not run by hand. The CA defaults are the RKE2 paths — on kubeadm, set all three to /etc/kubernetes/pki/ca.crt and ca.key.

c8s get-kubeconfig

Obtain an operator kubeconfig from a measured Intel TDX CVM. The node is attested through its attestation-api and its quote's rtmr_3 must equal the value the operator public key implies (the node was launched to trust that key); a locally generated CSR is then exchanged for a short-lived kube client certificate over the node's cred-release endpoint, and the kubeconfig is written to --out. Verification runs in-process with attestation-go, including the RA-TLS check on the cred-release dial. TDX only — the operator-key binding lives in RTMR[3], so a node reporting any other platform is rejected. Requires --operator-key, --out, and either --node or all of --attest-url, --release-url, and --apiserver-url.

c8s ratls-mesh

Run the RA-TLS L4 mesh proxy or its iptables side commands.

c8s ratls-mesh iptables-sync

Watch Kubernetes pods and maintain the iptables/ipset rules that redirect mesh traffic.

The ratls-mesh iptables-cleanup subcommand takes no flags.

c8s nri-image-policy

Run the NRI image-policy plugin. Uses the standard Go flag package; most configuration comes from the YAML config file rather than CLI flags.

c8s probe-file

Exit 0 if <path> exists and is non-empty — a file-existence helper for distroless containers, where /bin/test is not available. One-shot by default (for a kubelet exec probe); with --wait it blocks until the path passes (or --timeout elapses), so it can be the entrypoint of an init container that gates a workload on a file another container writes — the exec-free equivalent of a startup probe, needed on locked kata guests where exec probes are denied by policy. The non-empty check rules out passing on a half-written file.