feat: Allow access to Postgres from the office (and VPN)

[akash1810]

What does this change?

Add an ingress rule to the Postgres security group, allowing connection from the Engineering subnet.

The CloudFormation diff is quite big, however that's largely due to one change - we're now explicitly creating a security group for the database, rather than letting AWS CDK create one. This change has a cascading effect across most other resources in the stack.

As noted, a bastion host might be a better option here as it means we're not reliant on the network to limit access. Thoughts on whether this is blocking welcomed. See also guardian/cdk#1786.

Why?

This means we can connect to the database from the office network, as it is sometimes easier to run queries outside of Grafana.

We had previously added this ingress rule manually (i.e. introduced drift); this change encodes it.

How one connects is down to preference. Personally, I'd be recommending using the AWS Toolkit for JetBrains as it allows one to authenticate via IAM credentials, i.e. credentials issued by Janus.

How has it been verified?

I have performed the following steps:

• Confirmed I can access Postgres locally when connected to the VPN
• Removed drift
• Deployed main
• Confirmed I can no longer access Postgres locally
• Deployed this branch
• Confirmed I can access Postgres locally when connected to the VPN

[akash1810]

This is a mocked value. See https://github.com/guardian/private-infrastructure-config/blob/d8dde2549cac6323508bbf95bfc34712e010c4e0/src/private-networks.ts#L7 for the real value.

[akash1810]

Summarising a discussion with @itsibitzi about this:

Location based trust is terrible, however we're maintaining DB auth, so not so bad. Generally speaking, we should consider the office network as good as compromised. A bastion host removes the network trust layer, so would be an improvement here.

Also worth noting that the ingress rule of 10.X.X.X is only possible for accounts using Direct Connect, meaning this repository cannot be used as a reference implementation. Moving to a bastion host would change that¹.

I'll merge this, and look at adding a bastion host soon after.

Footnotes

1. Though actually, the creation of a bastion host should be abstracted into GuCDK. ↩

[akash1810]

I'll merge this, and look at adding a bastion host soon after.

UPDATE: Attempts to use the AWS CDK bastion host results in:

Error: Resolution error: Resolution error: Found an encoded list token string in a scalar string context. Use 'Fn.select(0, list)' (not 'list[0]') to extract elements from token lists...

I think we'd need to update https://github.com/guardian/aws-account-setup to export the values of the VPC, and we can then use importListValue to resolve this.