kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #44311 from apeabody/patch-1 

consistency updates for pod security standards documentation
This commit is contained in:
Kubernetes Prow Robot 2024-07-30 12:34:26 -07:00 committed by GitHub
parent 519e62c5ca d421b5814e
commit 856df61cb3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
content/en/docs/concepts/security/pod-security-standards.md
View File

@ -29,9 +29,9 @@ This guide outlines the requirements of each policy.
**The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is
typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
The Privileged policy is defined by an absence of restrictions. Allow-by-default
mechanisms (such as gatekeeper) may be Privileged by default. In contrast, for a deny-by-default mechanism (such as Pod
Security Policy) the Privileged policy should disable all restrictions.
The Privileged policy is defined by an absence of restrictions. If you define a Pod where the Privileged
security policy applies, the Pod you define is able to bypass typical container isolation mechanisms.
For example, you can define a Pod that has access to the node's host network.
### Baseline
@ -57,7 +57,7 @@ fail validation.
<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. {{< feature-state for_k8s_version="v1.26" state="stable" >}}</p>
<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 host machine. Privileged access to the host is disallowed in the Baseline policy. {{< feature-state for_k8s_version="v1.26" state="stable" >}}</p>
<p><strong>Restricted Fields</strong></p>
<ul>
<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
@ -317,12 +317,12 @@ fail validation.
<td><strong>Policy</strong></td>
</tr>
<tr>
<td colspan="2"><em>Everything from the baseline profile.</em></td>
<td colspan="2"><em>Everything from the Baseline policy</em></td>
</tr>
<tr>
<td style="white-space: nowrap">Volume Types</td>
<td>
<p>The restricted policy only permits the following volume types.</p>
<p>The Restricted policy only permits the following volume types.</p>
<p><strong>Restricted Fields</strong></p>
<ul>
<li><code>spec.volumes[*]</code></li>
@ -488,15 +488,14 @@ workloads. Specifically, many of the Pod `securityContext` fields
[have no effect on Windows](/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext).
{{< note >}}
Kubelets prior to v1.24 don't enforce the pod OS field, and if a cluster has nodes on versions earlier than v1.24 the restricted policies should be pinned to a version prior to v1.25.
Kubelets prior to v1.24 don't enforce the pod OS field, and if a cluster has nodes on versions earlier than v1.24 the Restricted policies should be pinned to a version prior to v1.25.
{{< /note >}}
### Restricted Pod Security Standard changes
Another important change, made in Kubernetes v1.25 is that the _restricted_ Pod security
Another important change, made in Kubernetes v1.25 is that the _Restricted_ policy
has been updated to use the `pod.spec.os.name` field. Based on the OS name, certain policies that are specific
to a particular OS can be relaxed for the other OS.
#### OS-specific policy controls
Restrictions on the following controls are only required if `.spec.os.name` is not `windows`:
- Privilege Escalation
@ -511,10 +510,10 @@ the [documentation](/docs/concepts/workloads/pods/user-namespaces#integration-wi
## FAQ
### Why isn't there a profile between privileged and baseline?
### Why isn't there a profile between Privileged and Baseline?
The three profiles defined here have a clear linear progression from most secure (restricted) to least
secure (privileged), and cover a broad set of workloads. Privileges required above the baseline
The three profiles defined here have a clear linear progression from most secure (Restricted) to least
secure (Privileged), and cover a broad set of workloads. Privileges required above the Baseline
policy are typically very application specific, so we do not offer a standard profile in this
niche. This is not to say that the privileged profile should always be used in this case, but that
policies in this space need to be defined on a case-by-case basis.