Google Exposure Notification Key Server

Server deployment options

This document describes possible strategies for building and hosting the Exposure Notification Key Server components. You should use this information explore and compare trade-offs when making hosting decisions.

The Exposure Notification Key Server can be deployed in the following environments:

• Fully self-hosted or on-premises
• Fully managed Google Cloud
• A combination of self-hosted and fully managed

For more details on each component, see the Server Functional Requirements.

Server architecture

The Exposure Notification Key Server has multiple components which can be categorized as compute and data. To understand deployment scenarios, you should look at the architecture of the server and data flow between servers and devices.

The Exposure Notification Key Server compute components have been designed to be stateless, scalable, and rely on data stored in a shared database. This makes the compute components suited to deployment on serverless compute platforms.

Serverless platforms can scale down to zero during times of zero usage, which is likely if the Exposure Notification Key Server deployment covers a single or small number of countries. During times of high demand, serverless platforms can scale to meet demand.

Server components

	Purpose	Fully Hosted Google Cloud	Self-hosted, Google-managed	Self Hosted Kubernetes
Data components
Exposure key database	Stores anonymized exposure keys from devices identified as exposed	Google Cloud SQL (PostgreSQL)	PostgreSQL hosted with on-prem Kubernetes	PostgreSQL on Kubernetes
Exposure key batches storage	Storing batches of exposure keys that will be sent to devices.	Google Cloud Storage	Open Source Blobstore hosted with on-prem Kubernetes	Kubernetes hosted Open Source Blobstore (ie. min.io, rook). Could also use Redis and reconstruct batches
Certificate and key storage	Secure Storage for secrets such as signing, private keys, etc.	Secret Manager	Anthos GKE on Prem + KMS	HashiCorp Vault
Compute components
Exposure key ingestion server	Ingestion of exposure keys from client devices.	Google Cloud Run	On-prem Kubernetes with Cloud Run for Anthos GKE on-prem	Kubernetes with Knative Serving
Exposure Reporting Server	Serves anonymous keys of exposed users	Google Cloud Storage + Google Cloud CDN	On-prem Kubernetes with Anthos GKE on-prem, Or Google Cloud CDN	Kubernetes with Knative Serving + Redis
Data deletion	Deletion of data that is older than a configured time limit.	Google Cloud Run	On-prem Kubernetes with Anthos GKE on-prem	Kubernetes, either a job or Knative Service
Batch exposure keys	Periodic DB queries to batch data for client consumption. Signing payloads for verification on device.	Google Cloud Run	On-prem Kubernetes with Anthos GKE on-prem	Kubernetes, either job or Knative Service
Periodic data batching and deletion	Used to control running of periodic jobs (deletion, batching)	Google Cloud Scheduler	Kubernetes Cronjobs	Kubernetes Cronjobs
Content delivery network	Distribution of keys to client devices	Google Cloud CDN	Third Party CDN, Redis + Server, or allow direct access to storage	Third Party CDN, Redis + Server, or allow direct access to storage
Optional components
Federated ingestion	Ingestion of keys from other parties.	Google Cloud Run	On-prem Kubernetes with Anthos GKE on-prem	Kubernetes with Knative Serving
Federated access	Allows other parties/countries to retrieve data	Google Cloud Run	On-prem Kubernetes with Anthos GKE on-prem	Kubernetes with Knative Serving

Hosting infrastructure options

Data and compute hosted on premises

You can host all components of the Exposure Notification Key Server on-premises.

Deploying compute and data components on-premises allows you to have complete control of all components and deploy them in any location by using an on-premises Google Kubernetes Engine cluster. However, an on-premises deployment will require you to configure and maintain the underlying infrastructure, and ensure it is able to meet usage demands.

When the Exposure Notification Key Server is deployed on-premises, we recommend you deploy audit and access logging to the data and API endpoints. This is automatically available in the fully managed, and hybrid deployment scenarios.

Storing data on-premises and using Google-managed compute

The Exposure Notification Key Server supports either compute or data components to be hosted on-premises or on Google Cloud.

This example deployment has compute components running on Google Cloud Serverless products, with databases hosted on-premises. Alternatively, you could use an Anthos cluster to host compute components on premises, and have the data components hosted on Google Cloud as a fully managed service.

Fully hosted on Google Cloud

This example deployment hosts all components of the system on Google Cloud.

By using fully hosted components most of the service’s operation can be delegated to Google Cloud, which will provide audit and access logging of the data. For example, Cloud SQL will manage the infrastructure for a hosted PostgreSQL database.

This solution requires hosting within a Google Cloud location which may not exist in a location that permits use for all parts of the Exposure Notification Server architecture.

Edit this page