Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

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 app instances

  • Port 123 Network Time Protocol (NTP) on all instances

  • HTTP port 80 is open on the public tidepool.org web sites, but only as a re-direct to HTTPS port 443. .

    • 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.

  • Access to kubernetes nodes for administration is provided via the Kubernetes proxy, which requires either AWS IAM credentials or Google Group membership and OIDC authentication to Google SSO. Both access methods require 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.

  • No labels