Private network guide

Note: groundcover inCloud is available only to users subscribed to one of our paid plans.

Deployment Overview

1. groundcover is deployed in private subnets.

   • Nodes access public internet using NAT

2. Internal Load Balancer is deployed to accept traffic from your workloads.

3. Peering subnets are set up to allow you to create VPC peering routes from your production subnets to peered subnets.

Security Principles

1. groundcover is denied access at the IP route level from sending traffic towards your production workloads.

2. Your production workloads are able to send traffic to groundcover over a unidirectional enter point using “inCloud internal LB”.

3. inCloud EKS instances are isolated from public traffic at the IP route level.

4. EKS Public API is exposed to predefined IP addresses [3.86.137.43, 44.217.56.175]

Integration Steps

Private subnets

These subnets will be used by groundcover inCloud to run worker nodes.

1. Pick two AZ (for ex. us-east-1a and us-east-1b)

2. Create one private subnet per AZ with a /22 address range.

3. Tag subnets with:

   1. groundcover:access = owner

4. Make sure each AZ route table has a 0.0.0.0/0 route to a local NAT Gateway

Peering subnets

These subnets will be used by groundcover inCloud for NLB endpoints.

1. Create one additional subnet per AZ

2. Minimal private address range should be /30 (higher is accepted)

3. Tag subnets with:

   1. groundcover:access = read

VPC Peering

To allow production workloads to send telemetry traffic, VPC peering should be set to the “VPC Peering route table”

Note: VPC peering should be set to “peering subnets” route table.