whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Windows HostProcess Container Documentation (#28413)

Browse Source 
* 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:
Brandon Smith
2021-07-27 00:50:45 -07:00
committed by GitHub
parent acc7252970
commit af2f72ad59
4 changed files with 247 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/security/pod-security-standards.md
+28 -3
View File
@@ -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.
content/en/docs/concepts/workloads/pods/_index.md
+3 -2
View File
@@ -257,8 +257,9 @@ section.
## Privileged mode for containers
Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
Processes within a privileged container get almost the same privileges that are available to processes outside a container.
In Linux, any container in a Pod can enable privileged mode using the `privileged` (Linux) flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices.
If your cluster has the `WindowsHostProcessContainers` feature enabled, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod) by setting the `windowsOptions.hostProcess` flag on the security context of the pod spec. All containers in these pods must run as Windows HostProcess containers. HostProcess pods run directly on the host and can also be used to perform administrative tasks as is done with Linux privileged containers.
{{< note >}}
Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.