Skip to content

Role-based access for Mirantis k0rdent Virtualization#

This page describes how Kubernetes role-based access control (RBAC) applies when you run Mirantis k0rdent Virtualization (KubeVirt via HCO) on Mirantis k0rdent Enterprise child clusters. It complements the platform RBAC model for the management cluster, which is documented separately.

Scope#

  • Management cluster: Defines who may install ServiceTemplate objects, edit ClusterDeployment resources, and use kubectl against the k0rdent API is governed by Mirantis k0rdent Enterprise RBAC. See Role Based Access Control.
  • Child cluster (virtualization workloads): After HCO deploys KubeVirt and related components, users and automation need appropriate Roles or ClusterRoles (and bindings) to create and manage VirtualMachine, VirtualMachineInstance, DataVolume, and other KubeVirt and CDI APIs in their namespaces.

Components and namespaces#

HCO installs operators and operands (for example KubeVirt, CDI, network add-ons, kubevirt-manager) in the kubevirt namespace by default. Cluster-scoped CRDs extend the Kubernetes API; namespace-scoped VM workloads typically live in application namespaces that you define. Plan RBAC so that:

  • Platform operators retain cluster-admin or equivalent for installing and upgrading HCO.
  • Namespace-scoped teams receive only the verbs and resources they need on the child cluster where VMs run.

Granting users access to virtualization APIs#

Use standard Kubernetes patterns on the child cluster:

  1. Choose a namespace (or namespaces) where VM owners will create workloads.
  2. Create a Role (namespace-scoped) or ClusterRole (cluster-scoped) that allows the required API groups and resources, for example virtualmachines, virtualmachineinstances, datavolumes, and related subresources where applicable.
  3. Bind that role to users, groups, or ServiceAccounts with a RoleBinding or ClusterRoleBinding.

KubeVirt typically ships aggregate ClusterRoles that you bind to users or groups, for example:

  • kubevirt.io:view — read KubeVirt resources (no create, delete, or console access).
  • kubevirt.io:edit — create, update, and delete VM workloads and use console or VNC where allowed.
  • kubevirt.io:admin — full access to KubeVirt resources plus runtime configuration; some operations require a ClusterRoleBinding rather than a namespace-scoped RoleBinding.

Bind these with RoleBinding (single namespace) or ClusterRoleBinding (cluster-wide), depending on your tenancy model. Labels and behavior can vary slightly by release; see Authorization in the KubeVirt user guide for details and examples.

Service accounts and automation#

CI/CD pipelines and controllers that create or mutate VM objects should use dedicated ServiceAccounts in the workload namespace, with RoleBindings granting only the required permissions. Avoid reusing personal user credentials for automation.

kubevirt-manager#

The kubevirt-manager UI runs in the cluster and uses Kubernetes credentials (for example a ServiceAccount) to list and manage VM resources. Ensure the account used by the deployment has RBAC consistent with what you want operators to do through the UI—typically permissions on VirtualMachine and related objects in the namespaces you expose.