Security policies

Learn about OKD Virtualization security and authorization.

Key points

• OKD Virtualization adheres to the restricted Kubernetes pod security standards profile, which aims to enforce the current best practices for pod security.

• Virtual machine (VM) workloads run as unprivileged pods.

• Security context constraints (SCCs) are defined for the kubevirt-controller service account.

About workload security

By default, virtual machine (VM) workloads do not run with root privileges in OKD Virtualization, and there are no supported OKD Virtualization features that require root privileges.

For each VM, a virt-launcher pod runs an instance of libvirt in session mode to manage the VM process. In session mode, the libvirt daemon runs as a non-root user account and only permits connections from clients that are running under the same user identifier (UID). Therefore, VMs run as unprivileged pods, adhering to the security principle of least privilege.

Additional OKD security context constraints and Linux capabilities for the kubevirt-controller service account

Security context constraints (SCCs) control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system.

The virt-controller is a cluster controller that creates the virt-launcher pods for virtual machines in the cluster. These pods are granted permissions by the kubevirt-controller service account.

The kubevirt-controller service account is granted additional SCCs and Linux capabilities so that it can create virt-launcher pods with the appropriate permissions. These extended permissions allow virtual machines to use OKD Virtualization features that are beyond the scope of typical pods.

The kubevirt-controller service account is granted the following SCCs:

• scc.AllowHostDirVolumePlugin = true
  This allows virtual machines to use the hostpath volume plugin.

• scc.AllowPrivilegedContainer = false
  This ensures the virt-launcher pod is not run as a privileged container.

• scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}

  • SYS_NICE allows setting the CPU affinity.

  • NET_BIND_SERVICE allows DHCP and Slirp operations.

Viewing the SCC and RBAC definitions for the kubevirt-controller

You can view the SecurityContextConstraints definition for the kubevirt-controller by using the oc tool:

$ oc get scc kubevirt-controller -o yaml

You can view the RBAC definition for the kubevirt-controller clusterrole by using the oc tool:

$ oc get clusterrole kubevirt-controller -o yaml

Authorization

OKD Virtualization uses role-based access control (RBAC) for authorization. For example, an administrator can create an RBAC role that provides the permissions required to launch a virtual machine. The administrator can then restrict access to that feature by binding the role to specific users.

Default cluster roles for OKD Virtualization

By using cluster role aggregation, OKD Virtualization extends the default OKD cluster roles to include permissions for accessing virtualization objects.

Additional resources

• Managing security context constraints

• Using RBAC to define and apply permissions

• Creating a cluster role

• Cluster role binding commands

• Enabling user permissions to clone data volumes across namespaces