Instaclustr Launches Private Network Clusters
via instaclustr.com
Instaclustr is pleased to announce the release of a new feature, Private Network Clusters. This feature continues Instaclustr’s commitment to security by providing our customers with the option to provision clusters where the nodes do not have publically routable IPs allocated.
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.
Private Network Clusters adds to Instaclustr’s ongoing commitment to providing the most secure choice for running Cassandra in the cloud with existing features including:
- 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 complete list see https://www.instaclustr.com/instaclustr-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 Clusters are available as an option on newly provisioned clusters. Existing clusters can be migrated to a Private Network Cluster. Customers interested in migrating to a Private Network Cluster should contact support@instaclustr.com. Private Network Clusters are available in Beta (general availability expected prior to the end of November), for customers using AWS.
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.