Network configuration

Back end and database components are on separate, isolated networks.

The "public" network that houses the application instances and NAT Gateway;
The "private" network that houses the database;
The "bastion" network in the OPS environment that houses the single bastion instance.

All incoming requests from the Internet arrive via AWS Elastic Load Balancer (ELB) services. The ELB service is unique per environment. Amazon ensures that the AWS ELB service is redundant and fault-tolerant.

Tidepool also uses the AWS NAT Gateway Service to allow internal instances to reach out to the Internet, for example to reach out for time updates (via NTP), but does not allow outside traffic in. The NAT Gateway also provides automatic fault tolerance.

Only strictly necessary ports are configured:

Ports 80 (http) and 443 (https) on service instances or clusters
Tidepool does not provide any web services over port 80/HTTP and is not required for operations, port 80 redirects are provided as a convenience.
Our end-user and clinic application site, app.tidepool.org, and our api endpoint (api.tidepool.org) only uses HTTPS port 443. HTTP port 80 automatically redirects (via 301 Permanent Redirect) to the same page on HTTPS over port 443.
Internal servers with no public-facing ports use self-signed certificates so that all data communication is encrypted in transit at all times via a service mesh.
Access to kubernetes nodes for administration is provided via the Kubernetes proxy, which requires internal SSO, and requires multi-factor authentication.

No direct remote access is possible to Kubernetes application clusters and all changes are handled via a GitOPS workflow, where everything including the infrastructure is being managed via code.

Some Tidepool EC2 instances are used for development and testing, so Bastion Hosts are retained for this reason, though there is no backend access to Kubernetes clusters.