allow fine-grained source/destination selection

[sebhoss]

We are currently re-working our network policies by introducing GlobalNetworkSets. We have labeled each network set with something like networking.our.internal.stuff/networkset: <name> to be able to select a single network set in our network policies. We are concerned that someone accidentally adds the same label to a pod or another resource and thus undermines our network policies.

Expected Behavior

It would be cool if something similar to projectcalico.org/orchestrator exists that lets us specify the resource type we want to select.

Current Behavior

We can use global() to select across all global resources, but cannot limit this to just GlobalNetworkSets. We can use an external policy agent, like OPA or kyverno, to disallow setting our networkset labels on resources that are not network sets but this requires an additional system to be deployed.

Possible Solution

Calico could automatically add a new label, e.g. projectcalico.org/kind to each calico resource so that we can select resources by kind and their labels within the same selector. In our case, we could write a selector like networking.our.internal.stuff/networkset == "some-name" && projectcalico.org/kind == "GlobalNetworkSet"

Another solution would be something like a kind(GlobalNetworkSet) expression that does the same, but does not require an extra label.

Context

We want to be as strict as possible in our network policies and close any potential loophole that might exist in our setup.

[fasaxc]

I think this would be a good feature to have (given that we didn't split selector by type in the first place).

Note that k8s now has built in support for label validation/RBAC via the validating admission policy resource.

[sebhoss]

Another issue with the current approach: GlobalNetworkSets are global by nature and thus their names are unique. Their labels are not. It is possible to add the same label to two different network sets potentially allowing much more than expected. Something like kind(GlobalNetworkSet) && name(Something) as an expression would perfectly express what we want without allowing any potential misconfiguration.

Again, we can work around this using additional tooling (VAP/OPA/Kyverno) that verifies that the value of our networking.our.internal.stuff/networkset label exactly matches the name of a global network set, but built-in support for more precision when declaring network policies would be really nice!

[ivnhk]

Hey guys,

I'd love to try and work on this one. Do you have a general advice where I should start with this?

[caseydavenport]

Thanks @ivnhk !

I'd start by familiarizing yourself with how to build and run Calico and its tests. There's a general contribution guide here: https://github.com/projectcalico/calico/blob/master/CONTRIBUTING.md (although I'll admit, it might be a tad out of date...)

You might also want to poke around to see how the (very similar) orchestrator label is handled for kubernetes pods. Here's a hint:

calico/libcalico-go/lib/backend/k8s/conversion/workload_endpoint_default.go

Line 163 in f3da524

labels[apiv3.LabelOrchestrator] = apiv3.OrchestratorKubernetes

We convert pods into an internal type called "WorkloadEndpoint" and when we do, we force a label to be set on it for selection.

For NetworkSets, you could probably do something similar - or even better since it's an API that we control, you could also add it to the defaulting and validation code for that API - here are some hints on that part:

• https://github.com/projectcalico/calico/blob/master/libcalico-go/lib/clientv3/networkset.go

• calico/libcalico-go/lib/validator/v3/validator.go

  Lines 269 to 270 in f3da524

  	registerStructValidator(validate, validateGlobalNetworkSet, api.GlobalNetworkSet{})
  	registerStructValidator(validate, validateNetworkSet, api.NetworkSet{})