Exposure Notification Reference Key Server

View on GitHub

Getting Started

    How to Deploy
    How to Publish Keys
    How to Download Keys
    Estimating the Cost of Deployment

Design

    Server Deployment Options
    Server Functional Requirements
    Verification Protocol Design
    API Definitions

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:

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.

Exposure Notification Key Server data ingress flow

Exposure Notification Key Server data egress flow

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

A diagram of the Exposure Notification Key Server deployed 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.

A diagram of data ingress with the Exposure Notification Key Server that has compute components on Google Cloud and data on-premises

A diagram of data egress with the Exposure Notification Key Server that has compute components on Google Cloud and data on-premises

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.

A diagram of the Exposure Notification Key Server deployed 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