Step 4. Create user-defined security groups for Amazon EC2
Create ELB, master, and worker security groups to fine-tune security settings in your AWS environment. Configure the appropriate inbound and outbound rules for each security group. After you complete these tasks, you can specify the security groups in an advanced configuration.
If you're looking for a quick setup, you can use the default security groups that the Secure Agent creates. For more information, see Use default security groups (alternative). You cannot mix and match default and user-defined security groups. For example, if you create a user-defined ELB security group, you must also create user-defined master and worker security groups.
For detailed instructions about how to create security groups for Amazon EC2, refer to the AWS documentation.
Create the ELB security group
The ELB security group defines the inbound rules between the Kubernetes API server and clients that are external to the advanced cluster. It also defines the outbound rules between the Kubernetes API server and cluster nodes. This security group is attached to the load balancer that the agent provisions for the advanced cluster.
Inbound rules
The inbound rules identify the nodes outside of the advanced cluster that can access the Kubernetes API server using HTTPS.
The inbound rules must allow the following traffic:
•Incoming traffic from the Secure Agent that creates the advanced cluster.
•Incoming traffic from master nodes in the same cluster.
•Incoming traffic from worker nodes in the same cluster.
•Incoming traffic from the Secure Agent using TCP port 31447. The Secure Agent uses this port to run data preview jobs. If you need to change this port number, contact Informatica Global Customer Support.
•For advanced clusters that use a CLAIRE-powered configuration, include traffic from the Secure Agent to the Prometheus server using TCP port 30000.
The following image shows the required inbound rules:
Outbound rules
Use the default outbound rule to allow all outbound traffic.
You can restrict the destination of this rule, but the destination must include HTTPS traffic to all master nodes in the cluster.
Create the master security group
The master security group defines the inbound rules between the master nodes and the worker nodes in the advanced cluster, the ELB security group, and the Secure Agent. It also defines outbound rules to other nodes. This security group is attached to all master nodes in the cluster.
Inbound rules
Inbound rules must allow the following traffic:
•Incoming traffic from worker nodes in the same cluster. For example, worker nodes accessing the API server through the service named "kubernetes," or kube-proxy forwarding the network traffic inside or outside the cluster. You can simplify the inbound rules for worker nodes by configuring the rule for custom TCP and UDP with port range 1024 - 65535, as well as HTTPs with TCP at port 443.
•Incoming traffic from other master nodes in the same cluster.
•Incoming traffic using HTTPS over TCP at port 443 from the ELB security group in the same cluster.
•Incoming traffic using SSH over port 22.
•Incoming traffic using TCP port 31447, which is from the ELB security group in the same cluster. The Secure Agent uses this port to run data preview jobs.
•For advanced clusters that use a CLAIRE-powered configuration, include traffic from the Secure Agent to the Prometheus server using TCP port 30000.
When you create and use a user-defined master security group, the Secure Agent ignores the following default rules for SSH access from outside the cluster:
•The IP address of the Secure Agent, from where the cluster is created, can use the SSH protocol to connect to worker nodes through port 22.
•The ability to configure the source Classless Inter-Domain Routing (CIDR) address using a custom property.
•The configuration of SSH port using a custom property.
•The ability to set a local file path on an agent node for a public key using a custom property.
The following image shows the required inbound rules:
Outbound rules
Use the default outbound rule to allow all outbound traffic.
Outbound traffic from the master node can include the other master nodes; the ELB security group; worker nodes; Secure Agents; other managed services on AWS such Amazon S3, EC2, and IAM; other storage services; and other public services.
Create the worker security group
The worker security group defines the inbound and outbound rules between worker nodes in the advanced cluster and other nodes. This security group is attached to all worker nodes in the cluster.
Inbound rules
Inbound rules must allow the following traffic:
•Incoming traffic from other worker nodes in the cluster. For example, communication between related Pods.
•Incoming traffic from any master node in the cluster. For example, the master node contacts the kubelet on worker nodes to get logs or support port forwarding.
•Incoming traffic from TCP ports 10250, 10257, and 10259.
•Incoming traffic using HTTPS with TCP at port 443 from the ELB security group in the same cluster.
•Incoming SSH access from outside the cluster. This rule is the same as the SSH inbound rule defined for the master security group and is needed only if you want to access the worker node using SSH.
The following image shows the required inbound rules:
Outbound rules
Use the default outbound rule to allow all outbound traffic.
Outbound traffic from worker nodes can include the ELB security group; master nodes; other worker nodes; the Secure Agent; other managed services on AWS such as Amazon S3, EC2, and IAM; other storage services; and other public services. Additionally, the outbound rules must allow advanced jobs to communicate with data sources, such as Redshift and Snowflake databases, and external services, such as REST endpoints that the Secure Agent exposes.
Use default security groups (alternative)
When the Secure Agent creates an advanced cluster, it can generate a default ELB security group, master security group, and worker security group. These default security groups define communication guidelines between Kubernetes clients, the API server, master nodes, worker nodes, and other services.
To allow the Secure Agent to generate the default security groups, the cluster operator policy for the cluster operator role requires the following permissions:
•ec2:DescribeSecurityGroups
•ec2:CreateSecurityGroup
•ec2:DeleteSecurityGroup
•ec2:AuthorizeSecurityGroupEgress
•ec2:AuthorizeSecurityGroupIngress
•ec2:RevokeSecurityGroupEgress
•ec2:RevokeSecurityGroupIngress
For more information about the cluster operator role and the cluster operator policy, see Step 7. Create IAM roles.