NetworkPolicies for System Namespaces #613
Conversation
|
(There's no actual epic filed for this yet, but since it's going to take several releases to move all the pieces into place I wanted to start early...) |
danwinship
force-pushed
the
system-networkpolicies
branch
from
b188e54 to
593ce2c
Compare
|
Hmm - one thought about how we might be able to incrementally enhance this: all new system namespaces need to have a network policy in them (which we can enforce with an e2e test). This would be regardless of "restricted mode". |
| as restricted, and CNO would fix things up if they were supposed to be | ||
| open. | ||
|
|
||
| However, 2b would make upgrades more complicated, since we have to |
There was a problem hiding this comment.
Do we really need to worry about this? The only connections that would be disrupted would be
- Connections we somehow missed when writing network polices, and
- Only between operator S upgrade and CNO upgrade.
Because option 2-b seems like the best choice. It also gets us closer to a cno-manged "all-namespaces-are-restricted" mode, a.k.a. son-of-Multitenant.
There was a problem hiding this comment.
I didn't mean "upgrades in general", I meant specifically the case of upgrading from a version of OCP that doesn't implement this feature, to the version of OCP that does, in a cluster where the administrator does not want to be using this feature, and has components of their own that we don't know about accessing random OpenShift components. In that case, during the upgrade, user workloads would be blocked from accessing OpenShift components, possibly creating outages.
If you're going to argue that that's not a real problem, then you're essentially arguing that we don't actually need to preserve the permissive option at all; we can just start switching all components to be restrictive with no way to override it.
danwinship
force-pushed
the
system-networkpolicies
branch
from
593ce2c to
a9ca2df
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
For https://issues.redhat.com/browse/RFE-701; add a mode in which system services are protected by NetworkPolicies (in addition to the existing TLS certificate authentication), for "defense in depth".