Lock down "egress anywhere" policies for known external services

[mjnagel]

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:

• For egress to SSO we should lock down to the tenant/admin gateway since our service entries will handle this and not require true egress outside the cluster.
• For egress to specific external services like S3, RDS, we should explore istio service entries + a locked down outbound traffic policy
• For egress to "unknown things" (may not have a hostname) we should consider configurable CIDR values for the end user to pass in. This could also be a short-term solve instead of service entries if that is more challenging to implement.

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 https://github.com/defenseunicorns/uds-core/issues/487).

[mjnagel]

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.

[JoeHCQ1]

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)?

[mjnagel]

@JoeHCQ1 just to clarify on...

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.

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).

[mjnagel]

To implement this, I'd propose two new additions to the Package CR:

• remoteHost: This would be configurable with a specific host name. Implementation would be with service entries + a sidecar outbound traffic policy to restrict traffic to only those serviceentries. Note that on the netpol side we will likely still need egress "anywhere" but the service entries will lock down beyond the netpols.
• remoteCidr: Would allow a configurable CIDR, implemented with netpols.

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.