Fetch a kubeconfig from a running CVM

c8s get-kubeconfig runs on your machine and gives you kubectl access to a c8s node confidential VM (CVM) that no cluster you can reach knows about yet. It attests the guest through the measured-image + operator-key gate, then exchanges a locally generated certificate signing request (CSR) for a system:masters client certificate over Remote-Attestation TLS (RA-TLS) and writes a kubeconfig. Its counterpart inside the guest is cred-release, a service in the c8s node image that signs that certificate with the cluster's client CA.

Nothing is unsealed from storage. The credential is minted on demand, the private half of the client key never leaves your machine, and the certificate is valid for 24 hours — run the command again for a new one.

Before you start

• A booted c8s node CVM you can reach on 8400 (attestation-api), 8443 (cred-release), and 6443 (kube-apiserver). See Boot a node CVM on bare metal.
• That CVM must have been launched for your operator key. On Intel TDX the public key reaches the guest as a disk labeled opkeydata holding one file, pubkey, and the measured initrd extends its digest into RTMR[3] before switch_root. On AMD SEV-SNP the launcher commits HOSTDATA = SHA-256(pubkey bytes) at launch. Either way the binding is set at launch and cannot be added to a running guest.
• The operator EC private key (operator.key).
• The build-artifact manifest of the exact image the CVM booted (step 1 gets it).
• On SEV-SNP, outbound HTTPS from your machine to AMD's Key Distribution Service: bare-metal SNP evidence carries no inline VCEK, so the verifier fetches one to check the quote's signature.
• The c8s CLI — Install c8s has the build steps.

One keypair, two gates

One EC keypair does double duty across the whole bootstrap. Generate it once:

umask 077
openssl ecparam -name prime256v1 -genkey -noout -out operator.key
openssl ec -in operator.key -pubout -out operator.pub

These are two independent gates that in practice hold one keypair: the launch binding is verified by the guest and by this command, while --operator-keys is a Helm value the install pins into the CDS, the cluster's Certificate Distribution Service. c8s get-kubeconfig derives the public half from --operator-key itself, so the bytes it compares against the quote are the bytes openssl ec -pubout wrote.

That forces the order. The key must exist before the CVM boots, and the CVM has no kubeconfig until this command runs, so the bootstrap is:

1. Create the keypair (above).
2. Launch the node CVM with operator.pub bound into its launch identity.
3. Run c8s get-kubeconfig — this is the first kubectl access anyone has to the guest.
4. Run c8s install --operator-keys operator.pub against that kubeconfig.

Fetch the kubeconfig

The commands below assume a bare-metal Intel TDX guest running under KubeVirt, addressed by its guest IP. Substitute <GUEST_IP>.

crane manifest <REGISTRY>/<REPO>:<TAG> \
  | jq -r '.layers[] | select(.annotations["org.opencontainers.image.title"] == "manifest.json") | .digest'

crane blob <REGISTRY>/<REPO>@<MANIFEST_LAYER_DIGEST> > image-manifest.json

jq '.tdx' image-manifest.json           # TDX: mrtd, rtmr1, rtmr2
jq '.snp_variants' image-manifest.json  # SNP: one launch digest per vCPU count

curl -s http://<GUEST_IP>:8400/health                                    # "platform":"tdx" (or "snp")
curl -sk -o /dev/null -w '%{http_code}\n' https://<GUEST_IP>:6443/livez  # 200, 401, or 403
curl -sk -o /dev/null -w '%{http_code}\n' https://<GUEST_IP>:8443/       # any code but 000

c8s get-kubeconfig \
  --node <GUEST_IP> \
  --operator-key operator.key \
  --image-manifest image-manifest.json \
  --out guest.kubeconfig

wrote guest.kubeconfig (context "c8s") — attested: image tuple + operator-key chain verified

export KUBECONFIG=$PWD/guest.kubeconfig
kubectl auth whoami -o jsonpath='{.status.userInfo.username}'   # operator
kubectl get nodes

Address a KubeVirt guest by name

If the guest runs as a KubeVirt VirtualMachineInstance, name it instead of chasing its address:

c8s get-kubeconfig \
  --vmi <NAMESPACE>/<VMI_NAME> \
  --operator-key operator.key \
  --image-manifest image-manifest.json \
  --out guest.kubeconfig

--vmi reads the VMI's first reported status.interfaces[].ipAddress through your current kubeconfig — the outer cluster that hosts the VM — and then talks to the guest directly. The namespace defaults to your current context's. A VMI that is still booting reports no address yet, and the lookup fails with has no reported address. --vmi and --node are mutually exclusive.

SEV-SNP under direct QEMU

A guest launched by hand under QEMU usually reaches you on host-forwarded ports rather than 8400/8443/6443, so give all three URLs explicitly instead of --node:

c8s get-kubeconfig \
  --attest-url    http://127.0.0.1:<ATTEST_PORT>/attest \
  --release-url   https://127.0.0.1:<RELEASE_PORT> \
  --apiserver-url https://127.0.0.1:<APISERVER_PORT> \
  --operator-key operator.key \
  --image-manifest manifest.json \
  --out guest.kubeconfig

Use the SNP build's manifest.json, the one carrying snp_variants. --workload-image is rejected on SNP: there is no runtime-extend register, so a workload chain cannot be verified.

The kubeconfig's tls-server-name is c8s-cvm by default, which is the SAN the node image bakes into RKE2's tls-san. That is what makes the apiserver certificate verify against a stable name rather than the per-launch address you dialed.

What the gate checked

The manifest names the platform, and the node must be that platform: evidence tagged az-snp, az-tdx, or gcp-* is refused before any claim is read. On top of that:

The image tuple and RTMR[3] are both load-bearing. RTMR[3] alone is not an identity: the untrusted host stages the operator key, so it could boot any image at all and still reproduce the bare operator-key register. The manifest anchors the image; the register binds the key.

The same policy is enforced twice. Once on the attest gate, against a fresh 32-byte nonce returned in report_data. Then again on the RA-TLS dial to cred-release, where the serving certificate must be self-signed, carry a quote bound to its own public key, and satisfy the identical pins — so a host that cannot forge the first gate cannot sit in the middle of the channel that carries the CSR either. For how this verification model works across the rest of the platform, see The verification model.

When it fails

Every check fails closed, and the message names which one.

Why this does not apply on AKS or GKE

Each of these is enough on its own:

• cred-release ships only in the c8s node image. An AKS or GKE node does not run that image, so nothing serves :8443.
• The gate refuses the evidence. A manifest pins tdx or snp; Azure and GCP confidential nodes report az-tdx, az-snp, or gcp-*, and the platform compare rejects them.
• HOSTDATA is owned by the cloud stack on those platforms, so it cannot carry the operator-key binding at all.

Get the kubeconfig from the provider instead — az aks get-credentials on AKS. See Provision a confidential cluster on Azure. The operator keypair still matters there: c8s install --operator-keys operator.pub is what authorizes allowlist and secrets writes.

See also

• Boot a node CVM on bare metal — the step that produces the guest this page attests.
• Install c8s — the next step, using the kubeconfig you just wrote.
• CLI reference — every flag, with its type and default.
• The verification model — how attested channels are checked elsewhere in c8s.
• Obtain launch measurements — the digest c8s install --measurements wants.