From 9d88f2d764ea60a4393feaee80174d9206cf700e Mon Sep 17 00:00:00 2001
From: Rayan Das <rayandas91@gmail.com>
Date: Thu, 24 Apr 2025 14:08:49 +0530
Subject: [PATCH 01/13] Tracking commit for v1.34 docs


From c807d9c6f7a5b8273b6025a5b85c339fa3f27337 Mon Sep 17 00:00:00 2001
From: Anish Ramasekar <anish.ramasekar@gmail.com>
Date: Tue, 17 Jun 2025 17:43:03 -0700
Subject: [PATCH 02/13] Add docs for Structured Authn GA

Signed-off-by: Anish Ramasekar <anish.ramasekar@gmail.com>
---
 .../reference/access-authn-authz/authentication.md     | 10 +++++-----
 .../StructuredAuthenticationConfiguration.md           | 10 +++++++---
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index 5534ac6bab442..2ddc9b7f90975 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -380,7 +380,7 @@ command line arguments, and use the configuration file instead.
 # CAUTION: this is an example configuration.
 #          Do not use this for your own cluster!
 #
-apiVersion: apiserver.config.k8s.io/v1beta1
+apiVersion: apiserver.config.k8s.io/v1
 kind: AuthenticationConfiguration
 # list of authenticators to authenticate Kubernetes users using JWT compliant tokens.
 # the maximum number of allowed authenticators is 64.
@@ -513,7 +513,7 @@ jwt:
   {{< tabs name="example_configuration" >}}
   {{% tab name="Valid token" %}}
   ```yaml
-  apiVersion: apiserver.config.k8s.io/v1beta1
+  apiVersion: apiserver.config.k8s.io/v1
   kind: AuthenticationConfiguration
   jwt:
   - issuer:
@@ -574,7 +574,7 @@ jwt:
   {{% /tab %}}
   {{% tab name="Fails claim validation" %}}
   ```yaml
-  apiVersion: apiserver.config.k8s.io/v1beta1
+  apiVersion: apiserver.config.k8s.io/v1
   kind: AuthenticationConfiguration
   jwt:
   - issuer:
@@ -625,7 +625,7 @@ jwt:
   {{% /tab %}}
   {{% tab name="Fails user validation" %}}
   ```yaml
-  apiVersion: apiserver.config.k8s.io/v1beta1
+  apiVersion: apiserver.config.k8s.io/v1
   kind: AuthenticationConfiguration
   jwt:
   - issuer:
@@ -1095,7 +1095,7 @@ A sample authentication configuration file is below:
 # CAUTION: this is an example configuration.
 #          Do not use this for your own cluster!
 #
-apiVersion: apiserver.config.k8s.io/v1beta1
+apiVersion: apiserver.config.k8s.io/v1
 kind: AuthenticationConfiguration
 anonymous:
   enabled: true
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/StructuredAuthenticationConfiguration.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/StructuredAuthenticationConfiguration.md
index 11c4f11ab09b5..976e21ad85b5a 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/StructuredAuthenticationConfiguration.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/StructuredAuthenticationConfiguration.md
@@ -6,13 +6,17 @@ _build:
   render: false
 
 stages:
-  - stage: alpha 
+  - stage: alpha
     defaultValue: false
     fromVersion: "1.29"
     toVersion: "1.29"
   - stage: beta
     defaultValue: true
-    fromVersion: "1.30"  
+    fromVersion: "1.30"
+    toVersion: "1.33"
+  - stage: stable
+    defaultValue: true
+    fromVersion: "1.34"
 ---
-Enable [structured authentication configuration](/docs/reference/access-authn-authz/authentication/#configuring-the-api-server) 
+Enable [structured authentication configuration](/docs/reference/access-authn-authz/authentication/#configuring-the-api-server)
 for the API server.

From d3b9281256ab7168d7505c1e341fcefbae77f73d Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" <neolit123@gmail.com>
Date: Sat, 28 Jun 2025 12:36:20 +0200
Subject: [PATCH 03/13] kubeadm-init.md: update
 WaitForAllControlPlaneComponents

---
 content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 7b03e693d87d6..62d79f95f641f 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -157,7 +157,7 @@ Feature | Default | Alpha | Beta | GA
 :-------|:--------|:------|:-----|:----
 `ControlPlaneKubeletLocalMode` | `true` | 1.31 | 1.33 | -
 `NodeLocalCRISocket` | `false` | 1.32 | - | -
-`WaitForAllControlPlaneComponents` | `true` | 1.30 | 1.33 | -
+`WaitForAllControlPlaneComponents` | `true` | 1.30 | 1.33 | 1.34
 {{< /table >}}
 
 {{< note >}}

From 2b5803b6c7d73c84bba539844e408643eb4d39d3 Mon Sep 17 00:00:00 2001
From: Tim Hockin <thockin@google.com>
Date: Tue, 1 Jul 2025 08:58:25 -0700
Subject: [PATCH 04/13] Document KYAML

---
 content/en/docs/reference/kubectl/_index.md          | 5 +++--
 content/en/docs/reference/kubectl/quick-reference.md | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/content/en/docs/reference/kubectl/_index.md b/content/en/docs/reference/kubectl/_index.md
index 1396981bfd06d..4924dde922d41 100644
--- a/content/en/docs/reference/kubectl/_index.md
+++ b/content/en/docs/reference/kubectl/_index.md
@@ -270,9 +270,10 @@ Output format | Description
 `-o json`     | Output a JSON formatted API object.
 `-o jsonpath=<template>` | Print the fields defined in a [jsonpath](/docs/reference/kubectl/jsonpath/) expression.
 `-o jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath/) expression in the `<filename>` file.
+`-o kyaml`    | Output a KYAML formatted API object (alpha, requires environment variable `KUBECTL_KYAML="true"`).
 `-o name`     | Print only the resource name and nothing else.
 `-o wide`     | Output in the plain-text format with any additional information. For pods, the node name is included.
-`-o yaml`     | Output a YAML formatted API object.
+`-o yaml`     | Output a YAML formatted API object. KYAML is an experimental Kubernetes-specific dialect of YAML, and can be parsed as YAML.
 
 ##### Example
 
@@ -586,4 +587,4 @@ Current user: plugins-user
 * Learn about [`kubectl` usage conventions](/docs/reference/kubectl/conventions/)
 * Read about [JSONPath support](/docs/reference/kubectl/jsonpath/) in kubectl
 * Read about how to [extend kubectl with plugins](/docs/tasks/extend-kubectl/kubectl-plugins)
-  * To find out more about plugins, take a look at the [example CLI plugin](https://github.com/kubernetes/sample-cli-plugin).
+  * To find out more about plugins, take a look at the [example CLI plugin](https://github.com/kubernetes/sample-cli-plugin).
\ No newline at end of file
diff --git a/content/en/docs/reference/kubectl/quick-reference.md b/content/en/docs/reference/kubectl/quick-reference.md
index 43df826c323ff..6a76ddb174dcb 100644
--- a/content/en/docs/reference/kubectl/quick-reference.md
+++ b/content/en/docs/reference/kubectl/quick-reference.md
@@ -461,6 +461,7 @@ Output format | Description
 `-o=json`     | Output a JSON formatted API object
 `-o=jsonpath=<template>` | Print the fields defined in a [jsonpath](/docs/reference/kubectl/jsonpath) expression
 `-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath) expression in the `<filename>` file
+`-o=kyaml`    | Output a KYAML formatted API object (alpha, requires environment variable `KUBECTL_KYAML="true"`). KYAML is an experimental Kubernetes-specific dialect of YAML, and can be parsed as YAML.
 `-o=name`     | Print only the resource name and nothing else
 `-o=wide`     | Output in the plain-text format with any additional information, and for pods, the node name is included
 `-o=yaml`     | Output a YAML formatted API object
@@ -510,4 +511,4 @@ Verbosity | Description
 
 * Also read [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use kubectl in reusable scripts.
 
-* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
+* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
\ No newline at end of file

From 78dc078e7085f4a0eb080189e31f64d199091c1e Mon Sep 17 00:00:00 2001
From: carlory <baofa.fan@daocloud.io>
Date: Tue, 7 Jan 2025 15:35:32 +0800
Subject: [PATCH 05/13] mark PodDisruptionConditions as removed

Signed-off-by: carlory <baofa.fan@daocloud.io>
---
 .../feature-gates/PodDisruptionConditions.md                   | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
index bd2fc3a40ae2d..5dd13987a2a22 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
@@ -17,5 +17,8 @@ stages:
   - stage: stable
     defaultValue: true
     fromVersion: "1.31"
+    toVersion: "1.33"
+
+removed: true
 ---
 Enables support for appending a dedicated pod condition indicating that the pod is being deleted due to a disruption.

From c900a025d1dc66e420cb6215ec0d281b05e22398 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=9D=A8=E6=9C=B1=20=C2=B7=20Kiki?= <baofa.fan@daocloud.io>
Date: Fri, 4 Jul 2025 18:04:53 +0800
Subject: [PATCH 06/13] Update PodDisruptionConditions.md

---
 .../feature-gates/PodDisruptionConditions.md                    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
index 5dd13987a2a22..99e0e56efaaa0 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodDisruptionConditions.md
@@ -21,4 +21,4 @@ stages:
 
 removed: true
 ---
-Enables support for appending a dedicated pod condition indicating that the pod is being deleted due to a disruption.
+Enabled support for appending a dedicated pod condition indicating that the pod is being deleted due to a disruption.

From 74b7cab46992ac2c2a74a22c730630a22fb9101f Mon Sep 17 00:00:00 2001
From: Vinayak Goyal <vinaygo@google.com>
Date: Wed, 7 May 2025 21:53:30 +0000
Subject: [PATCH 07/13] KEP-4633: Graduate to Stable.

---
 .../feature-gates/AnonymousAuthConfigurableEndpoints.md      | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/AnonymousAuthConfigurableEndpoints.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/AnonymousAuthConfigurableEndpoints.md
index f731f04625a33..08ca121519305 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/AnonymousAuthConfigurableEndpoints.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/AnonymousAuthConfigurableEndpoints.md
@@ -13,6 +13,11 @@ stages:
   - stage: beta 
     defaultValue: true
     fromVersion: "1.32"
+    toVersion: "1.33"
+  - stage: stable
+    defaultValue: true
+    fromVersion: "1.34"
+    locked: true
 ---
 Enable [configurable endpoints for anonymous auth](/docs/reference/access-authn-authz/authentication/#anonymous-authenticator-configuration)
 for the API server.

From 6b081ddd1ae0dd16ddbb47d98a66fbe27ff5b19c Mon Sep 17 00:00:00 2001
From: rfranzke <rafael.franzke@sap.com>
Date: Mon, 7 Jul 2025 10:03:23 +0200
Subject: [PATCH 08/13] Document new `cache{A,Una}uthorizedRequests` field in
 `AuthorizationConfiguration`

---
 .../reference/access-authn-authz/authorization.md    | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md
index 292bf6f8ae4e8..204ac36bf473a 100644
--- a/content/en/docs/reference/access-authn-authz/authorization.md
+++ b/content/en/docs/reference/access-authn-authz/authorization.md
@@ -219,11 +219,23 @@ authorizers:
       # Same as setting `--authorization-webhook-cache-authorized-ttl` flag
       # Default: 5m0s
       authorizedTTL: 30s
+      # If set to false, 'authorized' responses from the webhook are not cached
+      # and the specified authorizedTTL is ignored/has no effect.
+      # Same as setting `--authorization-webhook-cache-authorized-ttl` flag to `0`.
+      # Note: Setting authorizedTTL to `0` results in its default value being used.
+      # Default: true
+      cacheAuthorizedRequests: true
       # The duration to cache 'unauthorized' responses from the webhook
       # authorizer.
       # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag
       # Default: 30s
       unauthorizedTTL: 30s
+      # If set to false, 'unauthorized' responses from the webhook are not cached
+      # and the specified unauthorizedTTL is ignored/has no effect.
+      # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag to `0`.
+      # Note: Setting unauthorizedTTL to `0` results in its default value being used.
+      # Default: true
+      cacheUnauthorizedRequests: true
       # Timeout for the webhook request
       # Maximum allowed is 30s.
       # Required, with no default.

From d60ae4dff1a3d78f7bb1a81abcefcebd87074a7f Mon Sep 17 00:00:00 2001
From: Cici Huang <cicih@google.com>
Date: Mon, 7 Jul 2025 17:40:38 +0000
Subject: [PATCH 09/13] Update doc for 5080

---
 .../feature-gates/OrderedNamespaceDeletion.md                 | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
index 7ed57df3161ff..067b3a6ae974e 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
@@ -13,5 +13,9 @@ stages:
   - stage: beta
     defaultValue: true
     fromVersion: "1.33"
+    toVersion: "1.33"
+  - stage: stable
+    defaultValue: true
+    fromVersion: "1.34"
 ---
 Enables the pods being deleted before the rest of resources while namespace deletion.

From 74ef2a128be029fc9cb64bc288a0b4ab58cdb3d9 Mon Sep 17 00:00:00 2001
From: Cici Huang <cicih@google.com>
Date: Wed, 9 Jul 2025 20:51:41 +0000
Subject: [PATCH 10/13] Address comments

---
 .../feature-gates/OrderedNamespaceDeletion.md                   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
index 067b3a6ae974e..3593e45348aaf 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/OrderedNamespaceDeletion.md
@@ -18,4 +18,4 @@ stages:
     defaultValue: true
     fromVersion: "1.34"
 ---
-Enables the pods being deleted before the rest of resources while namespace deletion.
+While deleting namespace, the pods resources is going to be deleted before the rest of resources.

From e5435b0e733067c8270539fdf1af6b09b4eb3839 Mon Sep 17 00:00:00 2001
From: HirazawaUi <695097494plus@gmail.com>
Date: Fri, 4 Jul 2025 23:28:02 +0800
Subject: [PATCH 11/13] Add documentation for graduating the NodeLocalCRISocket
 to Beta

---
 .../labels-annotations-taints/_index.md        | 10 +++++-----
 .../kubeadm/implementation-details.md          | 10 ++++++++--
 .../setup-tools/kubeadm/kubeadm-init.md        |  2 +-
 .../tools/kubeadm/kubelet-integration.md       | 16 ++++++++++------
 .../kubeadm/configure-cgroup-driver.md         |  4 ++++
 .../change-runtime-containerd.md               | 18 ++++--------------
 .../docs/tasks/debug/debug-cluster/_index.md   |  2 --
 7 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md
index 0a7701d04e104..7b27c2e718337 100644
--- a/content/en/docs/reference/labels-annotations-taints/_index.md
+++ b/content/en/docs/reference/labels-annotations-taints/_index.md
@@ -2695,7 +2695,7 @@ See more details on [Audit Annotations](/docs/reference/labels-annotations-taint
 
 ## kubeadm
 
-### kubeadm.alpha.kubernetes.io/cri-socket
+### kubeadm.alpha.kubernetes.io/cri-socket (deprecated) {#kubeadm-alpha-kubernetes-io-cri-socket}
 
 Type: Annotation
 
@@ -2703,10 +2703,10 @@ Example: `kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/contain
 
 Used on: Node
 
-Annotation that kubeadm uses to preserve the CRI socket information given to kubeadm at
-`init`/`join` time for later use. kubeadm annotates the Node object with this information.
-The annotation remains "alpha", since ideally this should be a field in KubeletConfiguration
-instead.
+{{< note >}}
+Starting from v1.34, this annotation is deprecated, kubeadm will no longer actively set and use it.
+{{< /note >}}
+
 
 ### kubeadm.kubernetes.io/etcd.advertise-client-urls
 
diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
index 354f66b4f03ab..5a4dc89d799c0 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
@@ -674,7 +674,10 @@ upgrades the control plane node where it's run. The steps it performs are:
   for the kubelet to restart the components if the files have changed.
 - Uploads the updated kubeadm and kubelet configurations to the cluster in the `kubeadm-config`
   and the `kubelet-config` ConfigMaps (both in the `kube-system` namespace).
-- Writes updated kubelet configuration for this node in `/var/lib/kubelet/config.yaml`.
+- Writes updated kubelet configuration for this node in `/var/lib/kubelet/config.yaml`,
+  and read the node's `/var/lib/kubelet/instance-config.yaml` file
+  and patch fields like `containerRuntimeEndpoint`
+  from this instance configuration into `/var/lib/kubelet/config.yaml`. 
 - Configures bootstrap token and the `cluster-info` ConfigMap for RBAC rules. This is the same as
   in the `kubeadm init` stage and ensures that the cluster continues to support nodes joining with bootstrap tokens.
 - Upgrades the kube-proxy and CoreDNS addons conditionally if all existing kube-apiservers in the cluster
@@ -691,7 +694,10 @@ infers that there is a running kube-apiserver Pod on this node.
 - Runs preflight checks similarly to `kubeadm upgrade apply`.
 - For control plane nodes, upgrades the control plane manifest files on disk in `/etc/kubernetes/manifests`
   and waits for the kubelet to restart the components if the files have changed.
-- Writes the updated kubelet configuration for this node in `/var/lib/kubelet/config.yaml`.
+- Writes updated kubelet configuration for this node in `/var/lib/kubelet/config.yaml`,
+  and read the node's `/var/lib/kubelet/instance-config.yaml` file and
+  patch fields like `containerRuntimeEndpoint`
+  from this instance configuration into `/var/lib/kubelet/config.yaml`. 
 - (For control plane nodes) upgrades the kube-proxy and CoreDNS
   {{< glossary_tooltip text="addons" term_id="addons" >}} conditionally, provided that all existing
   API servers in the cluster have already been upgraded to the target version.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 62d79f95f641f..eb4f0cebe8d88 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -156,7 +156,7 @@ List of feature gates:
 Feature | Default | Alpha | Beta | GA
 :-------|:--------|:------|:-----|:----
 `ControlPlaneKubeletLocalMode` | `true` | 1.31 | 1.33 | -
-`NodeLocalCRISocket` | `false` | 1.32 | - | -
+`NodeLocalCRISocket` | `true` | 1.32 | 1.34 | -
 `WaitForAllControlPlaneComponents` | `true` | 1.30 | 1.33 | 1.34
 {{< /table >}}
 
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 864900f8e047b..161ac218a7034 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -106,8 +106,11 @@ for more details.
 ### Workflow when using `kubeadm init`
 
 When you call `kubeadm init`, the kubelet configuration is marshalled to disk
-at `/var/lib/kubelet/config.yaml`, and also uploaded to a `kubelet-config` ConfigMap in the `kube-system`
-namespace of the cluster. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf`
+at `/var/lib/kubelet/config.yaml`, and also uploaded to a `kubelet-config` 
+ConfigMap in the `kube-system` namespace of the cluster. 
+Additionally, the kubeadm tool detects the CRI socket on the node and writes its details
+(including the socket path) into a local configuration, `/var/lib/kubelet/instance-config.yaml`.
+A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf`
 with the baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
 points to the client certificates that allow the kubelet to communicate with the API server. This
 addresses the need to
@@ -123,8 +126,7 @@ KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
 ```
 
 In addition to the flags used when starting the kubelet, the file also contains dynamic
-parameters such as the cgroup driver and whether to use a different container runtime socket
-(`--cri-socket`).
+parameters such as the cgroup driver.
 
 After marshalling these two files to disk, kubeadm attempts to run the following two
 commands, if you are using systemd:
@@ -139,8 +141,10 @@ If the reload and restart are successful, the normal `kubeadm init` workflow con
 
 When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
 a TLS bootstrap, which fetches the credential needed to download the
-`kubelet-config` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
-environment file is generated in exactly the same way as `kubeadm init`.
+`kubelet-config` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`.
+Additionally, the kubeadm tool detects the CRI socket on the node and writes its details
+(including the socket path) into a local configuration, `/var/lib/kubelet/instance-config.yaml`.
+The dynamic environment file is generated in exactly the same way as `kubeadm init`.
 
 Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:
 
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md
index c103114317b1c..144092a5598e2 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md
@@ -70,6 +70,10 @@ object under the `kube-system` namespace.
 Executing the sub commands `init`, `join` and `upgrade` would result in kubeadm
 writing the `KubeletConfiguration` as a file under `/var/lib/kubelet/config.yaml`
 and passing it to the local node kubelet.
+
+On each node, kubeadm detects the CRI socket and stores its details into the `/var/lib/kubelet/instance-config.yaml` file.
+When executing the `init`, `join`, or `upgrade` subcommands, 
+kubeadm patches the `containerRuntimeEndpoint` value from this instance configuration into `/var/lib/kubelet/config.yaml`.
 {{< /note >}}
 
 ## Using the `cgroupfs` driver
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
index c3d7e7e92a8a5..fb7d4193ce78c 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
@@ -101,23 +101,13 @@ then run the following commands:
 Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags;
 `--container-runtime-endpoint=unix:///run/containerd/containerd.sock`.
 
-Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
-an annotation in the Node object for that host. To change it you can execute the following command
-on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
+Users using kubeadm should be aware that the kubeadm tool stores the host's CRI socket in the 
 
-```shell
-kubectl edit no <node-name>
-```
-
-This will start a text editor where you can edit the Node object.
-To choose a text editor you can set the `KUBE_EDITOR` environment variable.
+`/var/lib/kubelet/instance-config.yaml` file on each node. You can create this `/var/lib/kubelet/instance-config.yaml` file on the node.
 
-- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
-  to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
-   
-  Note that new CRI socket paths must be prefixed with `unix://` ideally.
+The `/var/lib/kubelet/instance-config.yaml` file allows setting the `containerRuntimeEndpoint` parameter. 
 
-- Save the changes in the text editor, which will update the Node object.
+You can set this parameter's value to the path of your chosen CRI socket (for example `unix:///run/containerd/containerd.sock`).
 
 ## Restart the kubelet
 
diff --git a/content/en/docs/tasks/debug/debug-cluster/_index.md b/content/en/docs/tasks/debug/debug-cluster/_index.md
index cde6043c0327d..d67c8ba696eea 100644
--- a/content/en/docs/tasks/debug/debug-cluster/_index.md
+++ b/content/en/docs/tasks/debug/debug-cluster/_index.md
@@ -71,7 +71,6 @@ Labels:             beta.kubernetes.io/arch=amd64
                     kubernetes.io/arch=amd64
                     kubernetes.io/hostname=kube-worker-1
                     kubernetes.io/os=linux
-Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
                     node.alpha.kubernetes.io/ttl: 0
                     volumes.kubernetes.io/controller-managed-attach-detach: true
 CreationTimestamp:  Thu, 17 Feb 2022 16:46:30 -0500
@@ -144,7 +143,6 @@ apiVersion: v1
 kind: Node
 metadata:
   annotations:
-    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
     node.alpha.kubernetes.io/ttl: "0"
     volumes.kubernetes.io/controller-managed-attach-detach: "true"
   creationTimestamp: "2022-02-17T21:46:30Z"

From cb4b423c93f5687ea4cc8e3f79f4d20d39c5979c Mon Sep 17 00:00:00 2001
From: Jordan Liggitt <liggitt@google.com>
Date: Tue, 1 Jul 2025 12:20:12 -0400
Subject: [PATCH 12/13] KEP-4601: promote to stable

---
 content/en/docs/reference/access-authn-authz/node.md         | 5 +----
 content/en/docs/reference/access-authn-authz/webhook.md      | 5 +++--
 .../feature-gates/AuthorizeNodeWithSelectors.md              | 5 ++++-
 .../feature-gates/AuthorizeWithSelectors.md                  | 4 ++++
 content/en/docs/reference/using-api/cel.md                   | 5 +++--
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/content/en/docs/reference/access-authn-authz/node.md b/content/en/docs/reference/access-authn-authz/node.md
index dd144d7fa1403..3397c5a90722f 100644
--- a/content/en/docs/reference/access-authn-authz/node.md
+++ b/content/en/docs/reference/access-authn-authz/node.md
@@ -29,10 +29,7 @@ Read operations:
 
 {{< feature-state feature_gate_name="AuthorizeNodeWithSelectors" >}}
 
-When the `AuthorizeNodeWithSelectors` feature is enabled
-(along with the pre-requisite `AuthorizeWithSelectors` feature),
-kubelets are only allowed to read their own Node objects,
-and are only allowed to read pods bound to their node.
+Kubelets are limited to reading their own Node objects, and only reading pods bound to their node.
 
 Write operations:
 
diff --git a/content/en/docs/reference/access-authn-authz/webhook.md b/content/en/docs/reference/access-authn-authz/webhook.md
index cb91ac34c60a3..e24d525b9f2bf 100644
--- a/content/en/docs/reference/access-authn-authz/webhook.md
+++ b/content/en/docs/reference/access-authn-authz/webhook.md
@@ -166,8 +166,9 @@ Access to non-resource paths are sent as:
 
 {{< feature-state feature_gate_name="AuthorizeWithSelectors" >}}
 
-With the `AuthorizeWithSelectors` feature enabled, field and label selectors in the request
-are passed to the authorization webhook. The webhook can make authorization decisions
+When calling out to an authorization webhook, Kubernetes passes
+label and field selectors in the request to the authorization webhook.
+The authorization webhook can make authorization decisions
 informed by the scoped field and label selectors, if it wishes.
 
 The [SubjectAccessReview API documentation](/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1/)
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeNodeWithSelectors.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeNodeWithSelectors.md
index db45f7ec27dbd..d4911cdd59b24 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeNodeWithSelectors.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeNodeWithSelectors.md
@@ -13,6 +13,9 @@ stages:
   - stage: beta
     defaultValue: true
     fromVersion: "1.32"
+    toVersion: "1.33"
+  - stage: stable
+    defaultValue: true
+    fromVersion: "1.34"
 ---
 Make the [Node authorizer](/docs/reference/access-authn-authz/node/) use fine-grained selector authorization.
-Requires `AuthorizeWithSelectors` to be enabled.
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeWithSelectors.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeWithSelectors.md
index d53ff8d6305ea..12ef546e869fd 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeWithSelectors.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/AuthorizeWithSelectors.md
@@ -13,6 +13,10 @@ stages:
   - stage: beta
     defaultValue: true
     fromVersion: "1.32"
+    toVersion: "1.33"
+  - stage: stable
+    defaultValue: true
+    fromVersion: "1.34"
 ---
 Allows authorization to use field and label selectors.
 Enables `fieldSelector` and `labelSelector` fields in the [SubjectAccessReview API](/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1/),
diff --git a/content/en/docs/reference/using-api/cel.md b/content/en/docs/reference/using-api/cel.md
index 14b688fc3cc88..cd55d6dfe3842 100644
--- a/content/en/docs/reference/using-api/cel.md
+++ b/content/en/docs/reference/using-api/cel.md
@@ -734,9 +734,10 @@ To perform an authorization check for a service account:
 </tbody>
 </table>
 
-{{< feature-state state="alpha" for_k8s_version="v1.31" >}}
+{{< feature-state feature_gate_name="AuthorizeWithSelectors" >}}
 
-With the alpha `AuthorizeWithSelectors` feature enabled, field and label selectors can be added to authorization checks.
+For CEL expressions in the API where a variable of type `Authorizer` is available,
+field and label selectors can be included in authorization checks.
 
 <table>
 <caption>Examples of CEL expressions using selector authorization functions</caption>

From 8ba16fc3e56ab38aaa8d207cb42b0bcfe850512d Mon Sep 17 00:00:00 2001
From: Taahir Ahmed <taahm@google.com>
Date: Thu, 27 Feb 2025 16:10:16 -0800
Subject: [PATCH 13/13] Refactor Certificates Documentation

---
 .../en/docs/concepts/security/certificates.md | 578 ++++++++++++++++++
 .../concepts/storage/projected-volumes.md     |  55 ++
 .../certificate-signing-requests.md           | 492 +--------------
 .../feature-gates/PodCertificateRequest.md    |  15 +
 .../tasks/extend-kubernetes/custom-signer.md  | 157 +++++
 .../clusterrole-sign.yaml                     |  27 +
 .../storage/projected-podcertificate.yaml     |  26 +
 7 files changed, 867 insertions(+), 483 deletions(-)
 create mode 100644 content/en/docs/concepts/security/certificates.md
 create mode 100644 content/en/docs/reference/command-line-tools-reference/feature-gates/PodCertificateRequest.md
 create mode 100644 content/en/docs/tasks/extend-kubernetes/custom-signer.md
 create mode 100644 content/en/examples/access/pod-certificate-request/clusterrole-sign.yaml
 create mode 100644 content/en/examples/pods/storage/projected-podcertificate.yaml

diff --git a/content/en/docs/concepts/security/certificates.md b/content/en/docs/concepts/security/certificates.md
new file mode 100644
index 0000000000000..7fab5dff94fad
--- /dev/null
+++ b/content/en/docs/concepts/security/certificates.md
@@ -0,0 +1,578 @@
+---
+reviewers:
+- liggitt
+- mikedanese
+- munnerz
+- enj
+title: Certificate Provisioning and Trust Distribution
+api_metadata:
+- apiVersion: "certificates.k8s.io/v1"
+  kind: "CertificateSigningRequest"
+  override_link_text: "CSR v1"
+- apiVersion: "certificates.k8s.io/v1beta1"
+  kind: "ClusterTrustBundle"
+- apiVersion: "certificates.k8s.io/v1alpha1"
+  kind: "PodCertificateRequest"  
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+Kubernetes certificate and trust bundle APIs enable automation of
+[X.509](https://www.itu.int/rec/T-REC-X.509) credential provisioning by
+providing a programmatic interface for clients of the Kubernetes API to request
+and obtain X.509 {{< glossary_tooltip term_id="certificate" text="certificates"
+>}} from a Certificate Authority (CA).
+
+The three API types for requesting and trusting certificates are:
+* CertificateSigningRequest: An API type that lets you request an arbitrary
+  certificate from a signer.
+* PodCertificateRequest: (alpha) An API type that lets `kubelet` request
+  certificates to inject into a Pod.
+* ClusterTrustBundle: (beta) A group of certificates (typically CA root
+  certificates) that should be used as roots of trust for verifying a server or
+  client certificate.
+
+<!-- body -->
+
+
+## Signers {#signers}
+
+Kubernetes organizes its certificate provisioning features around the concept of
+a signer.
+
+Each signer is identified by a qualified name built from a DNS name (for
+example, `kubernetes.io/foo`).  Each signer uniquely identifies a category of
+certificates that can be issued within the scope of a particular cluster.
+Kubernetes offers some [built-in signers](#kubernetes-signers), and third-party
+signers may also be freely installed into a cluster.
+
+Note that signers are not a concrete concept in the Kubernetes API &mdash; there
+is no Signer object that you create.  Instead, several types in the
+`certificates.k8s.io` API group have a `signerName` field, and there is special
+authorization logic that lets signers handle all objects that are addressed to a
+particular signer.
+
+Each signer is backed by a set of {{< glossary_tooltip text="controllers"
+term_id="controller" >}} that do one or more of the following things to let
+pods, users, and external workloads provision and verify certificates issued by
+the signer.
+* Certificate issuance: The signer responds to CertificateSigningRequests and
+  PodCertificateRequests addressed to the signer's name.
+* Trust anchor distribution: The controller publishes the trust anchors (root
+  certificates) of the signer for consumption by workloads using either
+  signer-linked ClusterTrustBundles or ConfigMaps
+
+The Kubernetes project provides a set of [built-in signers](#kubernetes-signers)
+that are available in every cluster.  It is also possible to install (or build
+your own) [third-party signers](#third-party-signers).
+
+
+## Certificate signing requests {#certificate-signing-requests}
+
+A
+[CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
+(CSR) is used to request a certificate from a particular signer.
+
+The CSR flow begins when a requester creates a CSR object:
+* `spec.signerName` says which signer should process the CSR.
+* `spec.request` contains a PEM-wrapped PKCS#10 signing request.
+* `spec.expirationSeconds` (optional) allows the requester to ask for a specific
+  lifetime for the issued certificate.
+* `spec.usages` contains the key usages that the requester wants on the issued
+  certificate. 
+
+Once created, a CSR must be approved before it can be signed. Approval is
+indicated by adding an `Approved` entry to `status.conditions`.  Denial is
+indicated by adding a `Denied` entry to `status.conditions`.  Both of these
+conditions must always have `status` set to `True`. These conditions are
+mutually-exclusive.
+
+Different signers have different expectations around their approval workflows,
+so signer authors are encouraged to document whether and how they expect CSRs to
+be approved.  Broadly speaking:
+* Some signers automatically approve conforming CSRs, and will refuse to issue a
+  certificate to a non-conforming CSR.  These signers will move an approved, but
+  non-conforming CSR into the `Failed` terminal state, rather than issuing it.
+  For example, a signer might only want to issue SPIFFE certificates, and so
+  will fail any CSR that requests a non-SPIFFE-formatted CSR.
+* Some signers expect a human reviewer to inspect and approve all
+  CSRs.  The `kubectl certificate approve/deny`
+  convenience commands may be used for this purpose.
+* Some signers operate in a blended mode, where some CSRs are automatically
+  approved and issued, but the signer will also issue certificates to
+  manually-approved CSRs.
+
+Special permissions are required to approve or deny a CSR:
+* Verbs: **update**, group: `certificates.k8s.io`, resource:
+  `certificatesigningrequests/approval`
+* Verbs: **approve**, group: `certificates.k8s.io`, resource: `signers`,
+  resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+Once a CSR is approved, the next step is for the signer's controller to either
+issue a certificate or fail the CSR.
+
+To issue a certificate to a CSR, the controller creates an X.509 certificate
+chain and stores it in the `status.certificate` field of the CSR, encoded as a
+series of PEM `CERTIFICATE` blocks. The signer implementation may, but does not
+have to, consider the CSR's `spec.request` field.  It is free to issue an
+entirely different certificate.
+
+{{< note >}}
+When encoded in JSON or YAML, `status.certificate` field is base-64 encoded, so
+it is not directly readable.  This is handled transparently when using a client
+library.
+{{< /note >}}
+
+Signer implementations are encouraged to:
+* Document whether or not they consider manual approval decisions on
+  CertificateSigningRequests.
+* Document which parts, if any, of the PKCS#10 request they consider.
+* Document the concrete format of the certificates they issue.
+
+Once the `status.certificate` field has been populated, the request has been
+completed and clients can now fetch the signed certificate PEM data from the
+CSR.
+
+If the signer controller does not wish to issue the certificate, even if it has
+been approved, then it can add the `Failed` condition to the CSR, which is a
+terminal state. 
+
+Special permissions are required to sign or fail a CSR:
+* Verbs: **update**, group: `certificates.k8s.io`, resource:
+  `certificatesigningrequests/status`
+* Verbs: **sign**, group: `certificates.k8s.io`, resource: `signers`,
+  resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+Like all conditions, the `status.conditions[].reason` field is meant to contain
+a machine-readable code describing the condition in TitleCase.  The
+`status.conditions[].message` field is meant for a free-form explanation for
+human consumption.
+
+In order to reduce the number of old CSR objects left in a cluster, a garbage
+collection controller runs periodically. The garbage collection removes CSRs
+that have not changed state for some duration:
+
+* Approved requests: automatically deleted after 1 hour
+* Denied requests: automatically deleted after 1 hour
+* Failed requests: automatically deleted after 1 hour
+* Pending requests: automatically deleted after 24 hours
+* All requests: automatically deleted after the issued certificate has expired
+
+
+## PodCertificateRequests {#pod-certificate-requests}
+
+{{< feature-state feature_gate_name="PodCertificateRequest" >}}
+
+{{< note >}}
+In Kubernetes {{< skew currentVersion >}}, you must enable support for Pod
+Certificates using the `PodCertificateRequest` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
+`--runtime-config=certificates.k8s.io/v1alpha1/podcertificaterequests=true`
+kube-apiserver flag.
+{{< /note >}}
+
+PodCertificateRequests are API objects tailored to provisioning certificates to
+workloads running as Pods within a cluster.  The user typically does not
+interact with PodCertificateRequests directly, but uses [podCertificate
+projected volume sources](
+/docs/concepts/storage/projected-volumes#podcertificate), which are a `kubelet`
+feature that handles secure key provisioning and automatic certificate refresh.
+The application inside the pod only needs to know how to read the certificates
+from the filesystem.
+
+PodCertificateRequests are similar to CertificateSigningRequests, but have a
+simpler format enabled by their narrower use case.
+
+A PodCertificateRequest has the following spec fields:
+* `signerName`: The signer to which this request is addressed.
+* `podName` and `podUID`: The Pod that Kubelet is requesting a certificate for.
+* `serviceAccountName` and `serviceAccountUID`: The ServiceAccount corresponding to the Pod.
+* `nodeName` and `nodeUID`: The Node corresponding to the Pod.
+* `maxExpirationSeconds`: The maximum lifetime that the workload author will
+  accept for this certificate.  Defaults to 24 hours if not specified.
+* `pkixPublicKey`: The public key for which the certificate should be issued.
+* `proofOfPossession`: A signature demonstrating that the requester controls the
+  private key corresponding to `pkixPublicKey`.
+
+Nodes automatically receive permissions to create PodCertificateRequests and
+read PodCertificateRequests related to them (as determined by the
+`spec.nodeName` field).  The [NodeRestriction admission
+plugin](/docs/reference/access-authn-authz/admission-controllers#noderestriction),
+if enabled, ensures that nodes can only create PodCertificateRequests that
+correspond to a real pod that is currently running on the node.
+
+After creation, the `spec` of a PodCertificateRequest is immutable.
+
+Unlike CSRs, PodCertificateRequests do not have an
+approval phase.  Once the PodCertificateRequest is created, the signer's
+controller directly decides to issue or deny the request.  It also has the
+option to mark the request as failed, if it encountered a permanent error when
+attempting to issue the request.
+
+To take any of these actions, the signing controller needs to have the
+appropriate permissions on both the PodCertificateRequest type, as well as on
+the signer name:
+* Verbs: **update**, group: `certificates.k8s.io`, resource:
+  `podcertificaterequests/status`
+* Verbs: **sign**, group: `certificates.k8s.io`, resource: `signers`,
+  resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+The signing controller is free to consider other information beyond what's
+contained in the request, but it can rely on the information in the request to
+be accurate.  For example, the signing controller might load the Pod and read
+annotations set on it, or perform a SubjectAccessReview on the ServiceAccount.  
+
+To issue a certificate in response to a request, the signing controller:
+* Adds an `Issued` condition to `status.conditions`.
+* Puts the issued certificate in `status.certificateChain`
+* Puts the `NotBefore` and `NotAfter` fields of the certificate in the
+  `status.notBefore` and `status.notAfter` fields &mdash; these fields are
+  denormalized into the Kubernetes API in order to aid debugging
+* Suggests a time to begin attempting to refresh the certificate using
+  `status.beginRefreshAt`.
+
+To deny a request, the signing controller adds a "Denied" condition to
+`status.conditions[]`.
+
+To mark a request failed, the signing controller adds a "Failed" condition to
+`status.conditions[]`.
+
+All of these conditions are mutually-exclusive, and must have status "True".  No
+other condition types are permitted on PodCertificateRequests.  In addition,
+once any of these conditions are set, the `status` field becomes immutable.
+
+Like all conditions, the `status.conditions[].reason` field is meant to contain
+a machine-readable code describing the condition in TitleCase.  The
+`status.conditions[].message` field is meant for a free-form explanation for
+human consumption.
+
+To ensure that terminal PodCertificateRequests do not build up in the cluster, a
+`kube-controller-manager` controller deletes all PodCertificateRequests older
+than 15 minutes.  All certificate issuance flows are expected to complete within
+this 15-minute limit.
+
+
+## ClusterTrustBundles {#cluster-trust-bundles}
+
+{{< feature-state feature_gate_name="ClusterTrustBundle" >}}
+
+{{< note >}}
+In Kubernetes {{< skew currentVersion >}}, you must enable the `ClusterTrustBundle`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+_and_ the `certificates.k8s.io/v1beta1`
+{{< glossary_tooltip text="API group" term_id="api-group" >}} in order to use
+this API.
+{{< /note >}}
+
+A ClusterTrustBundle is a cluster-scoped object for distributing X.509 trust
+anchors (root certificates) to workloads within the cluster. They're designed
+to work well with the [signer](#signers) concept from CertificateSigningRequests.
+
+ClusterTrustBundles can be used in two modes:
+[signer-linked](#ctb-signer-linked) and [signer-unlinked](#ctb-signer-unlinked).
+
+### Common properties and validation {#ctb-common}
+
+All ClusterTrustBundle objects have strong validation on the contents of their
+`trustBundle` field. That field must contain one or more X.509 certificates,
+DER-serialized, each wrapped in a PEM `CERTIFICATE` block. The certificates
+must parse as valid X.509 certificates.
+
+Esoteric PEM features like inter-block data and intra-block headers are either
+rejected during object validation, or can be ignored by consumers of the object.
+Additionally, consumers are allowed to reorder the certificates in
+the bundle with their own arbitrary but stable ordering.
+
+ClusterTrustBundle objects should be considered world-readable within the
+cluster. If your cluster uses [RBAC](/docs/reference/access-authn-authz/rbac/)
+authorization, all ServiceAccounts have a default grant that allows them to
+**get**, **list**, and **watch** all ClusterTrustBundle objects.
+If you use your own authorization mechanism and you have enabled
+ClusterTrustBundles in your cluster, you should set up an equivalent rule to
+make these objects public within the cluster, so that they work as intended.
+
+If you do not have permission to list cluster trust bundles by default in your
+cluster, you can impersonate a service account you have access to in order to
+see available ClusterTrustBundles:
+
+```bash
+kubectl get clustertrustbundles --as='system:serviceaccount:mynamespace:default'
+```
+
+### Signer-linked ClusterTrustBundles {#ctb-signer-linked}
+
+Signer-linked ClusterTrustBundles are associated with a _signer name_, like this:
+
+```yaml
+apiVersion: certificates.k8s.io/v1beta1
+kind: ClusterTrustBundle
+metadata:
+  name: example.com:mysigner:foo
+spec:
+  signerName: example.com/mysigner
+  trustBundle: "<... PEM data ...>"
+```
+
+These ClusterTrustBundles are intended to be maintained by a signer-specific
+controller in the cluster, so they have several security features:
+
+* To create or update a signer-linked ClusterTrustBundle, you must be permitted
+  to **attest** on the signer (custom authorization verb `attest`,
+  API group `certificates.k8s.io`; resource path `signers`). You can configure
+  authorization for the specific resource name
+  `<signerNameDomain>/<signerNamePath>` or match a pattern such as
+  `<signerNameDomain>/*`.
+* Signer-linked ClusterTrustBundles **must** be named with a prefix derived from
+  their `spec.signerName` field. Slashes (`/`) are replaced with colons (`:`),
+  and a final colon is appended. This is followed by an arbitrary name. For
+  example, the signer `example.com/mysigner` can be linked to a
+  ClusterTrustBundle `example.com:mysigner:<arbitrary-name>`.
+
+Signer-linked ClusterTrustBundles will typically be consumed in workloads
+by a combination of a
+[field selector](/docs/concepts/overview/working-with-objects/field-selectors/) on the signer name, and a separate
+[label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
+
+### Signer-unlinked ClusterTrustBundles {#ctb-signer-unlinked}
+
+Signer-unlinked ClusterTrustBundles have an empty `spec.signerName` field, like this:
+
+```yaml
+apiVersion: certificates.k8s.io/v1beta1
+kind: ClusterTrustBundle
+metadata:
+  name: foo
+spec:
+  # no signerName specified, so the field is blank
+  trustBundle: "<... PEM data ...>"
+```
+
+They are primarily intended for cluster configuration use cases.
+Each signer-unlinked ClusterTrustBundle is an independent object, in contrast to the
+customary grouping behavior of signer-linked ClusterTrustBundles.
+
+Signer-unlinked ClusterTrustBundles have no `attest` verb requirement.
+Instead, you control access to them directly using the usual mechanisms,
+such as role-based access control.
+
+To distinguish them from signer-linked ClusterTrustBundles, the names of
+signer-unlinked ClusterTrustBundles **must not** contain a colon (`:`).
+
+### Accessing ClusterTrustBundles from pods {#ctb-projection}
+
+{{< feature-state feature_gate_name="ClusterTrustBundleProjection" >}}
+
+The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.
+See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
+
+
+## Kubernetes built-in signers {#kubernetes-signers}
+
+Kubernetes provides some built-in signers that should be present in every
+cluster.
+
+{{< caution >}}
+Signer names with domain prefix `kubernetes.io` (including any subdomains) are
+reserved by the Kubernetes project.
+{{< /caution >}}
+
+### `kubernetes.io/kube-apiserver-client` {#built-in-signer-kube-apiserver-client}
+
+This signer issues certificates that will be honored as client certificates by
+the API server.
+
+This signer responds only to CertificateSigningRequests, not
+PodCertificateRequests.
+
+There is no built-in auto-approval controller for this signer; all certificates
+must be manually approved, or a third-party auto-approval controller must be
+installed.
+
+This signer does not distribute its trust bundle, since no party besides the API
+server is intended to verify the certificates it issues.
+
+When this signer's signing controller sees an approved
+CertificateSigningRequest, it will check the following conditions:
+* The `spec.usages` field includes at least "client auth" and at most "client auth", "digital
+  signature", and "key encipherment".
+
+If the conditions are true, the signing controller will issue the certificate.
+Otherwise it will mark the CSR as failed.
+
+The issued certificate has the following properties:
+* The X.509 Subject field Subject Alternate Names extension are copied verbatim
+  from `spec.request`.
+* The "Key Usage" and "Extended Key Usage" extensions are set according to the key
+  usages named in `spec.usages`.
+* No other extensions are included.
+* NotBefore is set to the present time, with reasonable backdating to
+  account for clock skew.
+* NotAfter is set to the present time plus the minimum of `spec.expirationSeconds`
+  and the certificate TTL configured for `kube-controller-manager` (365 days, by
+  default), with reasonable backdating to account for clock skew.
+* The CA bit to false.
+
+{{< caution >}}
+
+Because the API server treats `Subject.CommonName` and `Subject.Organization` as
+the username and groups of the user, you must take care  when approving CSRs
+addressed to this signer.  If you approve CSRs that request identities that are
+internal to the function of your Kubernetes distribution, the user that gets the
+certificate can compromise your cluster.
+
+The `CertificateSubjectRestriction` admission plugin (enabled by default)
+prevents creation of CSRs that would assert membership in the `system:masters`
+group, but this is typically not the only highly-privileged identity present in
+a cluster.
+
+{{</ caution >}}
+
+### `kubernetes.io/kube-apiserver-client-kubelet` {#built-in-signer-kube-apiserver-client-kubelet}
+
+This signer issues certificates that will be honored as `kubelet` client
+certificates by the API server.  It offers no further guarantees on what the
+certificates may be used for.
+
+This signer responds only to CertificateSigningRequests, not
+PodCertificateRequests.
+
+There is a built-in auto-approval controller for this signer.
+
+This signer does not distribute its trust bundle, since no party besides the API
+server is intended to verify the certificates it issues.
+
+When this signer's signing controller sees an approved
+CertificateSigningRequest, it will check the following conditions:
+* The `Subject.CommonName` field has the prefix `system:node:`
+* There is one `Subject.Organization` entry, exactly equal to `system:nodes`
+* There are no entries in the Subject Alternate Name extension
+* The CSR `spec.usages` field is either:
+  * `digital signature` and `client auth`, or
+  * `digital signature`, `client auth`, and `key encipherment`. 
+
+If the conditions are true, the signing controller will issue the certificate.
+Otherwise it will mark the CSR as failed.
+
+The issued certificate has the following properties:
+* The X.509 Subject field Subject Alternate Names extension are copied verbatim
+  from `spec.request`.
+* The "Key Usage" and "Extended Key Usage" extensions are set according to the key
+  usages named in `spec.usages`.
+* No other extensions are included.
+* NotBefore is set to the present time, with reasonable backdating to
+  account for clock skew.
+* NotAfter is set to the present time plus the minimum of `spec.expirationSeconds`
+  and the certificate TTL configured for `kube-controller-manager` (365 days, by
+  default), with reasonable backdating to account for clock skew.
+* The CA bit to false.
+
+### `kubernetes.io/kubelet-serving` {#built-in-signer-kube-apiserver-client-kubelet-serving}
+
+This signer issues certificates that the API server will honor as valid
+`kubelet` serving certificates.  It offers no further guarantees on what the
+certificates may be used for.
+
+This signer responds only to CertificateSigningRequests, not
+PodCertificateRequests.
+
+There is no built-in auto-approval controller for this signer.
+
+This signer does not distribute its trust bundle, since no party besides the API
+server is intended to verify the certificates it issues.
+
+When this signer's signing controller sees an approved
+CertificateSigningRequest, it will check the following conditions:
+* The `Subject.CommonName` field has the prefix `system:node:`
+* There is one `Subject.Organization` entry, exactly equal to `system:nodes`
+* There is at least one DNS or IP entry in Subject Alternate Name extension.
+* There are no Email or URI entries in the Subject Alternate Name extension.
+* The CSR `spec.usages` field is either:
+  * `digital signature` and `server auth`, or
+  * `digital signature`, `server auth`, and `key encipherment`. 
+
+If the conditions are true, the signing controller will issue the certificate.
+Otherwise it will mark the CSR as failed.
+
+The issued certificate has the following properties:
+* The X.509 Subject field Subject Alternate Names extension are copied verbatim
+  from `spec.request`.
+* The "Key Usage" and "Extended Key Usage" extensions are set according to the key
+  usages named in `spec.usages`.
+* No other extensions are included.
+* NotBefore is set to the present time, with reasonable backdating to
+  account for clock skew.
+* NotAfter is set to the present time plus the minimum of `spec.expirationSeconds`
+  and the certificate TTL configured for `kube-controller-manager` (365 days, by
+  default), with reasonable backdating to account for clock skew.
+* The CA bit to false.
+
+### `kubernetes.io/kube-apiserver-serving` {#built-in-signer-kube-apiserver-serving}
+
+{{< feature-state feature_gate_name="ClusterTrustBundle" >}}
+
+This signer does not issue any certificates.  It purely serves to distribute the
+trust anchors that allow workloads within the cluster to verify the API server's
+server certificate when they connect to `kubernetes.default.svc`.
+
+There are three built-in distribution mechanisms for these trust anchors:
+* A built-in controller writes them into the `.data[ca.crt]` field of
+  ServiceAccount token secrets.
+* A built-in controller creates a ConfigMap named `kube-root-ca.crt` in each
+  namespace.  The `.data["ca.crt"]` field of this configmap contains the trust
+  anchors of this signer.
+* (Only when ClusterTrustBundles are enabled) A built-in controller creates a
+  set of signer-linked ClusterTrustBundles for this signer.  Workloads can
+  access them directly, or using `clusterTrustBundle` projected volumes sources
+  (`signerName="kubernetes.io/kube-apiserver-serving"` and
+  `labelSelector.matchLabels={}`).
+
+### `kubernetes.io/legacy-unknown` {#built-in-signer-legacy-unknown}
+
+This signer issues certificates that are not guaranteed to be suitable for any
+purpose.  In some third-party distributions of Kubernetes, the API server may
+accept certificates it issues as client certificates, but this is not a
+standard.
+
+This signer only responds to CertificateSigningRequests, not
+PodCertificateRequests.
+
+There is not built-in auto-approval controller for this signer.
+
+The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and
+later) does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
+
+This signer does not distribute its trust bundle.
+
+When this signer's signing controller sees an approved
+CertificateSigningRequest, it will immediately attempt to issue the certificate
+with no further checks.
+
+The issued certificate has the following properties:
+* The X.509 Subject field Subject Alternate Names extension are copied verbatim
+  from `spec.request`.
+* The "Key Usage" and "Extended Key Usage" extensions are set according to the key
+  usages named in `spec.usages`.
+* No other extensions are included.
+* NotBefore is set to the present time, with reasonable backdating to
+  account for clock skew.
+* NotAfter is set to the present time plus the minimum of `spec.expirationSeconds`
+  and the certificate TTL configured for `kube-controller-manager` (365 days, by
+  default), with reasonable backdating to account for clock skew.
+* The CA bit to false.
+
+
+## Third-party signers {#third-party-signers}
+
+You can also introduce your own custom signer, which should have a similar
+prefixed name but using your own domain name. For example, if you represent an
+open source project that uses the domain `open-fictional.example` then you might
+use `issuer.open-fictional.example/service-mesh` as a signer name.
+
+To implement your custom signer, you need to provide a set of controllers that
+use the Kubernetes API to interact with CertificateSigningRequests,
+PodCertificateRequests, and ClusterTrustBundles that are linked to your signer's
+name.
+
+See [Develop a Custom Signer](/docs/tasks/tls/extend-kubernetes/custom-signer) for more details.
diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md
index 509b4cc31f15a..35c85177363f4 100644
--- a/content/en/docs/concepts/storage/projected-volumes.md
+++ b/content/en/docs/concepts/storage/projected-volumes.md
@@ -25,6 +25,7 @@ Currently, the following types of volume sources can be projected:
 * [`configMap`](/docs/concepts/storage/volumes/#configmap)
 * [`serviceAccountToken`](#serviceaccounttoken)
 * [`clusterTrustBundle`](#clustertrustbundle)
+* [`podCertificate`](#podcertificate)
 
 All sources are required to be in the same namespace as the Pod. For more details,
 see the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document.
@@ -96,6 +97,60 @@ By default, the kubelet will prevent the pod from starting if the named ClusterT
 
 {{% code_sample file="pods/storage/projected-clustertrustbundle.yaml" %}}
 
+## podCertificate projected volumes {#podcertificate}
+
+{{< feature-state feature_gate_name="PodCertificateRequest" >}}
+
+{{< note >}}
+In Kubernetes {{< skew currentVersion >}}, you must enable support for Pod
+Certificates using the `PodCertificateRequest` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
+`--runtime-config=certificates.k8s.io/v1alpha1/podcertificaterequests=true`
+kube-apiserver flag.
+{{< /note >}}
+
+The `podCertificate` projected volumes source securely provisions a private key
+and X.509 certificate chain for pod to use as client or server credentials.
+Kubelet will then handle refreshing the private key and certificate chain when
+they get close to expiration.  The application just has to make sure that it
+reloads the file promptly when it changes, with a mechanism like `inotify` or
+polling.
+
+Each `podCertificate` projection supports the following configuration fields:
+* `signerName`: The
+  [signer](/docs/reference/access-authn-authz/certificate-signing-requests#signers)
+  you want to issue the certificate.  Note that signers may have their own
+  access requirements, and may refuse to issue certificates to your pod.
+* `keyType`: The type of private key that should be generated.  Valid values are
+  `ED25519`, `ECDSAP256`, `ECDSAP384`, `ECDSAP521`, `RSA3072`, and `RSA4096`.
+* `maxExpirationSeconds`: The maximum lifetime you will accept for the
+  certificate issued to the pod.  If not set, will be defaulted to `86400` (24
+  hours).  Must be at least `3600` (1 hour), and at most `7862400` (91 days).
+  The signer is allowed to issue a certificate with a lifetime shorter than what
+  you've specified.
+* `credentialBundlePath`: Relative path within the projection where the
+  credential bundle should be written.  The credential bundle is a PEM-formatted
+  file, where the first block is a "PRIVATE KEY" block that contains a
+  PKCS#8-serialized private key, and the remaining blocks are "CERTIFICATE"
+  blocks that comprise the certificate chain (leaf certificate and any
+  intermediates).
+* `keyPath` and `certificateChainPath`: Separate paths where Kubelet should
+  write *just* the private key or certificate chain.
+
+{{< note >}}
+
+Most applications should prefer using `credentialBundlePath` unless they need
+the key and certificates in separate files for compatibility reasons. Kubelet
+uses an atomic writing strategy based on symlinks to make sure that when you
+open the files it projects, you read either the old content or the new content.
+However, if you read the key and certificate chain from separate files, Kubelet
+may rotate the credentials after your first read and before your second read,
+resulting in your application loading a mismatched key and certificate.
+
+{{< /note >}}
+
+{{% code_sample file="pods/storage/projected-podcertificate.yaml" %}}
+
 ## SecurityContext interactions
 
 The [proposal](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the correct owner permissions set.
diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
index 58bcae9b840f8..da2e80845bc86 100644
--- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
@@ -4,500 +4,26 @@ reviewers:
 - mikedanese
 - munnerz
 - enj
-title: Certificates and Certificate Signing Requests
-api_metadata:
-- apiVersion: "certificates.k8s.io/v1"
-  kind: "CertificateSigningRequest"
-  override_link_text: "CSR v1"
-- apiVersion: "certificates.k8s.io/v1alpha1"
-  kind: "ClusterTrustBundle"  
+title: Authenticating to the Kubernetes API with Client Certificates  
 content_type: concept
 weight: 60
 ---
 
 <!-- overview -->
 
-Kubernetes certificate and trust bundle APIs enable automation of
-[X.509](https://www.itu.int/rec/T-REC-X.509) credential provisioning by providing
-a programmatic interface for clients of the Kubernetes API to request and obtain
-X.509 {{< glossary_tooltip term_id="certificate" text="certificates" >}} from a Certificate Authority (CA).
+The Kubernetes API supports optional client certificate authentication.  To make use of it, you must:
+* Ensure that `kube-apiserver` has client certificate authentication enabled,
+* Generate a private key and request a client certificate using the Kubernetes API.
+* Configure your client to use the private key and certificate for authentication.
 
-There is also experimental (alpha) support for distributing [trust bundles](#cluster-trust-bundles).
+Before you begin, [read about the mechanisms for requesting certificates](/docs/concepts/security/certificates).
 
 <!-- body -->
 
-## Certificate signing requests
 
-{{< feature-state for_k8s_version="v1.19" state="stable" >}}
+## Configuring client certificate authentication on kube-apiserver
 
+TODO: List flags
 
-A [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
-(CSR) resource is used to request that a certificate be signed
-by a denoted signer, after which the request may be approved or denied before
-finally being signed.
 
-
-### Request signing process
-
-The CertificateSigningRequest resource type allows a client to ask for an X.509 certificate
-be issued, based on a signing request.
-The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in
-the `spec.request` field. The CertificateSigningRequest denotes the signer (the
-recipient that the request is being made to) using the `spec.signerName` field.
-Note that `spec.signerName` is a required key after API version `certificates.k8s.io/v1`.
-In Kubernetes v1.22 and later, clients may optionally set the `spec.expirationSeconds`
-field to request a particular lifetime for the issued certificate. The minimum valid
-value for this field is `600`, i.e. ten minutes.
-
-Once created, a CertificateSigningRequest must be approved before it can be signed.
-Depending on the signer selected, a CertificateSigningRequest may be automatically approved
-by a {{< glossary_tooltip text="controller" term_id="controller" >}}.
-Otherwise, a CertificateSigningRequest must be manually approved either via the REST API (or client-go)
-or by running `kubectl certificate approve`. Likewise, a CertificateSigningRequest may also be denied,
-which tells the configured signer that it must not sign the request.
-
-For certificates that have been approved, the next step is signing. The relevant signing controller
-first validates that the signing conditions are met and then creates a certificate.
-The signing controller then updates the CertificateSigningRequest, storing the new certificate into
-the `status.certificate` field of the existing CertificateSigningRequest object. The
-`status.certificate` field is either empty or contains a X.509 certificate, encoded in PEM format.
-The CertificateSigningRequest `status.certificate` field is empty until the signer does this.
-
-Once the `status.certificate` field has been populated, the request has been completed and clients can now
-fetch the signed certificate PEM data from the CertificateSigningRequest resource.
-The signers can instead deny certificate signing if the approval conditions are not met.
-
-In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection
-controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed
-state for some duration:
-
-* Approved requests: automatically deleted after 1 hour
-* Denied requests: automatically deleted after 1 hour
-* Failed requests: automatically deleted after 1 hour
-* Pending requests: automatically deleted after 24 hours
-* All requests: automatically deleted after the issued certificate has expired
-
-### Certificate signing authorization {#authorization}
-
-To allow creating a CertificateSigningRequest and retrieving any CertificateSigningRequest:
-
-* Verbs: `create`, `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
-
-For example:
-
-{{% code_sample file="access/certificate-signing-request/clusterrole-create.yaml" %}}
-
-To allow approving a CertificateSigningRequest:
-
-* Verbs: `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
-* Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/approval`
-* Verbs: `approve`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
-
-For example:
-
-{{% code_sample file="access/certificate-signing-request/clusterrole-approve.yaml" %}}
-
-To allow signing a CertificateSigningRequest:
-
-* Verbs: `get`, `list`, `watch`, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
-* Verbs: `update`, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status`
-* Verbs: `sign`, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
-
-{{% code_sample file="access/certificate-signing-request/clusterrole-sign.yaml" %}}
-
-
-## Signers
-
-Signers abstractly represent the entity or entities that might sign, or have
-signed, a security certificate.
-
-Any signer that is made available for outside a particular cluster should provide information
-about how the signer works, so that consumers can understand what that means for CertifcateSigningRequests
-and (if enabled) [ClusterTrustBundles](#cluster-trust-bundles).
-This includes:
-
-1. **Trust distribution**: how trust anchors (CA certificates or certificate bundles) are distributed.
-1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
-1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames,
-   Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
-1. **Permitted key usages / extended key usages**: any restrictions on and behavior
-   when usages different than the signer-determined usages are specified in the CSR.
-1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR `spec.expirationSeconds` field, etc
-   and the behavior when the signer-determined expiration is different from the CSR `spec.expirationSeconds` field.
-1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
-
-Commonly, the `status.certificate` field of a CertificateSigningRequest contains a
-single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued.
-Some signers store multiple certificates into the `status.certificate` field. In
-that case, the documentation for the signer should specify the meaning of
-additional certificates; for example, this might be the certificate plus
-intermediates to be presented during TLS handshakes.
-
-If you want to make the _trust anchor_ (root certificate) available, this should be done
-separately from a CertificateSigningRequest and its `status.certificate` field. For example,
-you could use a ClusterTrustBundle.
-
-The PKCS#10 signing request format does not have a standard mechanism to specify a
-certificate expiration or lifetime. The expiration or lifetime therefore has to be set
-through the `spec.expirationSeconds` field of the CSR object. The built-in signers
-use the `ClusterSigningDuration` configuration option, which defaults to 1 year,
-(the `--cluster-signing-duration` command-line flag of the kube-controller-manager)
-as the default when no `spec.expirationSeconds` is specified. When `spec.expirationSeconds`
-is specified, the minimum of `spec.expirationSeconds` and `ClusterSigningDuration` is
-used.
-
-{{< note >}}
-The `spec.expirationSeconds` field was added in Kubernetes v1.22. Earlier versions of Kubernetes do not honor this field.
-Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
-{{< /note >}}
-
-### Kubernetes signers
-
-Kubernetes provides built-in signers that each have a well-known `signerName`:
-
-1. `kubernetes.io/kube-apiserver-client`: signs certificates that will be honored as client certificates by the API server.
-   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle is not distributed by any other means.
-   1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign.
-      Certain subjects like cluster-admin level users or groups vary between distributions and installations,
-      but deserve additional scrutiny before approval and signing.
-      The `CertificateSubjectRestriction` admission plugin is enabled by default to restrict `system:masters`,
-      but it is often not the only cluster-admin subject in a cluster.
-   1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
-   1. Permitted key usages - must include `["client auth"]`. Must not include key usages beyond `["digital signature", "key encipherment", "client auth"]`.
-   1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
-      of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
-   1. CA bit allowed/disallowed - not allowed.
-
-1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client certificates by the
-   API server.
-   May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle
-      is not distributed by any other means.
-   1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
-   1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions.
-   1. Permitted key usages - `["key encipherment", "digital signature", "client auth"]` or `["digital signature", "client auth"]`.
-   1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
-      of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
-   1. CA bit allowed/disallowed - not allowed.
-
-1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
-   by the API server, but has no other guarantees.
-   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: signed certificates must be honored by the API server as valid to terminate connections to a kubelet.
-      The CA bundle is not distributed by any other means.
-   1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name is "`system:node:${NODE_NAME}`".
-   1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and
-      URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
-   1. Permitted key usages - `["key encipherment", "digital signature", "server auth"]` or `["digital signature", "server auth"]`.
-   1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
-      of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
-   1. CA bit allowed/disallowed - not allowed.
-
-1. `kubernetes.io/legacy-unknown`: has no guarantees for trust at all. Some third-party distributions of Kubernetes
-   may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
-   does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
-   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster.
-   1. Permitted subjects - any
-   1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
-   1. Permitted key usages - any
-   1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
-      of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
-   1. CA bit allowed/disallowed - not allowed.
-
-The kube-controller-manager implements [control plane signing](#signer-control-plane) for each of the built in
-signers. Failures for all of these are only reported in kube-controller-manager logs.
-
-{{< note >}}
-The `spec.expirationSeconds` field was added in Kubernetes v1.22. Earlier versions of Kubernetes do not honor this field.
-Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
-{{< /note >}}
-
-Distribution of trust happens out of band for these signers. Any trust outside of those described above are strictly
-coincidental. For instance, some distributions may honor `kubernetes.io/legacy-unknown` as client certificates for the
-kube-apiserver, but this is not a standard.
-None of these usages are related to ServiceAccount token secrets `.data[ca.crt]` in any way. That CA bundle is only
-guaranteed to verify a connection to the API server using the default service (`kubernetes.default.svc`).
-
-### Custom signers
-
-You can also introduce your own custom signer, which should have a similar prefixed name but using your
-own domain name. For example, if you represent an open source project that uses the domain `open-fictional.example`
-then you might use `issuer.open-fictional.example/service-mesh` as a signer name.
-
-A custom signer uses the Kubernetes API to issue a certificate. See [API-based signers](#signer-api).
-
-## Signing
-
-### Control plane signer {#signer-control-plane}
-
-The Kubernetes control plane implements each of the
-[Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers),
-as part of the kube-controller-manager.
-
-{{< note >}}
-Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that
-were marked as approved.
-{{< /note >}}
-
-{{< note >}}
-The `spec.expirationSeconds` field was added in Kubernetes v1.22.
-Earlier versions of Kubernetes do not honor this field.
-Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
-{{< /note >}}
-
-### API-based signers {#signer-api}
-
-Users of the REST API can sign CSRs by submitting an UPDATE request to the `status`
-subresource of the CSR to be signed.
-
-As part of this request, the `status.certificate` field should be set to contain the
-signed certificate. This field contains one or more PEM-encoded certificates.
-
-All PEM blocks must have the "CERTIFICATE" label, contain no headers,
-and the encoded data must be a BER-encoded ASN.1 Certificate structure
-as described in [section 4 of RFC5280](https://tools.ietf.org/html/rfc5280#section-4.1).
-
-Example certificate content:
-
-```
------BEGIN CERTIFICATE-----
-MIIDgjCCAmqgAwIBAgIUC1N1EJ4Qnsd322BhDPRwmg3b/oAwDQYJKoZIhvcNAQEL
-BQAwXDELMAkGA1UEBhMCeHgxCjAIBgNVBAgMAXgxCjAIBgNVBAcMAXgxCjAIBgNV
-BAoMAXgxCjAIBgNVBAsMAXgxCzAJBgNVBAMMAmNhMRAwDgYJKoZIhvcNAQkBFgF4
-MB4XDTIwMDcwNjIyMDcwMFoXDTI1MDcwNTIyMDcwMFowNzEVMBMGA1UEChMMc3lz
-dGVtOm5vZGVzMR4wHAYDVQQDExVzeXN0ZW06bm9kZToxMjcuMC4wLjEwggEiMA0G
-CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDne5X2eQ1JcLZkKvhzCR4Hxl9+ZmU3
-+e1zfOywLdoQxrPi+o4hVsUH3q0y52BMa7u1yehHDRSaq9u62cmi5ekgXhXHzGmm
-kmW5n0itRECv3SFsSm2DSghRKf0mm6iTYHWDHzUXKdm9lPPWoSOxoR5oqOsm3JEh
-Q7Et13wrvTJqBMJo1GTwQuF+HYOku0NF/DLqbZIcpI08yQKyrBgYz2uO51/oNp8a
-sTCsV4OUfyHhx2BBLUo4g4SptHFySTBwlpRWBnSjZPOhmN74JcpTLB4J5f4iEeA7
-2QytZfADckG4wVkhH3C2EJUmRtFIBVirwDn39GXkSGlnvnMgF3uLZ6zNAgMBAAGj
-YTBfMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMB
-Af8EAjAAMB0GA1UdDgQWBBTREl2hW54lkQBDeVCcd2f2VSlB1DALBgNVHREEBDAC
-ggAwDQYJKoZIhvcNAQELBQADggEBABpZjuIKTq8pCaX8dMEGPWtAykgLsTcD2jYr
-L0/TCrqmuaaliUa42jQTt2OVsVP/L8ofFunj/KjpQU0bvKJPLMRKtmxbhXuQCQi1
-qCRkp8o93mHvEz3mTUN+D1cfQ2fpsBENLnpS0F4G/JyY2Vrh19/X8+mImMEK5eOy
-o0BMby7byUj98WmcUvNCiXbC6F45QTmkwEhMqWns0JZQY+/XeDhEcg+lJvz9Eyo2
-aGgPsye1o3DpyXnyfJWAWMhOz7cikS5X2adesbgI86PhEHBXPIJ1v13ZdfCExmdd
-M1fLPhLyR54fGaY+7/X8P9AZzPefAkwizeXwe9ii6/a08vWoiE4=
------END CERTIFICATE-----
-```
-
-Non-PEM content may appear before or after the CERTIFICATE PEM blocks and is unvalidated,
-to allow for explanatory text as described in [section 5.2 of RFC7468](https://www.rfc-editor.org/rfc/rfc7468#section-5.2).
-
-When encoded in JSON or YAML, this field is base-64 encoded.
-A CertificateSigningRequest containing the example certificate above would look like this:
-
-```yaml
-apiVersion: certificates.k8s.io/v1
-kind: CertificateSigningRequest
-...
-status:
-  certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JS..."
-```
-
-## Approval or rejection  {#approval-rejection}
-
-Before a [signer](#signers) issues a certificate based on a CertificateSigningRequest,
-the signer typically checks that the issuance for that CSR has been _approved_.
-
-### Control plane automated approval {#approval-rejection-control-plane}
-
-The kube-controller-manager ships with a built-in approver for certificates with
-a signerName of `kubernetes.io/kube-apiserver-client-kubelet` that delegates various
-permissions on CSRs for node credentials to authorization.
-The kube-controller-manager POSTs SubjectAccessReview resources to the API server
-in order to check authorization for certificate approval.
-
-### Approval or rejection using `kubectl` {#approval-rejection-kubectl}
-
-A Kubernetes administrator (with appropriate permissions) can manually approve
-(or deny) CertificateSigningRequests by using the `kubectl certificate
-approve` and `kubectl certificate deny` commands.
-
-To approve a CSR with kubectl:
-
-```shell
-kubectl certificate approve <certificate-signing-request-name>
-```
-
-Likewise, to deny a CSR:
-
-```shell
-kubectl certificate deny <certificate-signing-request-name>
-```
-
-### Approval or rejection using the Kubernetes API {#approval-rejection-api-client}
-
-Users of the REST API can approve CSRs by submitting an UPDATE request to the `approval`
-subresource of the CSR to be approved. For example, you could write an
-{{< glossary_tooltip term_id="operator-pattern" text="operator" >}} that watches for a particular
-kind of CSR and then sends an UPDATE to approve them.
-
-When you make an approval or rejection request, set either the `Approved` or `Denied`
-status condition based on the state you determine:
-
-For `Approved` CSRs:
-
-```yaml
-apiVersion: certificates.k8s.io/v1
-kind: CertificateSigningRequest
-...
-status:
-  conditions:
-  - lastUpdateTime: "2020-02-08T11:37:35Z"
-    lastTransitionTime: "2020-02-08T11:37:35Z"
-    message: Approved by my custom approver controller
-    reason: ApprovedByMyPolicy # You can set this to any string
-    type: Approved
-```
-
-For `Denied` CSRs:
-
-```yaml
-apiVersion: certificates.k8s.io/v1
-kind: CertificateSigningRequest
-...
-status:
-  conditions:
-  - lastUpdateTime: "2020-02-08T11:37:35Z"
-    lastTransitionTime: "2020-02-08T11:37:35Z"
-    message: Denied by my custom approver controller
-    reason: DeniedByMyPolicy # You can set this to any string
-    type: Denied
-```
-
-It's usual to set `status.conditions.reason` to a machine-friendly reason
-code using TitleCase; this is a convention but you can set it to anything
-you like. If you want to add a note for human consumption, use the
-`status.conditions.message` field.
-
-
-## Cluster trust bundles {#cluster-trust-bundles}
-
-{{< feature-state feature_gate_name="ClusterTrustBundle" >}}
-
-{{< note >}}
-In Kubernetes {{< skew currentVersion >}}, you must enable the `ClusterTrustBundle`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-_and_ the `certificates.k8s.io/v1alpha1`
-{{< glossary_tooltip text="API group" term_id="api-group" >}} in order to use
-this API.
-{{< /note >}}
-
-A ClusterTrustBundles is a cluster-scoped object for distributing X.509 trust
-anchors (root certificates) to workloads within the cluster. They're designed
-to work well with the [signer](#signers) concept from CertificateSigningRequests.
-
-ClusterTrustBundles can be used in two modes:
-[signer-linked](#ctb-signer-linked) and [signer-unlinked](#ctb-signer-unlinked).
-
-### Common properties and validation {#ctb-common}
-
-All ClusterTrustBundle objects have strong validation on the contents of their
-`trustBundle` field. That field must contain one or more X.509 certificates,
-DER-serialized, each wrapped in a PEM `CERTIFICATE` block. The certificates
-must parse as valid X.509 certificates.
-
-Esoteric PEM features like inter-block data and intra-block headers are either
-rejected during object validation, or can be ignored by consumers of the object.
-Additionally, consumers are allowed to reorder the certificates in
-the bundle with their own arbitrary but stable ordering.
-
-ClusterTrustBundle objects should be considered world-readable within the
-cluster. If your cluster uses [RBAC](/docs/reference/access-authn-authz/rbac/)
-authorization, all ServiceAccounts have a default grant that allows them to
-**get**, **list**, and **watch** all ClusterTrustBundle objects.
-If you use your own authorization mechanism and you have enabled
-ClusterTrustBundles in your cluster, you should set up an equivalent rule to
-make these objects public within the cluster, so that they work as intended.
-
-If you do not have permission to list cluster trust bundles by default in your
-cluster, you can impersonate a service account you have access to in order to
-see available ClusterTrustBundles:
-
-```bash
-kubectl get clustertrustbundles --as='system:serviceaccount:mynamespace:default'
-```
-
-### Signer-linked ClusterTrustBundles {#ctb-signer-linked}
-
-Signer-linked ClusterTrustBundles are associated with a _signer name_, like this:
-
-```yaml
-apiVersion: certificates.k8s.io/v1alpha1
-kind: ClusterTrustBundle
-metadata:
-  name: example.com:mysigner:foo
-spec:
-  signerName: example.com/mysigner
-  trustBundle: "<... PEM data ...>"
-```
-
-These ClusterTrustBundles are intended to be maintained by a signer-specific
-controller in the cluster, so they have several security features:
-
-* To create or update a signer-linked ClusterTrustBundle, you must be permitted
-  to **attest** on the signer (custom authorization verb `attest`,
-  API group `certificates.k8s.io`; resource path `signers`). You can configure
-  authorization for the specific resource name
-  `<signerNameDomain>/<signerNamePath>` or match a pattern such as
-  `<signerNameDomain>/*`.
-* Signer-linked ClusterTrustBundles **must** be named with a prefix derived from
-  their `spec.signerName` field. Slashes (`/`) are replaced with colons (`:`),
-  and a final colon is appended. This is followed by an arbitrary name. For
-  example, the signer `example.com/mysigner` can be linked to a
-  ClusterTrustBundle `example.com:mysigner:<arbitrary-name>`.
-
-Signer-linked ClusterTrustBundles will typically be consumed in workloads
-by a combination of a
-[field selector](/docs/concepts/overview/working-with-objects/field-selectors/) on the signer name, and a separate
-[label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
-
-### Signer-unlinked ClusterTrustBundles {#ctb-signer-unlinked}
-
-Signer-unlinked ClusterTrustBundles have an empty `spec.signerName` field, like this:
-
-```yaml
-apiVersion: certificates.k8s.io/v1alpha1
-kind: ClusterTrustBundle
-metadata:
-  name: foo
-spec:
-  # no signerName specified, so the field is blank
-  trustBundle: "<... PEM data ...>"
-```
-
-They are primarily intended for cluster configuration use cases.
-Each signer-unlinked ClusterTrustBundle is an independent object, in contrast to the
-customary grouping behavior of signer-linked ClusterTrustBundles.
-
-Signer-unlinked ClusterTrustBundles have no `attest` verb requirement.
-Instead, you control access to them directly using the usual mechanisms,
-such as role-based access control.
-
-To distinguish them from signer-linked ClusterTrustBundles, the names of
-signer-unlinked ClusterTrustBundles **must not** contain a colon (`:`).
-
-### Accessing ClusterTrustBundles from pods {#ctb-projection}
-
-{{< feature-state feature_gate_name="ClusterTrustBundleProjection" >}}
-
-The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.
-See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
-
-## {{% heading "whatsnext" %}}
-
-* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
-* Read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
-* View the source code for the kube-controller-manager built in
-  [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
-* View the source code for the kube-controller-manager built in
-  [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
-* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
-* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
-* Read about the ClusterTrustBundle API:
-  * {{< page-api-reference kind="ClusterTrustBundle" >}}
+## Requesting a client certificate.
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/PodCertificateRequest.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodCertificateRequest.md
new file mode 100644
index 0000000000000..74b7a83473797
--- /dev/null
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/PodCertificateRequest.md
@@ -0,0 +1,15 @@
+---
+title: PodCertificateRequest
+content_type: feature_gate
+_build:
+  list: never
+  render: false
+
+stages:
+  - stage: alpha
+    defaultValue: false
+    fromVersion: "1.34"
+    toVersion: "1.37"
+---
+Enable PodCertificateRequest objects and podCertificate projected volume
+sources.
diff --git a/content/en/docs/tasks/extend-kubernetes/custom-signer.md b/content/en/docs/tasks/extend-kubernetes/custom-signer.md
new file mode 100644
index 0000000000000..80efff66f87c5
--- /dev/null
+++ b/content/en/docs/tasks/extend-kubernetes/custom-signer.md
@@ -0,0 +1,157 @@
+---
+title: Develop a Custom Signer
+content_type: task
+weight: 40
+---
+
+## Third-party signers {#third-party-signers}
+
+You can also introduce your own custom signer, which should have a similar
+prefixed name but using your own domain name. For example, if you represent an
+open source project that uses the domain `open-fictional.example` then you might
+use `issuer.open-fictional.example/service-mesh` as a signer name.
+
+To implement your custom signer, you need to provide a set of controllers that
+use the Kubernetes API to interact with CertificateSigningRequests,
+PodCertificateRequests, and ClusterTrustBundles that are linked to your signer's
+name.
+
+### Useful ClusterRoles {#authorization}
+
+#### CertificateSigningRequests {#useful-cluster-roles-csr}
+
+CertificateSigningRequests have three roles &mdash; requesters, approvers, and
+signers.  Depending on the signer's logic around approvals, the approver and
+signer role may be shared by the same controller.
+
+Requesters need to be able to create and read CertificateSigningRequests.
+Allowing broad read access to CSRs is not a security issue, because the CSRs
+only contain public (not private) keys.
+* Verbs: **create**, **get**, **list**, **watch**, group: `certificates.k8s.io`,
+  resource: `certificatesigningrequests`
+
+If your cluster uses RBAC, here's an example ClusterRole for a CSR requester:
+
+{{% code_sample file="access/certificate-signing-request/clusterrole-create.yaml" %}}
+
+Approvers need to be able to watch CSRs, and approve or deny CSRs addressed to
+their signer name:
+
+* Verbs: **get**, **list**, **watch**, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
+* Verbs: **update**, group: `certificates.k8s.io`, resource: `certificatesigningrequests/approval`
+* Verbs: **approve**, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+If your cluster uses RBAC, here's an example ClusterRole for a CSR approver:
+
+{{% code_sample file="access/certificate-signing-request/clusterrole-approve.yaml" %}}
+
+Issuers need to be able to watch CSRs, and issue or fail CSRs addressed to their
+signer name:
+
+* Verbs: **get**, **list**, **watch**, group: `certificates.k8s.io`, resource: `certificatesigningrequests`
+* Verbs: **update**, group: `certificates.k8s.io`, resource: `certificatesigningrequests/status`
+* Verbs: **sign**, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+If your cluster uses RBAC, here's an example ClusterRole for a CSR issuer:
+
+{{% code_sample file="access/certificate-signing-request/clusterrole-sign.yaml" %}}
+
+#### PodCertificateRequests {#useful-cluster-roles-pcr}
+
+For PodCertificateRequests, the requester role is almost always filled by
+`kubelet`, which automatically has the necessary permissions to create and read
+PCRs.  There is no approver role.
+
+Issuers need to be able to watch CSRs, and issue or fail CSRs addressed to their
+signer name:
+
+* Verbs: **get**, **list**, **watch**, group: `certificates.k8s.io`, resource: `podcertificaterequests`
+* Verbs: **update**, group: `certificates.k8s.io`, resource: `podcertificaterequests/status`
+* Verbs: **sign**, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+If your cluster uses RBAC, here's an example ClusterRole for a PCR issuer:
+
+{{% code_sample file="access/pod-certificate-request/clusterrole-sign.yaml" %}}
+
+#### ClusterTrustBundles {#useful-cluster-roles-ctb}
+
+ClusterTrustBundles have two broad roles: consumers and attesters.
+
+Consumers need to be able to read ClusterTrustBundles.  In most scenarios, the
+consumer will be `kubelet` (automatic permission via the node authorizer, if
+enabled) or a service account (automatic permission via an RBAC bootstrap
+ClusterRole, if enabled).
+* Verbs: **get**, **list**, **watch**, group `certificates.k8s.io`, resource: `clustertrustbundles`
+
+Attesters are typically a signer controller, and will need permission to create
+and maintain specific signer-linked ClusterTrustBundles
+* Verbs: **create**, **get**, **list**, **watch**, group: `certificates.k8s.io`, resource: `clustertrustbundles`
+* Verbs: **attest**, group: `certificates.k8s.io`, resource: `signers`, resourceName: `<signerNameDomain>/<signerNamePath>` or `<signerNameDomain>/*`
+
+### Writing a PodCertificateRequest controller {#write-pcr-controller}
+
+Under the hood, `kubelet` runs the state machine depicted in Figure 1 for each
+`podCertificate` projection.  The actions your signer takes on the
+PodCertificateRequests that `kubelet` generates control the state transitions.
+
+{{< mermaid >}} 
+stateDiagram-v2
+
+direction LR
+
+Initial --> Wait
+Wait --> Fresh
+Wait --> Failed
+Wait --> Denied
+Fresh --> WaitRefresh
+WaitRefresh --> Failed
+WaitRefresh --> Denied
+
+{{< /mermaid >}}
+Figure 1.  Kubelet podCertificate lifecycle
+
+1. The projection starts out in `Initial` state.
+2. Kubelet generates a private key and holds it in memory.
+3. Kubelet creates a
+   [PodCertificateRequest](/docs/reference/access-authn-authz/certificate-signing-requests#pod-certificate-requests)
+   addressed to the requested signer.  Kubelet then moves the projection into
+   the `Wait` state.
+4. If the PodCertificateRequest is marked "Denied", move to the `Denied` state.  This is
+   a permanent error state, and the container(s) that mount this projection will
+   fail to start.
+5. If the PodCertificateRequest is marked "Failed", move to the `Failed` state.
+   This is a permanent error state, and the container(s) that mount this
+   projection will fail to start.
+6. If the PodCertificate is marked "Issued", move to the `Fresh` state.  Kubelet
+   holds the private key and certificate chain in memory, and will periodically
+   write them to the filesystem at the requested location.  The container that
+   mounts this projection will start up and run (assuming nothing else blocks
+   its execution).
+7. The signer indicated an appropriate time to begin refreshing the certificate
+   when it issued the PodCertificateRequest.  Once that time has passed Kubelet
+   will generate a new private key, create a new PodCertificateRequest, and move
+   the projection into `WaitRefresh` state.
+8. If the PodCertificateRequest is marked "Denied", move to the `Denied` state.
+   This is a permanent error state, and the container(s) will begin to get
+   Kubelet volume remount errors.
+9. If the PodCertificateRequest is marked "Failed", move to the `Failed` state.
+   This is a permanent error state, and the container(s) will begin to get
+   Kubelet volume remount errors.
+10. If the PodCertificate is marked "Issued", move back to the `Fresh` state. The
+  container(s) will continue to run, with the new private key and certificate
+  chain written to the filesystem.
+
+## {{% heading "whatsnext" %}}
+
+* Read detailed API references:
+  * CertificateSigningRequest: {{< api-reference page="authentication-resources/certificate-signing-request-v1" >}}
+  * PodCertificateRequest: {{< api-reference page="authentication-resources/pod-certificate-request-v1alpha1" >}}
+  * ClusterTrustBundle: {{< api-reference page="authentication-resources/cluster-trust-bundle-v1beta1" >}}
+* Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
+* Read [Issue a Certificate for a Kubernetes API Client Using A CertificateSigningRequest](/docs/tasks/tls/certificate-issue-client-csr/)
+* View the source code for the `kube-controller-manager` built in
+  [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
+* View the source code for the `kube-controller-manager` built in
+  [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
+* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
+* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
diff --git a/content/en/examples/access/pod-certificate-request/clusterrole-sign.yaml b/content/en/examples/access/pod-certificate-request/clusterrole-sign.yaml
new file mode 100644
index 0000000000000..cb6956be4ef69
--- /dev/null
+++ b/content/en/examples/access/pod-certificate-request/clusterrole-sign.yaml
@@ -0,0 +1,27 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: pcr-signer
+rules:
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - podcertificaterequests
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - podcertificaterequests/status
+  verbs:
+  - update
+- apiGroups:
+  - certificates.k8s.io
+  resources:
+  - signers
+  resourceNames:
+  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
+  verbs:
+  - sign
diff --git a/content/en/examples/pods/storage/projected-podcertificate.yaml b/content/en/examples/pods/storage/projected-podcertificate.yaml
new file mode 100644
index 0000000000000..21d70788bf596
--- /dev/null
+++ b/content/en/examples/pods/storage/projected-podcertificate.yaml
@@ -0,0 +1,26 @@
+# Sample Pod spec that uses a podCertificate projection to request an ED25519
+# private key, a certificate from the `coolcert.example.com/foo` signer, and
+# write the results to `/var/run/my-x509-credentials/credentialbundle.pem`.
+apiVersion: v1
+kind: Pod
+metadata:
+  namespace: default
+  name: podcertificate-pod
+spec:
+  serviceAccountName: default
+  containers:
+  - image: debian
+    name: main
+    command: ["sleep", "infinity"]
+    volumeMounts:
+    - name: my-x509-credentials
+      mountPath: /var/run/my-x509-credentials
+  volumes:
+  - name: my-x509-credentials
+    projected:
+      defaultMode: 420
+      sources:
+      - podCertificate:
+          keyType: ED25519
+          signerName: coolcert.example.com/foo
+          credentialBundlePath: credentialbundle.pem