@soltysh (re openshift/origin#17491)
@deads2k This is what's breaking test_branch_origin_extended_networking

Are namespace constrained users expected to have write access to network policy? Or is that a tool for the cluster administrator to optionally grant?

NetworkPolicy was specifically designed to be used by namespace admins. (They give you the power to keep other users out of your namespace, but don't give you the power to get into other users' namespaces or anything like that.) (And these policies match what we do in OpenShift.)

I guess in theory a cluster admin might want to create a policy like "allow connections from pods in the magic-admin-can-connect-to-everything namespace" in each namespace and then not let namespace admins delete it. But I don't think that's much different from "in theory a cluster admin might want to create a pod/service and not let the namespace admin delete it".

Naively, I would have expected a common network policy to be something like "don't let pods hit the AWS metadata service" to prevent pods from getting node credentials. That seems like something a cluster admin wouldn't want a user in a namespace to be able to get around.

Does network policy not control egress as well?

NetworkPolicy can control egress now, but the feature is explicitly described as being for namespace-admin use, not for cluster-admin use. Well, OK, actually it's not documented very well, but it that's how it was always discussed and how it was designed. The use case it solves is

As a project administrator/developer I want to ensure that my pods only make outgoing connections to the pods/services/IPs they are expected to connect to, so that if hackers break into my pods, they can’t use them to attack arbitrary targets.

and not

As the administrator of a kubernetes cluster, I want to allow some pods/namespaces to access certain restricted IP addresses, but not allow all pods to access all IPs; and project admins and developers must not be able to override these rules.

which we discussed but assumed we couldn't implement with NetworkPolicy because we were still thinking in a pre-RBAC mindset where there is no one (within the Kubernetes API) more powerful than a namespace admin. If we implement that use case later, it would be via a separate resource type, because the expectation with NetworkPolicies has always been that namespace admins have complete control over NetworkPolicies in their namespace.

(Use cases from this doc.)

@thockin can you confirm that I'm representing the intent of NetworkPolicy correctly? (That namespace admins are expected to have complete control over NetworkPolicies in their namespaces.)

@kubernetes/sig-auth-pr-reviews @kubernetes/sig-network-pr-reviews

@thockin can you confirm that I'm representing the intent of NetworkPolicy correctly? (That namespace admins are expected to have complete control over NetworkPolicies in their namespaces.)

talked with @thockin, and that was the intent (the app owner controls network policy for their app). if we want a control for the cluster-admin to lock down namespaces, that's likely to be represented as a separate resource (possibly cluster-scoped, possibly namespace-selecting, etc)

/lgtm

/approve no-issue

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, liggitt

Associated issue requirement bypassed by: liggitt

The full list of commands accepted by this bot can be found here.

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@danwinship: The following test failed, say /retest to rerun them all:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.