✨ Include network policy for all configmap and grpc catalogsources#3568
Conversation
joelanford
changed the title
joelanford
force-pushed
the
catalog-source-network-policy
branch
2 times, most recently
from
7e73286 to
b8dbde0
Compare
joelanford
changed the title
joelanford
force-pushed
the
catalog-source-network-policy
branch
2 times, most recently
from
437b8cb to
b9ecf89
Compare
dinhxuanvu
left a comment
dinhxuanvu
left a comment
There was a problem hiding this comment.
Looking good. A few comments.
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
| return np | ||
| } | ||
|
|
||
| func sanitizedDeepEqual(a client.Object, b client.Object) bool { |
There was a problem hiding this comment.
is it possible that some future additional field breaks this function?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I changed this to be specific to network policy and exactly what we care about:
- Our labels are there (but others can be added)
- The specs are identical
| Expect(registryPods.Items).To(HaveLen(1), "unexpected number of replacement registry pods found") | ||
| }) | ||
|
|
||
| It("delete registry network policy triggers recreation", func() { |
There was a problem hiding this comment.
do we need an e2e? could a unit test cover this case?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'm just worried about adding additional e2es XD but I'd also say that if the effort to make it a unit test is too big, it's not worth the effort...let's proceed as it is
|
@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
force-pushed
the
catalog-source-network-policy
branch
3 times, most recently
from
f2a4870 to
026ceff
Compare
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
Ready for review again! RFC is here: https://docs.google.com/document/d/1TCb2YsSHaXBUnUUFp44Bt2hdsb2jwLnL77imP25QGVs/edit?tab=t.0#heading=h.x3tfh25grvnv |
Signed-off-by: Joe Lanford <joe.lanford@gmail.com>
Signed-off-by: Joe Lanford <joe.lanford@gmail.com>
perdasilva
force-pushed
the
catalog-source-network-policy
branch
from
026ceff to
c598875
Compare
8723097
…perator-framework#3568) * include network policy for all configmap and grpc catalogsources Signed-off-by: Joe Lanford <joe.lanford@gmail.com> * add network policy for bundle unpack pods Signed-off-by: Joe Lanford <joe.lanford@gmail.com> --------- Signed-off-by: Joe Lanford <joe.lanford@gmail.com>
3 participants
Description of the change:
This change updates OLMv0 to generate and reconcile two
NetworkPolicyobjects for eachCatalogSourcewhere OLMv0 also manages a catalog pod (i.e. configmap and grpc-based catalog sources).Related implementation details:
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
/doc[FLAKE]are truly flaky and have an issue