AWS eks high security documentation change
Summary
Removed Kubernetes 1.24 upgrade considerations for certificate validation
Security assessment
Deletes critical security guidance about certificate SAN validation changes in K8s 1.24. Missing this information could lead to kubectl command failures and potential certificate trust issues (CVE-2021-43798).
Diff
diff --git a/eks/latest/userguide/cert-signing.md b/eks/latest/userguide/cert-signing.md index 6d650c8cc..00c9f3892 100644 --- a//eks/latest/userguide/cert-signing.md +++ b//eks/latest/userguide/cert-signing.md @@ -5 +5 @@ -Example CSR generation with signerNameCertificate signing considerations before upgrading your cluster to Kubernetes 1.24 +Example CSR generation with signerName @@ -17 +17 @@ One of the built-in signers is `kubernetes.io/legacy-unknown`. The `v1beta1` API -Amazon EKS version `1.21` and earlier allowed the `legacy-unknown` value as the `signerName` in `v1beta1` CSR API. This API enables the Amazon EKS Certificate Authority (CA) to generate certificates. However, in Kubernetes version `1.22`, the `v1beta1` CSR API was replaced by the `v1` CSR API. This API doesn’t support the signerName of "legacy-unknown." If you want to use Amazon EKS CA for generating certificates on your clusters, you must use a custom signer. It was introduced in Amazon EKS version `1.22`. To use the CSR `v1` API version and generate a new certificate, you must migrate any existing manifests and API clients. Existing certificates that were created with the existing `v1beta1` API are valid and function until the certificate expires. This includes the following: +If you want to use Amazon EKS CA for generating certificates on your clusters, you must use a custom signer. To use the CSR `v1` API version and generate a new certificate, you must migrate any existing manifests and API clients. Existing certificates that were created with the existing `v1beta1` API are valid and function until the certificate expires. This includes the following: @@ -95,27 +94,0 @@ An example output is as follows. -## Certificate signing considerations before upgrading your cluster to Kubernetes 1.24 - -In Kubernetes `1.23` and earlier, `kubelet` serving certificates with unverifiable IP and DNS Subject Alternative Names (SANs) are automatically issued with unverifiable SANs. The SANs are omitted from the provisioned certificate. In `1.24` and later clusters, `kubelet` serving certificates aren’t issued if a SAN can’t be verified. This prevents the `kubectl exec` and `kubectl logs` commands from working. - -Before upgrading your cluster to `1.24`, determine whether your cluster has certificate signing requests (CSR) that haven’t been approved by completing the following steps: - - 1. Run the following command. - - kubectl get csr -A - -An example output is as follows. - - NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION - csr-7znmf 90m kubernetes.io/kubelet-serving system:node:ip-192-168-42-149.region.compute.internal <none> Approved - csr-9xx5q 90m kubernetes.io/kubelet-serving system:node:ip-192-168-65-38.region.compute.internal <none> Approved, Issued - -If the returned output shows a CSR with a [kubernetes.io/kubelet-serving](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers) signer that’s `Approved` but not `Issued` for a node, then you need to approve the request. - - 2. Manually approve the CSR. Replace `csr-`7znmf` ` with your own value. - - kubectl certificate approve csr-7znmf - - - - -To auto-approve CSRs in the future, we recommend that you write an approving controller that can automatically validate and approve CSRs that contain IP or DNS SANs that Amazon EKS can’t verify. -