Skip to content

Latest commit

 

History

History
50 lines (29 loc) · 4.15 KB

rfc-016-how-to-prevent-published-live-frontends-from-reading-from-the-draft-content-store.md

File metadata and controls

50 lines (29 loc) · 4.15 KB
Raw
status implementation status_last_reviewed status_notes
superseded
superseded
2024-03-06
We no longer use this infrastructure.

How to prevent published frontends from reading from the draft content store

Problem

The old draft stack used firewall rules to ensure that instances of frontend applications intended to serve published content were prevented from inadvertently reading from the instance of the content-store application used to serve draft (unpublished) content.

This is an operational risk for GOV.UK, since unpublished content may be embargoed for publication or otherwise contain sensitive information that should not become public until published.

Now that applications serving draft content are hosted in the same vCloud organisation as their counterpart instances used for published content (see ), we must identify any vectors through which the published frontends could read from the draft content store.

Proposal

Risk vectors

We have identified two ways that a published frontend application might inadvertently read from the draft instance of the content-store application:

  1. The instance of the content-store used for published content could inadvertently read from the draft instance of the content-store database if its database settings were misconfigured.
  2. Published instances of frontend applications could inadvertently read from the draft instance of the content-store application if their configuration was incorrect.

Mitigation for vector (1)

Vector (1) has been mitigated by avoiding the use of a default for the name of the content-store database when configuring the content-store application, meaning that each machine class (i.e. content_store or draft_content_store) must explicitly set the database name.

Mitigation for vector (2)

The draft instance of the content-store application is fronted by Nginx the existing api_lb machines, much the same way that the published instance of content-store is fronted by Nginx. The decision to share the api_lb for requests for both draft and published content was made to avoid the additional expense for creating two new draft_api_lb machines for serving draft content.

We initially explored access limiting by IP address within the Nginx virtual host for requests going to draft-content-store.production.alphagov.co.uk on the api_lb machines so as to block requests coming from published instances of frontend applications, however this was not possible because the client IP address in the HTTP request is presented as originating from the API vDC network's gateway IP address. This makes it impossible, in this configuration, to differentiate between requests from published and draft instances of frontend applications.

The only other possibility for implementing access control by IP address would be in the vShield Edge Gateway's firewall rules. Applying a firewall rule for the existing API vSE load balancer would not work as both published and draft applications would make requests through the same path and there would be no way to distinguish between requests intended for the published versus draft instances of content-store. 

To make that distinction possible, we propose to:

  • Instantiate a new vShield Edge Gateway (vSE) load balancer named 'DraftAPI', which will use the existing api_lb machines as its pool members on port 8443.
  • Add a new virtual host to Nginx on the api_lb machines that listens on port 8443 and have it serve requests destined for draft-content-store.production.alphagov.co.uk
  • Add a firewall rule to the vShield Edge Gateway that prevents IP addresses other than those used by the draft_frontend machines from connecting to the new 'DraftAPI' vSE load balancer.