[harvester] Use dedicated security group for accessing Postgres#1709
Merged
jacobwinch merged 2 commits intomainfrom Mar 4, 2026
Merged
[harvester] Use dedicated security group for accessing Postgres#1709jacobwinch merged 2 commits intomainfrom
jacobwinch merged 2 commits intomainfrom
Conversation
jacobwinch
added
the
maintenance
Contributor
jacobwinch
force-pushed
the
jw-harvester-sg
branch
from
a679a95 to
34b6823
Compare
jacobwinch
force-pushed
the
jw-harvester-sg
branch
from
34b6823 to
6883fe7
Compare
Contributor
akash1810
approved these changes
Feb 27, 2026
aracho1
approved these changes
Mar 4, 2026
Contributor
Contributor
Contributor
Contributor
Contributor
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
3 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?
The Notifications VPC has a “default group”. Prior to this PR,
harvesterused this group to gain access to the RDS database (via the RDS proxy). This approach to networking does not follow the principle of least privilege, as any network interface in the VPC can implicitly reach theCODEandPRODdatabases.In #1636 a new security group was created, with the intention of services joining it only if they need database access. This will ultimately allow us to remove the “default group”, thus improving our security posture by moving towards the principle of least privilege.
This PR updates
harvesterto use the new security group / approach1.How has this change been tested?
maintoCODE2ae14eea-2123-49e0-8614-168898ca6c09)CODEb878e245-4787-4573-894c-3e6a33131391)How can we measure success?
This is a step towards removing the "default group", which improves our security posture and allows us to standardise on a single approach following the changes made in #1636.
Have we considered potential risks?
If
harvestercannot query the DB then this will prevent us from sending notifications (such as breaking news notifications) to users. I think the testing described above confirms thatharvestercan still query the DB as expected.Footnotes
Note that all of the above applies regardless of whether the application connects to the RDS instance directly or whether it goes via the RDS proxy, because the RDS instance and the RDS proxy share the same security group (created here). ↩