To create managed node groups with custom configurations — such as instance types, AMI settings, subnet placement, and bootstrap arguments — use the EKS Managed Node Group input variable in your system template. This allows you to define multiple managed node groups with different configurations.
Example 1: Basic Managed Node Group Configuration¶
To assign a custom IAM role to the EKS worker nodes (managed node groups), use the Node IAM Role ARN field. This is useful when you want nodes to assume a specific IAM role with fine-grained permissions:
The Cluster Addons field allows you to configure and manage EKS-managed add-ons such as CoreDNS, kube-proxy, VPC CNI, and CSI drivers directly within the EKS System Template. You can also attach IAM roles to service accounts (using Pod Identity Associations) and provide custom configurations or versions for specific add-ons.
Use the Node Security Group Additional Rules field to define custom ingress or egress rules for the node security group. This is useful when you need to open specific traffic flows between pods, the control plane, or other network components.
{"allow-traffic-from-pods-to-control-plane"={description="allow traffic from pods to control plane"protocol="-1"from_port=0to_port=0type="ingress"source_cluster_security_group=true}}
Key Fields:
type: Direction of the rule (ingress or egress)
protocol: Protocol used (-1 means all protocols)
from_port / to_port: Port range (0-0 for all ports)
source_cluster_security_group: true allows traffic from the cluster’s security group
Note - For Pod Identity Association to work, the specified service account and namespace must already exist in the cluster. This configuration only creates the association, not the service account or namespace itself.