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.

   1. Nodes access public internet using NAT

2. Internal Load Balancer is deployed for accepting traffic from customer workloads.

3. Peering subnets are set-up to allow customer to create VPC peering routes from his production subnets to peered subnets.

Security Principles

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

2. Customer production workloads are able to send traffic to groundcover over 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. Please pick 2 AZ (for ex. us-east-1a and us-east-1b)

2. Create 1 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 1 additiinal 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-up to the “VPC Peering route table”

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