-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lock down "egress anywhere" policies for known external services #558
Comments
Also linking for another option/defense in depth - we don't currently leverage NeuVector's network rules but they could provide a layer of "learned access" if we needed to keep initial policies more open. |
## Description > [!IMPORTANT] >⚠️ **BREAKING CHANGE** This is a breaking change that requires `uds-core` `v0.22.0` but locks down GitLab to have no `remoteGenerated: Anywhere` entries by default. ## Related Issue Relates to defenseunicorns/uds-core#558 ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [X] Other (security config, docs update, etc) ## Checklist before merging - [X] Test, docs, adr added or updated as needed - [X] [Contributor Guide Steps](https://github.com/defenseunicorns/uds-package-gitlab/blob/main/CONTRIBUTING.md#developer-workflow) followed
## Description > [!IMPORTANT] >⚠️ **BREAKING CHANGE** This is a breaking change that requires `uds-core` `v0.22.0` but locks down GitLab to have no `remoteGenerated: Anywhere` entries by default. ## Related Issue Relates to defenseunicorns/uds-core#558 ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [X] Other (security config, docs update, etc) ## Checklist before merging - [X] Test, docs, adr added or updated as needed - [X] [Contributor Guide Steps](https://github.com/defenseunicorns/uds-package-gitlab/blob/main/CONTRIBUTING.md#developer-workflow) followed
## Description > [!IMPORTANT] >⚠️ **BREAKING CHANGE** This is a breaking change that requires `uds-core` `v0.22.0` but locks down GitLab to have no `remoteGenerated: Anywhere` entries by default. ## Related Issue Relates to defenseunicorns/uds-core#558 ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [X] Other (security config, docs update, etc) ## Checklist before merging - [X] Test, docs, adr added or updated as needed - [X] [Contributor Guide Steps](https://github.com/defenseunicorns/uds-package-gitlab/blob/main/CONTRIBUTING.md#developer-workflow) followed
I'll plus-one this - when I permit Confluence or any other service to egress to talk to an external Postgres instance (an incredibly common use-case), I want to permit access only to that postgres IP or hostname, I don't want to be permitting it to phone out to anyone, anywhere, for anything, anytime. Right now I believe I am able to still restrict the destination port at least, which would prevent outgoing telemetry but not a malicious actor. Note, this ticket captures two asks right now, but only the second ask is explicit in the title: Ask 1: UDS team please augment the UDS package spec so we can lock down egress whereas we are often required to permit egress to Anywhere. Ask 2: UDS/SWF teams lock down existing egress anywhere policies where they exist in our UDS packages. Ask 1 is implicit in Ask 2, but Ask 1 blocks other teams, whereas Ask 2 is more of a issue of tech-debt for the UDS/SWF teams. For clarity, @mjnagel and @Racer159 , would it make sense to create another ticket to specifically request this ability be added to UDS core (ask 1)? |
@JoeHCQ1 just to clarify on...
It's important to remember that network policies can always be created outside of the Package CR spec, which gives you options to use a CIDR - this shouldn't be a blocking issue. Ideally everything can move to the Package CR eventually of course, but don't want any teams to feel blocked on this problem. I don't think we need a second ticket here, but if it would help to track something different I'm okay with another being opened. However we implement "Ask 1", we would want to "test" in our CI, which would cover at least part of "Ask 2" for uds-core. This could be done as multiple PRs to keep changes slightly smaller. Also should note that this ticket does not track any work on SWF or other projects, it is scoped to uds-core (and corresponding UDS Operator changes). |
To implement this, I'd propose two new additions to the Package CR:
On the core side we should identify places where we can use this (RDS/S3 egress come to mind) and implement there with configurable helm values for host/cidr. |
Describe what should be investigated or refactored
Our package should operate under a "least privilege" type model for network access, and specifically egress network access should be limited to specific services/addresses rather than "anywhere". All current
remoteGenerated: Anywhere
netpols should be evaluated for their necessity. There are a few changes we could make to reduce the scope of these:Links to any relevant code
https://github.com/search?q=repo%3Adefenseunicorns%2Fuds-core%20remoteGenerated%3A%20anywhere&type=code
Additional context
This would also be valuable to ensure we are providing the correct network access in our CI testing and identify places where apps may have phone home telemetry or other external network requirements (related to #487).
The text was updated successfully, but these errors were encountered: