Private network guide
Note: groundcover inCloud is available only to users subscribed to one of our paid plans.
Deployment Overview
groundcover is deployed in private subnets.
Nodes access public internet using NAT
Internal Load Balancer is deployed to accept traffic from your workloads.
Peering subnets are set up to allow you to create VPC peering routes from your production subnets to peered subnets.
Security Principles
groundcover is denied access at the IP route level from sending traffic towards your production workloads.
Your production workloads are able to send traffic to groundcover over a unidirectional enter point using “inCloud internal LB”.
inCloud EKS instances are isolated from public traffic at the IP route level.
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.
Pick two AZ (for ex. us-east-1a and us-east-1b)
Create one private subnet per AZ with a /22 address range.
Tag subnets with:
groundcover:access = owner
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.
Create one additional subnet per AZ
Minimal private address range should be /30 (higher is accepted)
Tag subnets with:
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.
Last updated