Merge remote-tracking branch 'upstream/main' into dev-1.24

content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md

@@ -18,7 +18,7 @@ The paper attempts to _not_ focus on any specific [cloud native project](https:/
 
 ## Kubernetes native security controls
 When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:
-* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
+* [Pod Security Policies](/docs/concepts/security/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
 * [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
 * [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
 * [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster

content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md

@@ -21,7 +21,7 @@ Until then, PSP is still PSP. There will be at least a year during which the new
 
 ## What is PodSecurityPolicy?
 
-[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) is a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification. 
+[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) is a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification. 
 
 First, one or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual. In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields. If a Pod does not meet the PSP requirements, it is rejected, and cannot run. 
 

content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md

@@ -175,7 +175,7 @@ require internet access to update the vulnerability database.
 
 ### Pod Security Policies
 
-Since Kubernetes v1.21, the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) 
+Since Kubernetes v1.21, the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) 
 API and related features are [deprecated](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/),
 but some of the guidance in this section will still apply for the next few years, until cluster operators
 upgrade their clusters to newer Kubernetes versions.

content/en/blog/_posts/2021-11-09-non-root-containers-and-devices.md

@@ -18,7 +18,7 @@ One of the key security principles for running containers in Kubernetes is the
 principle of least privilege. The Pod/container `securityContext` specifies the config
 options to set, e.g., Linux capabilities, MAC policies, and user/group ID values to achieve this.
 
-Furthermore, the cluster admins are supported with tools like [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) (deprecated) or
+Furthermore, the cluster admins are supported with tools like [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) (deprecated) or
 [Pod Security Admission](/docs/concepts/security/pod-security-admission/) (alpha) to enforce the desired security settings for pods that are being deployed in
 the cluster. These settings could, for instance, require that containers must be `runAsNonRoot` or
 that they are forbidden from running with root's group ID in `runAsGroup` or `supplementalGroups`.

content/en/blog/_posts/2021-12-09-pod-security-admission-beta.md

@@ -9,7 +9,7 @@ slug: pod-security-admission-beta
 
 With the release of Kubernetes v1.23, [Pod Security admission](/docs/concepts/security/pod-security-admission/) has now entered beta. Pod Security is a [built-in](/docs/reference/access-authn-authz/admission-controllers/) admission controller that evaluates pod specifications against a predefined set of [Pod Security Standards](/docs/concepts/security/pod-security-standards/) and determines whether to `admit` or `deny` the pod from running.
 
-Pod Security is the successor to [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) which was deprecated in the v1.21 release, and will be removed in Kubernetes v1.25. In this article, we cover the key concepts of Pod Security along with how to use it. We hope that cluster administrators and developers alike will use this new mechanism to enforce secure defaults for their workloads.
+Pod Security is the successor to [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) which was deprecated in the v1.21 release, and will be removed in Kubernetes v1.25. In this article, we cover the key concepts of Pod Security along with how to use it. We hope that cluster administrators and developers alike will use this new mechanism to enforce secure defaults for their workloads.
 
 ## Why Pod Security
 

content/en/blog/_posts/2022-03-31-ready-for-dockershim-removal.md

@@ -14,7 +14,7 @@ Way back in December of 2020, Kubernetes announced the [deprecation of Dockershi
 
 If you are rolling your own cluster or are otherwise unsure whether or not this removal affects you, stay on the safe side and [check to see if you have any dependencies on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). Please note that using Docker Desktop to build your application containers is not a Docker dependency for your cluster. Container images created by Docker are compliant with the [Open Container Initiative (OCI)](https://opencontainers.org/), a Linux Foundation governance structure that defines industry standards around container formats and runtimes. They will work just fine on any container runtime supported by Kubernetes.
 
-If you are using a managed Kubernetes service from a cloud provider, and you haven’t explicitly changed the container runtime, there may be nothing else for you to do. Amazon EKS, Azure AKS, and Google GKE all default to containerd now, though you should make sure they do not need updating if you have any node customizations. To check the runtime of your nodes, follow [Find Out What Container Runtime is Used on a Node](​​/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
+If you are using a managed Kubernetes service from a cloud provider, and you haven’t explicitly changed the container runtime, there may be nothing else for you to do. Amazon EKS, Azure AKS, and Google GKE all default to containerd now, though you should make sure they do not need updating if you have any node customizations. To check the runtime of your nodes, follow [Find Out What Container Runtime is Used on a Node](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
 
 Regardless of whether you are rolling your own cluster or using a managed Kubernetes service from a cloud provider, you may need to [migrate telemetry or security agents that rely on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/). 
 

content/en/docs/concepts/architecture/garbage-collection.md

@@ -13,7 +13,7 @@ allows the clean up of resources like the following:
   * [Objects without owner references](#owners-dependents)
   * [Unused containers and container images](#containers-images)
   * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
-  * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
+  * [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
   * {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
     * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
     * On-premises when the cluster uses an addon similar to a cloud controller

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -134,7 +134,7 @@ Mi, Ki. For example, the following represent roughly the same value:
 128974848, 129e6, 129M,  128974848000m, 123Mi
 ```
 
-Take care about case for suffixes. If you request `400m` of memory, this is a request
+Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request
 for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
 or 400 megabytes (`400M`).
 

content/en/docs/concepts/extend-kubernetes/_index.md

@@ -46,7 +46,7 @@ Customization approaches can be broadly divided into *configuration*, which only
 
 Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
 
-*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
+*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
 
 ## Extensions
 

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -348,6 +348,7 @@ Here are some examples of device plugin implementations:
 * The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
 * The [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
 * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
+* The [SocketCAN device plugin](https://github.com/collabora/k8s-socketcan)
 * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
 * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
 * The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices

content/en/docs/concepts/security/controlling-access.md

@@ -129,6 +129,12 @@ The available Admission Control modules are described in [Admission Controllers]
 Once a request passes all admission controllers, it is validated using the validation routines
 for the corresponding API object, and then written to the object store (shown as step **4**).
 
+## Auditing
+
+Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
+The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
+
+For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/).
 
 ## API server ports and IPs
 

content/en/docs/concepts/security/pod-security-admission.md

@@ -21,7 +21,7 @@ behavior of pods in a clear, consistent fashion.
 
 As a Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
 text="admission controller" term_id="admission-controller" >}}, the successor
-to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
+to [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/). Pod security restrictions
 are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
 are created.
 
@@ -55,7 +55,7 @@ are available at [https://git.k8s.io/pod-security-admission/webhook](https://git
 
 To install:
 ```shell
-git clone git@github.com:kubernetes/pod-security-admission.git
+git clone https://github.com/kubernetes/pod-security-admission.git
 cd pod-security-admission/webhook
 make certs
 kubectl apply -k .

content/en/docs/concepts/security/pod-security-standards.md

@@ -452,7 +452,7 @@ of individual policies are not defined here.
 - {{< example file="security/podsecurity-baseline.yaml" >}}Baseline namespace{{< /example >}}
 - {{< example file="security/podsecurity-restricted.yaml" >}}Restricted namespace{{< /example >}}
 
-[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) (Deprecated)
+[**PodSecurityPolicy**](/docs/concepts/security/pod-security-policy/) (Deprecated)
 
 - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
 - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}

content/en/docs/concepts/services-networking/network-policies.md

@@ -281,7 +281,7 @@ the policy will be applied only for the single `port` field.
 
 ## Targeting a Namespace by its name
 
-{{< feature-state state="beta" for_k8s_version="1.21" >}}
+{{< feature-state for_k8s_version="1.22" state="stable" >}}
 
 The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all
 namespaces, provided that the `NamespaceDefaultLabelName`

content/en/docs/concepts/storage/ephemeral-volumes.md

@@ -126,10 +126,10 @@ standardized. See the documentation of each CSI driver for further
 instructions.
 
 ### CSI driver restrictions
- 
+
 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
 
-As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) to control which CSI drivers can be used in a Pod, specified with the
+As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) to control which CSI drivers can be used in a Pod, specified with the
 [`allowedCSIDrivers` field](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy).
 
 {{< note >}}
@@ -250,13 +250,12 @@ PVCs indirectly if they can create Pods, even if they do not have
 permission to create PVCs directly. Cluster administrators must be
 aware of this. If this does not fit their security model, they have
 two choices:
-- Use a [Pod Security
-  Policy](/docs/concepts/policy/pod-security-policy/) where the
-  `volumes` list does not contain the `ephemeral` volume type
-  (deprecated in Kubernetes 1.21).
 - Use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
-  which rejects objects like Pods that have a generic ephemeral
+  that rejects objects like Pods that have a generic ephemeral
   volume.
+- Use a [Pod Security Policy](/docs/concepts/security/pod-security-policy/)
+  where the `volumes` list does not contain the `ephemeral` volume type
+  (deprecated since Kubernetes 1.21).
 
 The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so
 even if users are allowed to use this new mechanism, they cannot use

content/en/docs/concepts/storage/projected-volumes.md

@@ -54,8 +54,7 @@ into a Pod at a specified path. For example:
 
 The example Pod has a projected volume containing the injected service account
 token. Containers in this Pod can use that token to access the Kubernetes API
-server, authenticating with the identity of [the pod's ServiceAccount]
-(/docs/tasks/configure-pod-container/configure-service-account/).
+server, authenticating with the identity of [the pod's ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/).
 The `audience` field contains the intended audience of the
 token. A recipient of the token must identify itself with an identifier specified
 in the audience of the token, and otherwise should reject the token. This field

content/en/docs/concepts/workloads/pods/_index.md

@@ -261,8 +261,7 @@ Within a Pod, containers share an IP address and port space, and
 can find each other via `localhost`. The containers in a Pod can also communicate
 with each other using standard inter-process communications like SystemV semaphores
 or POSIX shared memory.  Containers in different Pods have distinct IP addresses
-and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
+and can not communicate by OS-level IPC without special configuration.
 Containers that want to interact with a container running in a different Pod can
 use IP networking to communicate.
 

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -712,7 +712,7 @@ for more information.
 This admission controller acts on creation and modification of the pod and determines if it should be admitted
 based on the requested security context and the available Pod Security Policies.
 
-See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
+See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation
 for more information.
 
 ### PodTolerationRestriction {#podtolerationrestriction}
@@ -773,14 +773,17 @@ for more information.
 
 ### SecurityContextDeny {#securitycontextdeny}
 
-This admission controller will deny any pod that attempts to set certain escalating
+This admission controller will deny any Pod that attempts to set certain escalating
 [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
 fields, as shown in the
 [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
 task.
-This should be enabled if a cluster doesn't utilize 
-[pod security policies](/docs/concepts/policy/pod-security-policy/)
-to restrict the set of values a security context can take.
+If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/),
+[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism,
+then you could use this admission controller to restrict the set of values a security context can take.
+
+See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for more context on restricting
+pod privileges.
 
 ### ServiceAccount {#serviceaccount}
 

content/en/docs/reference/access-authn-authz/authentication.md

@@ -121,7 +121,7 @@ token,user,uid,"group1,group2,group3"
 
 When using bearer token authentication from an http client, the API
 server expects an `Authorization` header with a value of `Bearer
-THETOKEN`.  The bearer token must be a character sequence that can be
+<token>`.  The bearer token must be a character sequence that can be
 put in an HTTP header value using no more than the encoding and
 quoting facilities of HTTP.  For example: if the bearer token is
 `31ada4fd-adec-460c-809a-9e56ceb75269` then it would appear in an HTTP

content/en/docs/reference/access-authn-authz/authorization.md

@@ -76,7 +76,7 @@ DELETE    | delete (for individual resources), deletecollection (for collections
 
 Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
 
-* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)
+* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
   * `use` verb on `podsecuritypolicies` resources in the `policy` API group.
 * [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
   * `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.