✨ add NetworkPolicy objects for catalogd and operator-controller #1942
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| apiVersion: networking.k8s.io/v1 | ||
| kind: NetworkPolicy | ||
| metadata: | ||
| name: controller-manager | ||
| namespace: system | ||
| spec: | ||
| podSelector: | ||
| matchLabels: | ||
| control-plane: catalogd-controller-manager | ||
| policyTypes: | ||
| - Ingress | ||
| - Egress | ||
| ingress: | ||
| - ports: | ||
| - protocol: TCP | ||
| port: 7443 # metrics | ||
| - protocol: TCP | ||
| port: 8443 # catalogd http server | ||
| - protocol: TCP | ||
| port: 9443 # webhook | ||
| egress: | ||
| - {} # Allows all egress traffic (needed to pull catalog images from arbitrary image registries) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| apiVersion: networking.k8s.io/v1 | ||
| kind: NetworkPolicy | ||
| metadata: | ||
| name: controller-manager | ||
| namespace: system | ||
| spec: | ||
| podSelector: | ||
| matchLabels: | ||
| control-plane: operator-controller-controller-manager | ||
| policyTypes: | ||
| - Ingress | ||
| - Egress | ||
| ingress: | ||
| - ports: | ||
| - protocol: TCP | ||
| port: 8443 # metrics | ||
| egress: | ||
| - {} # Allows all egress traffic (needed to pull bundle images from arbitrary image registries) | ||
|
There was a problem hiding this comment. Just as a bit of context — back when we added this to Kubebuilder, there was a request from the community for us to use labels. The idea was to allow scenarios where, for example, a Pod wants to scrape metrics. In those cases, having specific labels becomes necessary to permit that traffic through the You might want to take a look at this example for reference: So, we might want to consider the same approach. Sharing to allow you to think about the pros and cons. There was a problem hiding this comment. Given that we are fully open now, I think keeping it simple and slightly more open is better for this first pass. If we find later that we can ratchet down access to metrics and the catalogd webhook port in a general way, we can do that later. There was a problem hiding this comment. OK, we can do a follow-up after checking that this config works on the downstream as well. |
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we just need Ingress, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First I did like you there, and I received this feedback from community: kubernetes-sigs/kubebuilder#3853 (comment)
So, we might need to reconsider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We explicitly want to allow all egress traffic both catalogd and operator-controller because they need to be able to communicate with unknown-in-advance image registries. If we are not explicitly granting that access, then another NetworkPolicy that matches our pod that is more restrictive could break us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll need to be more restrictive to make sense.
But I get your point.
We can also enhance it on follow ups. So, 👍