Private Matters - ROSA and AWS PrivateLink Working Together

AWS PrivateLink provides private connectivity between VPCs, AWS services, and your on-premises networks, without exposing your traffic to the public internet. AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify your network architecture.

In the past, a ROSA cluster required the use of a public load balancer even when the cluster was private. Now we can deploy a private ROSA cluster with PrivateLink enabled, which means the Red Hat SREs can now access the ROSA cluster privately over the AWS network, without going to the internet.

This post looks into what gets created from an AWS resource point of view when a ROSA cluster with PrivateLink is enabled. Please note that PrivateLink is only supported on existing VPCs.

With PrivateLink enabled, the Red Hat SREs managing the ROSA cluster will be accessing the cluster as shown in the diagram below via PrivateLink that gets set up as part of the deployment of the ROSA cluster:

Source

For creating the ROSA cluster with PrivateLink enabled, see  the document put together by the Red Hat Managed Service Black Belt team.

The rosa CLI version used to create the cluster is 1.0.8

Before looking into what gets created as part of the ROSA cluster with PrivateLink enabled, let's look at how AWS PrivateLink works. AWS PrivateLink is a highly available, scalable technology that enables one VPC to privately connect to another VPC’s offered service. You do not need to use an internet gateway, NAT device, public IP address, AWS Direct Connect connection, or AWS Site-to-Site VPN connection to communicate with the service. Traffic between client VPC and the service does not leave the Amazon network and is not exposed to the public internet.

By enabling the use of  AWS PrivateLink, we make ROSA in our VPC available to Red Hat SREs’ accounts and VPCs without going over the internet.

AWS PrivateLink enables private access to the ROSA cluster across VPC boundaries. As part of the deployment, the Red Hat SRE accounts and VPCs create VPC endpoints to access the ROSA cluster.

Endpoint services are created on a network load balancer. In this case, the ROSA cluster uses the Internal network load balancers for the interface endpoints.

Network Load Balancer:

Let's start by looking at the network load balancer that gets created during the ROSA cluster deployment with PrivateLink enabled:.

Next, let's check on the ports that this NLB is listening on. As shown  below, it is  listening to ports TCP 6443 and TCP 22623. The default action is to forward the incoming requests to Target Group private-link-dbxnj-aint, which has the three master nodes (10.0.55.125, 10.0.13.210, and 10.0.37.97) registered as targets.

As indicated  below, the master nodes have reported as healthy to the target group.

Under the Integrated services tab below, note  that a private connection to the NLB has been established as an endpoint service. The Id of the Endpoint Service in this case is vpce-svc-034b3e8a0101fe4e8

Endpoint Service:Let’s click on the Service Id to look into the Endpoint Service that was created. Note that it is  of Type Interface, and that the Status is Available. Also, as this PrivateLink is used by Red Hat SREs, there is no Acceptance required now that  a Private DNS is configured.

In the screen capture  below, you notice  that it shows that NLB private-link-dbxnj-int was used to create this Endpoint:

ee below that the Red Hat SRE user arn:aws:iam::710019948333:user/hive-privatelink-production is the only user in the Allow list of this Endpoint Service:

 Note below that the Endpoint is Available and was created during the time of deploying the ROSA cluster:

Just for completion, let's look at the Tags tab of the Service endpoint:

Conclusion

This new enhancement in ROSA allows SREs to manage and monitor private ROSA clusters in a more secure way without any public connections using the PrivateLink endpoint service. All the SRE traffic will run over the AWS internal network, which removes the need for any public load balancers, public subnets, Internet Gateway, and NAT Gateways. This also allows customers to put firewall rules in place to restrict access while following our published allowlist requirements.