Private Network ClustersMenu
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 internode communication occurs within a private network.
This configuration is security best practice and a security requirement for many organisations as it reduces the potential attack vectors to compromise servers running back end services.
Features of Private network clusters include:
- SOC2 Certification
- Each client cluster is created in its own network environment (eg 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 Cassandra’s internode communication occurs within a private network. Instaclustr will automatically provision a gateway server with a public IP to enable cluster management. Only the gateway server retains a public IP. 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 on AWS. Existing clusters can be migrated to a Private Network Cluster, customers interested in migrating to a Private Network should contact firstname.lastname@example.org.
The extra security of Private Network Clusters does come with some administrative overhead so customers should carefully evaluate if a Private Network Cluster is appropriate for their situation. A few important considerations include:
- Any connection with a Private Network Cluster, such as from a client application using Cassandra, requires the application to be in a VPC which has network connectivity (through VPC peering or via a VPN, for example) to the Private Network Cluster VPC.
- Multi-data center clusters, even within region, require manual setup (automated VPC peering is planned in a coming release). Cross-region clusters require a customer-supplied and managed inter-region communication solution such as a VPN or Direct Connect and dedicated connections.
- In a Private Network Cluster, user-facing applications including Zeppelin, Kibana and 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 make appropriate adjustments to their networking to ensure that users can access these applications in a private network.
If you have any questions regarding Instaclustr’s Private Network Clusters then please contact us.
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 to run in your AWS account, 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 Centers 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 us.
Clusters spanning multiple Data Centers (Multiple Regions)
Private Network Clusters can span multiple Data Centers across region. 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 us.
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 interface. Examples of such services include:
- Kibana’s web user interface,
- Zeppelin’s web user interface,
- Spark Job Server’s REST API,
- Elassandra’s Elasticsearch 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 only available for clusters running AWS.