Windows HostProcess Container Documentation (#28413)
* Rebasing HostProcess security changes. * Incorporated initial round of feedback * Minor wording updates * Finished up remaining todo items * Apply suggestions from code review Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Mark Rossetti <marosset@microsoft.com> * Moved HostProcess security documentation into PSS and create-host-process-pod docs * Updated with for James' review * Apply suggestions from code review Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: James Sturtevant <jsturtevant@gmail.com> * Minor edits * Modifications for additional feedback Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Mark Rossetti <marosset@microsoft.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: James Sturtevant <jsturtevant@gmail.com>
This commit is contained in:
@@ -55,6 +55,24 @@ fail validation.
|
||||
<td><strong>Control</strong></td>
|
||||
<td><strong>Policy</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap">HostProcess</td>
|
||||
<td>
|
||||
<p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess containers</a> which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are an <strong>alpha</strong> feature as of Kubernetes <strong>v1.22</strong>.</p>
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.containers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li>Undefined/nil</li>
|
||||
<li><code>false</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap">Host Namespaces</td>
|
||||
<td>
|
||||
@@ -483,10 +501,19 @@ ecosystem, such as [OPA Gatekeeper](https://github.com/open-profile-agent/gateke
|
||||
### What profiles should I apply to my Windows Pods?
|
||||
|
||||
Windows in Kubernetes has some limitations and differentiators from standard Linux-based
|
||||
workloads. Specifically, the Pod SecurityContext fields [have no effect on
|
||||
workloads. Specifically, many of the Pod SecurityContext fields [have no effect on
|
||||
Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
|
||||
such, no standardized Pod Security profiles currently exist.
|
||||
|
||||
If you apply the restricted profile for a Windows pod, this **may** have an impact on the pod
|
||||
at runtime. The restricted profile requires enforcing Linux-specific restrictions (such as seccomp
|
||||
profile, and disallowing privilege escalation). If the kubelet and / or its container runtime ignore
|
||||
these Linux-specific values, then the Windows pod should still work normally within the restricted
|
||||
profile. However, the lack of enforcement means that there is no additional restriction, for Pods
|
||||
that use Windows containers, compared to the baseline profile.
|
||||
|
||||
The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged.
|
||||
|
||||
### What about sandboxed Pods?
|
||||
|
||||
There is not currently an API standard that controls whether a Pod is considered sandboxed or
|
||||
@@ -499,5 +526,3 @@ kernel. This allows for workloads requiring heightened permissions to still be i
|
||||
|
||||
Additionally, the protection of sandboxed workloads is highly dependent on the method of
|
||||
sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user