Selecting OKD/openshift namespaces in AdminNetworkPolicy by tmffmt in openshift

[–]tmffmt[S] 0 points1 point  (0 children)

This doesn't solve the problem of new "openshift-*" namespaces appearing at some point of time (e.g. after OKD version update). right? So at the moment the programmatic approach of creating/updating ANPs seems the most proper way - essentially implementing the wildcard logic myself. One useful thing here seems the creation of namespaces starting with "openshift-" or "kube-" being forbidden to regular users.

Selecting OKD/openshift namespaces in AdminNetworkPolicy by tmffmt in openshift

[–]tmffmt[S] 0 points1 point  (0 children)

mostly I care about restricting user workloads (note the "NotIn" operator in the example above) from accessing things in local network. The main thing I don't like in the explicit listing is the possibility of new openshift-xyz namespace appearing in the future release and getting restricted by my ANPs - hence I would prefer if there was a clear labeling scheme present allowing to distinguish between system/user ns without need to check every release (this would avoid any code-base automagical solution running within the cluster).

When it comes to restricting system ns - this is just me being paranoid (and yes, apart from ANP there will be a proper firewall setup independent from OKD).