Prevent default security groups from accessing registration DB#1718
Merged
jacobwinch merged 1 commit intomainfrom Mar 5, 2026
Merged
Prevent default security groups from accessing registration DB#1718jacobwinch merged 1 commit intomainfrom
jacobwinch merged 1 commit intomainfrom
Conversation
jacobwinch
added
the
maintenance
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
akash1810
approved these changes
Mar 5, 2026
Contributor
Author
A quick update on this one. There are now 0 related resources; yesterday there were still 2 ENIs that referred to a |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this change?
There have been a few different networking approaches used to control access to the
registrationDB over the years:registrationDB by joining the VPC's default security group (i.e. the default security group that AWS provides).registrationDB by joining a new security group (which was created by Guardian engineers in response to this issue). This allowed us to resolve a number of FSBP issues, but did not follow the principle of least privilege, as a number of services which didn't need DB access were also joining this group1.registrationDB (including via its proxy) if it joins a dedicated 'Postgres Access' security group (which was created in New security group for Postgres access to registration db #1636).In #1636, #1705, #1707, #1708 and #1709 we updated all services which need DB access to start using the new approach (3). This means that we can now officially remove the AWS default security group (1) and the Guardian 'default' security group (2) from the ingress rules associated with the
registrationDB.Once this PR is deployed (and the import here is removed), we should also be able to delete the Guardian 'default' security group (2) via https://github.com/guardian/mobile-platform/pull/727.
How has this change been tested / checked?
I've deployed this branch to
CODEto check that the CFN change is valid.I've also done some checking in the AWS console to confirm that this change will be safe. In the console we can see resources that are associated with a given security group. For the new 'Postgres Access' security groups (3), we can see the expected instances and Lambdas:
registrations-db-CODE-accessregistrations-db-PROD-accessFor the old security groups (1 and 2) we don't see any associated instances or Lambdas:
default(1):Notifications VPC Main Security Group (CODE and PROD)(2):How can we measure success?
This should improve our security posture but all functionality should keep working as before.
Have we considered potential risks?
There is a small risk that something is currently relying on one of the default security groups (1 or 2) in order to access the DB. I think the steps taken to check for usage via the console are sufficient to mitigate this risk.
Footnotes
At one stage this also provided other functionality, such as the ability to access parameter store via an interface endpoint. This functionality is now available to any instance running in the private subnet, so services such as
notificationorreportno longer need to join a special security group for this. ↩