An overview of the AWS deployment options

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.

Option 1

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.

Option 2

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.

Option 3

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.

Option 4

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.

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

    extra_hosts:
      - "backup.us-gov-west-1.amazonaws.com:127.0.0.1"
      - "iam.us-gov.amazonaws.com:127.0.0.1"
      - "eks.us-gov-west-1.amazonaws.com:127.0.0.1"
      - "apigateway.us-gov-west-1.amazonaws.com:127.0.0.1"
      - "route53.us-gov.amazonaws.com:127.0.0.1"

E.g.

---
version: '3.7'

services:
  postgresql:
    image: "hyperglance/postgresql:latest"
    container_name: postgresql
    restart: always
    volumes:
      - /var/lib/data/postgresql:/var/lib/pgsql:rw

  httpd:
    image: "hyperglance/httpd:latest"
    container_name: httpd
    restart: always
    ports:
      - "443:443/tcp"
    env_file:
      - /var/lib/data/hyperglance/config.env
    volumes:
      - /var/lib/data/httpd/mellon:/etc/httpd/mellon:rw
      - /var/lib/data/httpd/ssl:/etc/httpd/ssl:ro
      - /var/lib/data/log/httpd:/var/log/httpd:rw

  wildfly:
    image: "hyperglance/wildfly:latest"
    container_name: wildfly
    restart: always
    depends_on:
      - "postgresql"
    env_file:
      - /usr/local/hyperglance/defaults.env
      - /var/lib/data/hyperglance/config.env
    volumes:
      - /var/lib/data/log/wildfly:/opt/wildfly/standalone/log:rw
      - /var/lib/data/hyperglance/rules:/var/lib/hyperglance/rules:rw
      - /var/lib/data/hyperglance/export_archive:/var/lib/hyperglance/export_archive
      - /var/lib/data/hyperglance/license:/opt/wildfly/standalone/data/lic/:rw
      - /usr/local/hyperglance/hg.bin:/opt/wildfly/standalone/data/hg.bin:rw
      - /var/lib/data/hyperglance/hgs-email.properties:/opt/wildfly/standalone/deployments/hgs.ear/lib/common.jar/email.properties:rw
    extra_hosts:
      - "backup.us-gov-west-1.amazonaws.com:127.0.0.1"
      - "iam.us-gov.amazonaws.com:127.0.0.1"
      - "eks.us-gov-west-1.amazonaws.com:127.0.0.1"
      - "apigateway.us-gov-west-1.amazonaws.com:127.0.0.1"

We recommend looking at the published IAM policy requirements and comparing to available VPCEndpoints.

At the time of authoring this article, the available VPC endpoints and gateways available for services that Hyperglance ingests were these:

1. EC2
2. ECS
3. EKS
4. ELB
5. Lambda
6. LoadBalancing
7. RDS
8. Redshift
9. S3
10. STS
11. SQS
12. SNS
13. Workspaces
14. Access-Analyzer
15. Auto-scaling
16. Backup
17. CloudWatch monitoring
18. DynamoDB