AWS eks documentation change
Summary
Fixed punctuation formatting (curly apostrophes to straight apostrophes) in documentation about node affinity and security controls
Security assessment
The changes are purely grammatical/formatting fixes (apostrophe correction) in existing security-related content. No new security information was added, and no specific vulnerability is being addressed. The existing security context about NodeRestriction admission controller protections remains unchanged.
Diff
diff --git a/eks/latest/best-practices/tenant-isolation.md b/eks/latest/best-practices/tenant-isolation.md index 2a8bbb93c..8cefa2bdb 100644 --- a//eks/latest/best-practices/tenant-isolation.md +++ b//eks/latest/best-practices/tenant-isolation.md @@ -163 +163 @@ Kubernetes [node affinity](https://kubernetes.io/docs/concepts/scheduling-evicti -With this node affinity, the label is required during scheduling, but not during execution; if the underlying nodes’ labels change, the pods will not be evicted due solely to that label change. However, future scheduling could be impacted. +With this node affinity, the label is required during scheduling, but not during execution; if the underlying nodes' labels change, the pods will not be evicted due solely to that label change. However, future scheduling could be impacted. @@ -167 +167 @@ With this node affinity, the label is required during scheduling, but not during -The label prefix of `node-restriction.kubernetes.io/` has special meaning in Kubernetes. [NodeRestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) which is enabled for EKS clusters prevents `kubelet` from adding/removing/updating labels with this prefix. Attackers aren’t able to use the `kubelet`’s credentials to update the node object or modify the system setup to pass these labels into `kubelet` as `kubelet` isn’t allowed to modify these labels. If this prefix is used for all pod to node scheduling, it prevents scenarios where an attacker may want to attract a different set of workloads to a node by modifying the node labels. +The label prefix of `node-restriction.kubernetes.io/` has special meaning in Kubernetes. [NodeRestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) which is enabled for EKS clusters prevents `kubelet` from adding/removing/updating labels with this prefix. Attackers aren’t able to use the `kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet` as `kubelet` isn’t allowed to modify these labels. If this prefix is used for all pod to node scheduling, it prevents scenarios where an attacker may want to attract a different set of workloads to a node by modifying the node labels. @@ -259 +259 @@ A second policy, seen below, adds the toleration to the same pod specification, -The above policies are specific to pods; this is due to the paths to the mutated elements in the policies’ `location` elements. Additional policies could be written to handle resources that create pods, like Deployment and Job resources. The listed policies and other examples can been seen in the companion [GitHub project](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa/gatekeeper/node-selector) for this guide. +The above policies are specific to pods; this is due to the paths to the mutated elements in the policies' `location` elements. Additional policies could be written to handle resources that create pods, like Deployment and Job resources. The listed policies and other examples can been seen in the companion [GitHub project](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa/gatekeeper/node-selector) for this guide.