Merge pull request #97863 from danielclowers/CNV-63561

CNV#63561: virt-launcher does not use kubevirt-controller SA

Author: sjhala-ccs

modules/virt-additional-scc-for-kubevirt-controller.adoc

@@ -8,7 +8,12 @@
 
 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 `virt-controller` is a cluster controller that creates the `virt-launcher` pods for virtual machines in the cluster.
+
+[NOTE]
+====
+By default, `virt-launcher` pods run with the `default` service account in the namespace. If your compliance controls require a unique service account, assign one to the VM. The setting applies to the `VirtualMachineInstance` object and the `virt-launcher` pod.
+====
 
 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 {VirtProductName} features that are beyond the scope of typical pods.
 
@@ -18,7 +23,7 @@ The `kubevirt-controller` service account is granted the following SCCs:
 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.
+This ensures the `virt-launcher` pod is not run as a privileged container.
 
 * `scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}`