Allow including both podSelector and namespaceSelector in a NetworkPolicyPeer

[danwinship]

Updates NetworkPolicy API docs and validation to allow podSelector and namespaceSelector to be specified together in a NetworkPolicyPeer

Fixes #58637

Release note:

NetworkPolicies can now target specific pods in other namespaces by including both a namespaceSelector and a podSelector in the same peer element.

[danwinship]

/sig network

Is there anything else I missed in kubernetes itself? We'll also need a docs PR and a kubectl PR...

[danwinship]

Having actually written the docs now, I'm maybe more convinceable that we should go with podAndNamespaceSelector instead; it would work more cleanly with the idea of separately documenting each field in NetworkPolicyPeer like we do...

[caseydavenport]

Having actually written the docs now, I'm maybe more convinceable that we should go with podAndNamespaceSelector instead; it would work more cleanly with the idea of separately documenting each field in NetworkPolicyPeer like we do...

I'd prefer to not introduce a new field such as podAndNamespaceSelector

As a user of the API, I think the AND of podSelector and namespaceSelector is exactly how I'd expect those two to behave when both specified. In fact, even a generic AND would make sense to me, though I don't see what use-case I'd have for it.

As an implementor, it's almost no work on my side to simply support the AND combination of pod / namespace, whereas there's more for me to do to support a new selector field.

[thockin]

My concern is that the AND isn't generic (unless we make it so) and is therefore vastly more confusing.

…

On Mon, Feb 26, 2018 at 12:49 PM, Casey Davenport ***@***.***> wrote: Having actually written the docs now, I'm maybe more convinceable that we should go with podAndNamespaceSelector instead; it would work more cleanly with the idea of separately documenting each field in NetworkPolicyPeer like we do... I'd prefer to not introduce a new field such as podAndNamespaceSelector As a user of the API, I think the AND of podSelector and namespaceSelector is exactly how I'd expect those two to behave when both specified. In fact, even a generic AND would make sense to me, though I don't see what use-case I'd have for it. As an implementor, it's almost no work on my side to simply support the AND combination of pod / namespace, whereas there's more for me to do to support a new selector field. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#60452 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVEj32SsBZRwpRJyBQ8BaFRYNAyA3ks5tYxg-gaJpZM4ST1yk> .

[caseydavenport]

My concern is that the AND isn't generic (unless we make it so) and is
therefore vastly more confusing.

That may be, though with a well written out validation error I'd guess it would be fairly clear.

I understand it might be extra work for other implementors to do the generic AND, but from a Calico perspective it's trivial. So personally I'd rather have us implement the generic AND than add an extra type for people to reason with.

[danwinship]

That may be, though with a well written out validation error I'd guess it would be fairly clear.

"may not specify both ipBlock and another peer"

[thockin]

I am OK either way. Let's just get it in.

…

On Mon, Feb 26, 2018 at 2:45 PM, Dan Winship ***@***.***> wrote: That may be, though with a well written out validation error I'd guess it would be fairly clear. "may not specify both ipBlock and another peer" — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#60452 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVFLqNCaXnDmJeI2KVMIdd8Mn5Vfeks5tYzP_gaJpZM4ST1yk> .

[Lion-Wei]

I like this, is this anything I can help? Maybe the kubectl pr? @danwinship

[danwinship]

@Lion-Wei: sure. "kubectl describe" needs to be extended to be able to describe policies where a NetworkPolicyPeer has both podSelector and namespaceSelector set (describing it according to the semantics seen in the API docs here).

[danwinship]

/retest

[caseydavenport]

This LGTM - one minor comment.

I'm in favor of merging as-is, and further relaxing the validation if we get feedback that it's confusing.

[caseydavenport]

Need to add this back?

[Lion-Wei]

@danwinship I will push that pr as soon as this got merged. : )

[danwinship]

@caseydavenport repushed with the stray update.sh change removed if you want to /lgtm it

[caseydavenport]

/lgtm

[thockin]

/approve

[thockin]

This change is 

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[oivindoh]

What's holding this thing of outstanding natural beauty back? Just re-applying /lgtm?

[danwinship]

It's waiting for 1.10 to go out and master to reopen for 1.11. I'm not sure where the /lgtm went.

[thockin]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: caseydavenport, danwinship, thockin

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

The pull request process is described here

Needs approval from an approver in each of these files:

• api/OWNERS [thockin]
• docs/api-reference/OWNERS [thockin]
• pkg/apis/OWNERS [thockin]
• staging/src/k8s.io/api/OWNERS [thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[fejta-bot]

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

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

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

[ahmetb]

Is this technically a breaking change in the behavior? (or was it impossible to specify both namespaceSelector and podSelector on the same peer spec?)

[oivindoh]

@caseydavenport does this require a change in calico to work?

[danwinship]

@ahmetb It was previously impossible to specify both; validation would reject the resource in that case

[caseydavenport]

@oivindoh yeah, we'll need to make a minor change to Calico in order to make this work. Should be really straightforward.

Calico supports this already within its policy model, but the code which converts kubernetes policies doesn't yet expect this.