Network configuration

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

  1. The "public" network that houses the application instances and NAT Gateway;

  2. The "private" network that houses the database;

  3. The "bastion" network in the OPS environment that houses the single bastion instance.

 

Search this space

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 443 (https). HTTP port 80 automatically redirects (via 301 Permanent Redirect) to the same page at 443 (https).

  • Internal clusters with no public-facing ports use self-signed certificates to encrypt data in transit at all times via a service mesh.

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.

 

The content of the Tidepool Technical Documentation is licensed under a Creative Commons CC0 1.0 Universal (CC0 1.0) Public Domain Dedication.