AWS eks documentation change
Summary
Removed detailed instructions about Pod Security Policy checks, CoreDNS manifest updates, and version-specific upgrade requirements. Simplified node version compatibility warnings and deleted deprecated upgrade preparation steps.
Security assessment
The removed content included security-related instructions about Pod Security Policies (PSP) and CoreDNS configuration, but these changes appear to be documentation cleanup rather than addressing an active security vulnerability. The PSP removal aligns with Kubernetes' deprecation of PSP in favor of Pod Security Admission, which is a routine update rather than a direct security fix. No CVE or explicit vulnerability mention exists in the diff.
Diff
diff --git a/eks/latest/userguide/update-cluster.md b/eks/latest/userguide/update-cluster.md index ac9eeade0..05f4d3c3a 100644 --- a//eks/latest/userguide/update-cluster.md +++ b//eks/latest/userguide/update-cluster.md @@ -67 +67 @@ The high-level summary of the Amazon EKS cluster upgrade process is as follows: - 1. Compare the Kubernetes version of your cluster control plane to the Kubernetes version of your nodes. +Compare the Kubernetes version of your cluster control plane to the Kubernetes version of your nodes. @@ -77,25 +76,0 @@ The high-level summary of the Amazon EKS cluster upgrade process is as follows: -Before updating your control plane to a new Kubernetes version, make sure that the Kubernetes minor version of both the managed nodes and Fargate nodes in your cluster are the same as your control plane’s version. For example, if your control plane is running version `1.29` and one of your nodes is running version `1.28`, then you must update your nodes to version `1.29` before updating your control plane to 1.30. We also recommend that you update your self-managed nodes and hybrid nodes to the same version as your control plane before updating the control plane. For more information, see [Update a managed node group for your cluster](./update-managed-node-group.html), [Update self-managed nodes for your cluster](./update-workers.html), and [Upgrade hybrid nodes for your cluster](./hybrid-nodes-upgrade.html). If you have Fargate nodes with a minor version lower than the control plane version, first delete the Pod that’s represented by the node. Then update your control plane. Any remaining Pods will update to the new version after you redeploy them. - - 2. If the Kubernetes version that you originally deployed your cluster with was Kubernetes `1.25` or later, skip this step. - -By default, the Pod security policy admission controller is enabled on Amazon EKS clusters. Before updating your cluster, ensure that the proper Pod security policies are in place. This is to avoid potential security issues. You can check for the default policy with the `kubectl get psp eks.privileged` command. - - kubectl get psp eks.privileged - -If you receive the following error, see [Amazon EKS default Pod security policy](./pod-security-policy.html#default-psp) before proceeding. - - Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found - - 3. If the Kubernetes version that you originally deployed your cluster with was Kubernetes `1.18` or later, skip this step. - -You might need to remove a discontinued term from your CoreDNS manifest. - - 1. Check to see if your CoreDNS manifest has a line that only has the word `upstream`. - - kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream - -If no output is returned, this means that your manifest doesn’t have the line. If this is the case, skip to the next step. If the word `upstream` is returned, remove the line. - - 2. Remove the line near the top of the file that only has the word `upstream` in the configmap file. Don’t change anything else in the file. After the line is removed, save the changes. - - kubectl edit configmap coredns -n kube-system -o yaml @@ -104,0 +80 @@ If no output is returned, this means that your manifest doesn’t have the line. +Before updating your control plane to a new Kubernetes version, make sure that the Kubernetes minor version of both the managed nodes and Fargate nodes in your cluster are the same as your control plane’s version. For example, if your control plane is running version `1.29` and one of your nodes is running version `1.28`, then you must update your nodes to version `1.29` before updating your control plane to 1.30. We also recommend that you update your self-managed nodes and hybrid nodes to the same version as your control plane before updating the control plane. For more information, see [Update a managed node group for your cluster](./update-managed-node-group.html), [Update self-managed nodes for your cluster](./update-workers.html), and [Upgrade hybrid nodes for your cluster](./hybrid-nodes-upgrade.html). If you have Fargate nodes with a minor version lower than the control plane version, first delete the Pod that’s represented by the node. Then update your control plane. Any remaining Pods will update to the new version after you redeploy them. @@ -112,4 +87,0 @@ Review the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference - * If you’re updating to version `1.23` and use Amazon EBS volumes in your cluster, then you must install the Amazon EBS CSI driver in your cluster before updating your cluster to version `1.23` to avoid workload disruptions. For more information, see [Store Kubernetes volumes with Amazon EBS](./ebs-csi.html). - - * Kubernetes `1.24` and later use `containerd` as the default container runtime. If you’re switching to the `containerd` runtime and already have Fluentd configured for Container Insights, then you must migrate Fluentd to Fluent Bit before updating your cluster. The Fluentd parsers are configured to only parse log messages in JSON format. Unlike `dockerd`, the `containerd` container runtime has log messages that aren’t in JSON format. If you don’t migrate to Fluent Bit, some of the configured Fluentd’s parsers will generate a massive amount of errors inside the Fluentd container. For more information on migrating, see [Set up Fluent Bit as a DaemonSet to send logs to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html). - @@ -124,2 +95,0 @@ Review the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference - * If the `kubelet` on your managed and Fargate nodes is on Kubernetes version `1.24` or older, it may only be up to two minor versions older than the `kube-apiserver`. In other words, if the `kubelet` is version `1.24` or older, you can only update your cluster up to two versions ahead. For example, if the `kubelet` is on version `1.21`, you can update your Amazon EKS cluster version from `1.21` to `1.22`, and to `1.23`, but you will not be able to update the cluster to `1.24` while the `kubelet` remains on `1.21`. - @@ -130,2 +99,0 @@ Review the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference - * If you’re updating your cluster to version `1.25` or later and have the AWS Load Balancer Controller deployed in your cluster, then update the controller to version `2.4.7` or later _before_ updating your cluster version to `1.25`. For more information, see the [Kubernetes 1.25](./kubernetes-versions-extended.html#kubernetes-1-25) release notes. -