RDS Networking

Use the Same VPC: Ideally, both your EKS cluster and RDS database should be in the same VPC. This simplifies network routing and security group settings.

Subnet Considerations: Your RDS database should be placed in a private subnet that is not directly accessible from the internet. Ensure that the VPC has sufficient subnet space to accommodate both EKS and RDS.

Security Groups: Set up security groups for both EKS and RDS. The security group for RDS should allow inbound traffic on the database port (e.g., 3306 for MySQL) from the security group attached to your EKS worker nodes. This ensures that only your EKS cluster can access the RDS instance.

Network Access Control Lists (NACLs): Ensure that your VPC’s network ACLs allow traffic between your EKS pods and the RDS instance.

Routing Tables: Make sure that the routing tables within your VPC allow for communication between the subnets where EKS and RDS are located.

Endpoint Services (Optional): If you want to further enhance security and reduce data transfer costs, consider using VPC Endpoint Services for Amazon RDS. This allows you to keep traffic between your EKS cluster and RDS database within the AWS network.

Database Authentication and Authorization: Ensure that your database's authentication mechanisms (e.g., username and password, IAM authentication) are properly configured to allow connections from your EKS pods.

Testing Connectivity: Once setup, you should test the connectivity from a pod in EKS to the RDS instance to ensure that the network configuration is correct.

---

Ensuring that Kubernetes network policies don't block necessary traffic to and from your PostgreSQL RDS instance involves a few steps. Kubernetes network policies are used to control the flow of traffic between pod-to-pod and pod-to-external services. Here's a general guide on how to ensure your network policies allow the required traffic:

1. Understand Existing Network Policies: First, review any existing network policies in your Kubernetes cluster. You can list all network policies using the following command:

   kubectl get networkpolicies --all-namespaces

1. Identify the Affected Pods: Determine which pods need to access the RDS instance. This could be your application pods that require database connectivity.

2. Create/Modify Network Policy:

   • If there are no existing network policies affecting your pods, you might not need to do anything, as the default behavior in the absence of network policies is to allow all traffic.
   • If there are existing policies that could restrict access, you need to either modify them or create new ones to allow traffic to your RDS instance.

3. Allowing Egress Traffic to RDS:

   • You need to create an egress policy that allows traffic from your pods to the RDS instance. Here's an example policy that allows egress traffic to a specific RDS endpoint on PostgreSQL's default port (5432):

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-rds-egress
      namespace: [your-namespace]
    spec:
      podSelector:
        matchLabels:
          [key]: [value]  # Replace with labels that match your pods
      policyTypes:
      - Egress
      egress:
      - to:
        - ipBlock:
            cidr: [RDS IP Range]  # Replace with the IP range of your RDS instance
        ports:
        - protocol: TCP
          port: 5432
   

• Replace [your-namespace], [key]: [value], and [RDS IP Range] with the appropriate values for your environment.

1. Apply the Network Policy: Once you have your network policy defined, apply it to your cluster:

   kubectl apply -f [your-policy-file].yaml

1. Test the Connectivity: After applying the network policy, test the connectivity to the RDS instance from the pods that require access.

2. Monitor and Adjust as Necessary: Monitor the connectivity and adjust the network policy if needed. Sometimes, fine-tuning is required to get the desired behavior.

Keep in mind that the exact configuration will depend on your specific requirements and setup. Make sure the policy is as restrictive as possible to maintain security, while still allowing the necessary traffic.