Choose the AWS deployment option that best matches your security posture
Hyperglance needs access to the AWS API in order to collect data. By default, the AWS endpoints are public IPs. There are various methods of securing access to Hyperglance, you will be led by your security posture as to which one to use.
The order in terms of deployment complexity follows:
- Option 1: The Hyperglance instance has a Public IP, inbound access is limited using a security group
- Option 2: The Hyperglance instance has a Public IP, inbound and outbound access is limited using a security group and a Network Access List (NACL)
- Option 3: The Hyperglance instance is placed behind a NAT Gateway or Load balancer
- Option 4: The Hyperglance instance runs in a private subnet and has multiple Virtual Private Cloud Endpoints configured for access to the AWS API via private IPs
With all options it is best security practice not to use your AWS account's root user to perform any deployment.
This is the default deployment option using the Cloud Formation Template (CFT) when using the AWS Marketplace.
The Hyperglance Instance is deployed with a public IP in a subnet that is connected to an Internet Gateway via a route table entry: 0.0.0.0/0 to igw
Outbound is allowed, inbound is secured using a Security Group that restricts inbound IP to your company IP ranges.
Adding in NACL entries to limit outbound and inbound connections adds to security. The Instance still needs a Public IP.
The Hyperglance Instance is deployed with a public IP in a subnet that is connected to an Internet Gateway via a route table entry.
Outbound is allowed, inbound is secured using a Security Group and a Network Access List that restricts inbound IP to your company IP ranges.
Adding a NAT Gateway or Load Balancer means you can remove the Public IP from the Hyperglance Instance.
The Hyperglance Instance is deployed with a Private IP in a subnet that is connected to a NAT Gateway.
The NAT Gateway uses an Internet Gateway for outbound access.
Inbound is restricted by both the NAT Gateway and a Security Group applied to the Hyperglance Instance.
If you need to run Hyperglance with no internet access at all you must run the Instances in a private subnet that has multiple Virtual Private Cloud Endpoints (VPCE) configured. This also means that you will not be able to update the Hyperglance software unless you contact us to allow you access to our ECR repository. You will need to configure an ECR VPCE.
The Hyperglance Instance is deployed with a Private IP in a subnet that is connected to Multiple VPC Endpoints that enable AWS API access per service.
There is a subset of services that are currently supported at the time of writing this article. The services that do not have an endpoint available will not be able to be collected by Hyperglance.
Hyperglance will attempt to connect to all services so there will be a delay in collection. This delay can be improved by causing those services to fail-fast. To do that add this configuration to the wildfly image in /etc/docker-compose.yml
Currently available VPC endpoints for support services: