Private Network Clusters

Private Network Clusters build on the security available in Standard Network Clusters by allowing clusters to be created without publicly routable IPs allocated to cluster nodes.  All inter-node communication occurs within a private network.

This configuration is a security best practice and a security requirement for many organizations as it reduces the potential attack vectors to compromise servers running back end services.

Features of Private network clusters include: 

• Each client cluster is created in its own network environment (e.g. VPC in AWS) with no shared instances
• Whitelist monitoring of open ports and running processes (basic intrusion detection)
• Communication from client nodes to our central infrastructure is via connections initiated by the nodes
• Central management infrastructure has no access to data in customer clusters
• (For a more complete list, please refer to Security Features Overview)

In a Private Network Cluster, all inter-node communication within data-layer clusters (Cassandra, Kafka etc) occurs within a private network.  

Instaclustr will automatically provision a gateway server with a public IP to enable cluster management only accessible to Instaclustr technical operation team. SSH is the only service this gateway server exposes and it is firewalled to only be accessible only from Instaclustr’s management system.

Private Network cluster is available as an option on newly provisioned clusters, only for production node sizes on AWS and GCP. If you are running on Azure AZ, private network clusters are available if the cluster is running in your own cloud provider account. Existing clusters can be migrated to a Private Network Cluster, customers interested in migrating to a Private Network should contact Instaclustr Support.

The extra security of Private Network Clusters does come with some administrative overhead so customers should carefully evaluate if it is appropriate for their situation.  A few important considerations include:

• Any connection to a cluster running in a Private Network Cluster, such as from a client application, requires the client application to be in a VPC which has network connectivity to the Private Network Cluster through VPC peering on AWS, GCP or VNet Peering for Azure AZ, or via a VPN, etc.
• Multi-data-centre clusters, even within a region, require manual setup (automated VPC peering is planned in a coming release). Cross-region clusters require either manual configuration of inter-region VPC peering or a customer-supplied and managed inter-region communication solution such as a VPN,  Direct Connect, etc and dedicated connections.
• In a Private Network Cluster, add-ons such as OpenSearch dashboards or Spark Job Server will no longer have a public IP address and will be inaccessible via the public internet.  Customers wishing to use these applications in a private network cluster should implement appropriate network configuration mentioned above to ensure that users can access these applications.

If you have any questions regarding Instaclustr’s Private Network Clusters, then please contact Instaclustr Support.

Table of Contents

Standard Network Cluster

In a Standard Network Cluster, a public IP is allocated to each node to facilitate internode communication and management via SSH.  In contrast, in a Private Network Cluster, only a private IP is allocated to facilitate internode communication and management via SSH.  A separate, hardened instance (the Gateway Instance) is allocated to facilitate remote access for management of nodes via SSH.  The Gateway Instance resides in the same VPC as the Private Network Cluster, and only the Gateway Instance is allocated a public IP.  The Gateway Instance is firewalled to only accept ssh connections from Instaclustr’s management services.

In a Private Network Cluster, outbound access to the internet occurs via a NAT gateway with a public IP.

If the cluster is configured as RIYOA, note that one instance (the Gateway instance) will be configured in addition to the cluster instances themselves.

Clusters spanning multiple Data Centers (Single Region)

Just like a Standard Network Cluster, Private Network Clusters can span multiple Data Centres in a single region.  To configure a cluster this way requires a VPC peering relationship to be established.  If you wish to configure a cluster this way, please contact Instaclustr Support.

Clusters spanning multiple Data Centers (Multiple Regions)

Private Network Clusters can span multiple Data Centres across regions.  To configure a cluster this way requires that an appropriate mechanism is used to establish a private route between VPC’s.  This is an advanced topic, and solutions may involve technologies such as AWS Direct Connect and VPN routers.  If you wish to configure a cluster this way, please contact Instaclustr Support.

Limitations

In a Standard Network Cluster, all nodes have a public IP address, which may be used to route to services running on nodes which may have browser or application facing interfaces. Examples of such services include:

1. OpenSearch dashboards’ web user interface
2. Spark Job Server’s REST API

In a Private Network Cluster, nodes do not have a public IP address.  Therefore special consideration needs to be given to establishing connectivity between the services and the applications or browsers that use the service.  This may involve VPC peering, opening firewall rules and/or configuring proxies.  These services are secured with a CA certificate which references a DNS Hostname which resolves (via a public DNS entry) to the private ip address of the Node.  This may result in security warnings if the application or browser using the service is unable to connect to a public DNS to resolve the hostname.

Private Network Clusters are available for all clusters running on AWS and GCP. If you are running on Azure AZ, private network clusters are available if the cluster is running in a RIYOA account.