Security
Secure a CVK installation by deciding who can read credentials, which remote identities each connection trusts, and which worker may perform an operation. The three guides below separate those decisions while retaining the detailed contracts needed for review.
Choose your task
| You are… | Start here | Expected result |
|---|---|---|
| Installing a device | Credentials and rotation, then TLS | The worker connects with a referenced Secret and verified server identity |
| Operating a network fleet | Credential rotation or gNOI trust | The intended workers restart or reconnect, with obsolete signer material removed |
| Reviewing or delegating access | Authorization and worker identities | Bindings and admission rules match the approved runtime and namespace boundaries |
For the first installation, follow Getting Started.
Keep the chart, CRDs and runtime image matched. These pages target v2026.11.1,
which introduces managed public-CA Secret projection and the Alpha controller
adapters. When upgrading from October v2026.10.0, follow their prerequisites;
a newer documentation example does not upgrade an installed release.
Decisions to make before deployment
Use a same-namespace credentialSecretRef with the exact key password for
each device. Secret storage needs Kubernetes encryption at rest and appropriate
RBAC; base64 encoding is not encryption. Application environment Secrets also
become device run options visible to device administrators.
Verify device HTTPS, gNOI and kubelet serving certificates separately. A valid certificate for one connection does not establish trust for another. Explicit gNOI TLS and signer retirement have their own procedure; read that procedure before a certificate change.
Review worker authority before sharing a cluster. Functional app hosting requires cluster-wide Secret reads, including with managed topology. Splitting fleets into namespaces does not remove that exposure. Network-management and controller-adapter identities have different, bounded permissions; cache filters are not authorization boundaries.
Confirm the outcome
Check the worker's readiness and referenced Secret revision after a credential change, verify the intended transport, and inspect the installed identities and bindings. Device mutation gates remain off until deliberately enabled. Use worker logs and device diagnostics for failures: hosted-application logs, exec, attach and port-forward are not supported through the VK kubelet API.
Related reading
Configuration defines fields; Getting Started provides the first-device path. Managed topology and the gNOI runbook own their migration and operation sequences. The focused security pages explain the trust assumptions behind those workflows.
Links from earlier versions of this guide
Detailed section links
Existing section links continue here. Choose Continue to open the full contract on its focused page.
| Topic | Continue |
|---|---|
| Injection contract | Continue |
| Create a Secret | Continue |
| Inline-password fallback | Continue |
| Password precedence | Continue |
| Rotate one password | Continue |
| Fleet credentials | Continue |
| One Secret per device | Continue |
| Shared fleet Secret | Continue |
| Shared password, distinct users | Continue |
| Namespace references | Continue |
| Bulk rotation | Continue |
| External secret managers | Continue |
| Application credentials | Continue |
| Device HTTPS | Continue |
| Secure gNOI | Continue |
| Upgrade image trust | Continue |
| SSH host keys | Continue |
| Kubelet serving TLS | Continue |
| RBAC model | Continue |
| Manager permissions | Continue |
| Worker permissions | Continue |
| Controller CEL prerequisite | Continue |
| Adapter identities | Continue |
| Intent Secret authorization | Continue |
| Delegation and hardening | Continue |
| Safe deletion | Continue |
| Security principles | Continue |