Ingress policy: from clause semantics

[Salvatore Orlando]

I have two questions on the semantics of the "pods" and "namespace" selectors in the "From" clause. I hope my interpretation could be correct, but please correct me if you feel otherwise.

First... let's assume we only have either pods or namespace selectors.

Shall the policy allow traffic from pods that match all the selectors or from pods that match any selector?  I personally believe it should be "ANY" selector, as the selector construct itself expresses an AND condition.

Second... for a policy with both namespace and pods selectors, I think traffic should be allowed only from pods in the selected namespaces which match the pod selector, whereas when the ns selector is not specified, pods in all namespaces will be selected. The alternative would be to select pods in all namespaces according to the pod selector and then all pods in the namespaces selected by the namespace selector.

Cheers,

Salvatore

PS: I know I could have added comments to the document [1], but as I'm seeing new documents being created at this stage I felt better to send a post to the group ML until at least we consolidate again around a single document.

[1] https://docs.google.com/document/d/1qAm-_oSap-f1d6a-xRTj6xaH1sYQBfK36VyjB5XOZug

[Mike Spreitzer]

If I understand you correctly, I thought the questions you raised were already answered (and with the answers you advocate).  Please have a look at my attempt at a clearer write-up, https://docs.google.com/document/d/1cTA_c1qahzZ9nDI-h6Vp9-9_kCB-kk1cw91K0qRjI84 --- I think it clearly gives the answers you want.

[Salvatore Orlando]

Is the document you prepared the one that reflects current consensus?

If yes, I will disregard any previous document and only look at this one from now on.

As for the semantics of Pod and namespace selectors that is not what I was expecting, but at the moment I have only little clues on whether this would lead to better or worse user experience, so I will just accept and implement it!

Cheers,

Salvatore

On 11 April 2016 at 16:16, Mike Spreitzer <gmik...@gmail.com> wrote:

If I understand you correctly, I thought the questions you raised were already answered (and with the answers you advocate).  Please have a look at my attempt at a clearer write-up, https://docs.google.com/document/d/1cTA_c1qahzZ9nDI-h6Vp9-9_kCB-kk1cw91K0qRjI84 --- I think it clearly gives the answers you want.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-sig-network.
For more options, visit https://groups.google.com/d/optout.

[Mike Spreitzer]

I attempted to write down what I think Casey intends for the fuller proposal and the consensus is for the original proposal.  But "consensus" is maybe too strong a word, because I suspect different people have been putting different interpretations on the wording in the original documents.  That is why I tried to write down something with more precise language.  I wanted to test whether we all really do agree, and get it written in a less ambiguous way.  So I really need people to look at this and see if they agree that what I wrote is what they mean.

[Casey Davenport]

> Shall the policy allow traffic from pods that match all the selectors or from pods that match any selector?  I personally believe it should be "ANY" selector, as the selector construct itself expresses an AND  condition.

Yep, so long as it matches ANY “from” selector the traffic will be allowed (limited to any specified ports).

> Second... for a policy with both namespace and pods selectors, I think traffic should be allowed only from pods in the selected namespaces which match the pod selector, whereas when the ns selector is not > specified, pods in all namespaces will be selected. The alternative would be to select pods in all namespaces according to the pod selector and then all pods in the namespaces selected by the namespace selector.

We explicitly did not support defining a namespace selector and pod selector in the same “from” rule in order to avoid this.  At the moment, labels are only valid in a single namespace, so making them apply to other namespaces is not quite right.  At the moment it is an error on the API to specify both for the same rule.  If no “namespaces" is defined and “pods” is defined, then pods in the current namespace will be selected.  If no “pods” is defined and “namespaces” is defined, all pods in the selected namespaces will be allowed.  If both “pods” and “namespaces” are defined, it is an error.  If neither “pods” nor “namespaces” is defined, no sources are selected.

--

[Salvatore Orlando]

Casey,

Thanks for providing these clarifications

more inline

Salvatore

On 11 April 2016 at 18:04, Casey Davenport <Casey.D...@metaswitch.com> wrote:

> Shall the policy allow traffic from pods that match all the selectors or from pods that match any selector?  I personally believe it should be "ANY" selector, as the selector construct itself expresses an AND  condition.

Yep, so long as it matches ANY “from” selector the traffic will be allowed (limited to any specified ports). 

> Second... for a policy with both namespace and pods selectors, I think traffic should be allowed only from pods in the selected namespaces which match the pod selector, whereas when the ns selector is not > specified, pods in all namespaces will be selected. The alternative would be to select pods in all namespaces according to the pod selector and then all pods in the namespaces selected by the namespace selector.

We explicitly did not support defining a namespace selector and pod selector in the same “from” rule in order to avoid this.  At the moment, labels are only valid in a single namespace, so making them apply to other namespaces is not quite right.  At the moment it is an error on the API to specify both for the same rule.  If no “namespaces" is defined and “pods” is defined, then pods in the current namespace will be selected.  If no “pods” is defined and “namespaces” is defined, all pods in the selected namespaces will be allowed.  If both “pods” and “namespaces” are defined, it is an error.

I did neglect that "pods" and "namespace" selectors are mutually exclusive. In this case you explanation - which is also what Mike reports in his document - makes sense as one can have either an intra-namespace policy and a cross-namespace policy.

 

 If neither “pods” nor “namespaces” is defined, no sources are selected.

Which I guess means that any source can access the specified protocol/ports! Sorry for being pedant but "no source are selected" could be read as "no source ip will match the policy".

[Alex Pollitt]

Re “consensus”, there are a lot of comments on the egress document that I think it would be good to talk through in the SIG meeting this week if they aren’t resolved beforehand.  I.e. We shouldn’t lose those discussion points.   

--

[Casey Davenport]

> Which I guess means that any source can access the specified protocol/ports! Sorry for being pedant but "no source are selected" could be read as "no source ip will match the policy".

Sorry – should have been more clear! There are two cases to talk about here, and I believe this is what we agreed for each:

1. No “from” key is provided.  In this case, all sources can reach the specified ports / protocols.
2. A “from” key is provided with no selectors.  In this case, no sources can access the pod on any port or protocol.

Does that make sense?

[Salvatore Orlando]

On 11 April 2016 at 18:33, Casey Davenport <Casey.D...@metaswitch.com> wrote:

> Which I guess means that any source can access the specified protocol/ports! Sorry for being pedant but "no source are selected" could be read as "no source ip will match the policy".

Sorry – should have been more clear! There are two cases to talk about here, and I believe this is what we agreed for each:

1. No “from” key is provided.  In this case, all sources can reach the specified ports / protocols.
2. A “from” key is provided with no selectors.  In this case, no sources can access the pod on any port or protocol.

Does that make sense?

Yeah, it does.

I'd say that a from clause with no selectors is probably an API error, unless your goal is to create "drop all" policies.

Salvatore

[Mike Spreitzer]

Oh, I also had not noticed that Casey intended to forbid a from list element to have both a pod selector and a namespace selector.  I did not write that prohibition in my consolidation, I will update it to add that.  However, I think it is not necessary.  I thought it was obvious that the three possibilities for fields in a from list element (pods, namespaces, and cidr) combine by union NOT intersection.  One reason is that we explicitly did discuss and agree that the pod selector there can match ONLY pods in the same Namespace as the NetworkPolicy, while the namespace selector matches all pods in the selected namespaces.

BTW, I also think it is clear that writing an empty from list can NOT accomplish "drop all", since a NetworkPolicy can only add to what is allowed.  An empty from list simply means that the NetworkPolicy object in question adds nothing to the allowed ingresses.