✨ Include network policy for all configmap and grpc catalogsources

[joelanford]

Description of the change:

This change updates OLMv0 to generate and reconcile two NetworkPolicy objects for each CatalogSource where OLMv0 also manages a catalog pod (i.e. configmap and grpc-based catalog sources).

1. GRPC server pods need to listen and receive requests on port 50051
2. Bundle unpack pods need to make connections to the kubernetes API server.

Related implementation details:

• Informer events from network policies are handled by the catalog operator, so any deletions or changes are reverted.
• Each NetworkPolicy gets an owner reference so that it is automatically cleaned up when the catalog source is deleted.
• Each NetworkPolicy uses a pod selector that specifically targets the appropriate pods, so there should be no accidental blocking of traffic of unrelated pods.

Unit tests are updated to ensure that NetworkPolicy objects are handled correctly.

Motivation for the change:

By adding NetworkPolicy, we can provide more security to mitigate vulnerabilities and avoid accidental data leaks.

Architectural changes:

None (unless you count managing NetworkPolicy for CatalogSources as an architectural change)

Testing remarks:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Bug fixes are accompanied by regression test(s)
• e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• Docs updated or added to /doc
• Commit messages sensible and descriptive
• Tests marked as [FLAKE] are truly flaky and have an issue
• Code is properly formatted

[dinhxuanvu]

Looking good. A few comments.

[dinhxuanvu]

/approve

[perdasilva]

is it possible that some future additional field breaks this function?

[joelanford]

Yes, that is possible. I looked at using equality.Semantic.DeepDerivative() instead, but I didn't want to allow someone to add an extra network policy rule or change the selector in a way that would say "all good" from a deep derivative perspective.

We could potentially write a diff detector in a different way that would be less susceptible to future API changes, but also still secure in terms of reverting undesirable changes.

[joelanford]

I changed this to be specific to network policy and exactly what we care about:

1. Our labels are there (but others can be added)
2. The specs are identical

[perdasilva]

do we need an e2e? could a unit test cover this case?

[joelanford]

Maybe? I didn't look too closely. The main bit of coverage I wanted here was "is there an NP event that the catalog-operator notices and causes there to be a sync of the relevant CatSrc"

It seemed like there were other e2e's for similar catsrc reconcile behaviors, so I followed the pattern.

[perdasilva]

@joelanford is this ready for review? it looks pretty good to me =D

[joelanford]

is this ready for review? it looks pretty good to me =D

Yes-ish. I think the catalog pod network policy is reviewable. But I realized I also need to add dynamic network policy handling for bundle unpack pods.

I could do that here, or I could do it in a separate PR. I don't really care which.

I also have this listed as a draft because the RFC is still in review: https://docs.google.com/document/d/1TCb2YsSHaXBUnUUFp44Bt2hdsb2jwLnL77imP25QGVs/edit?tab=t.0#heading=h.x3tfh25grvnv

[joelanford]

Ready for review again!

RFC is here: https://docs.google.com/document/d/1TCb2YsSHaXBUnUUFp44Bt2hdsb2jwLnL77imP25QGVs/edit?tab=t.0#heading=h.x3tfh25grvnv