brainstorming a CRD

[jayunit100]

Mostly thinking out loud, but want to start a thread around a CRD that would be able to generate (i.e. via an operator) v1 downstream networkpolicies.

Roughly, I think something like this would integrate many of the things people have asked for thus far.

NetpolExtended {
    Spec:
        Scope:
            AllNamespaces: true/false
            AllNamespacesRegex: true/false
            IncludedNamespaces: (labels)
            // ^ Pick one
        PortSpec:
            Range: min,max
            []Ports:
            Port
            // ^ Pick one, either a 
        NodeSelectorSpec:
             matchLabels
            // will allow traffic to all nodes in this sector
        ServiceSelectorSpec:
            // will allow traffic to pods in services of this selector
            matchLabels
        NamespacesSelectorSpec:
            // will allow all traffic to all namespaces in this selector
            matchLabels
        K8sDefaultService: true
        KubeDNSService: true
   Status:
        List[Pod,Pod] ConnectedViaNetworkPolicy
        List[Pod,Pod] ConnectedViaClusterlPolicy
}

Note i haven't at all thought about cardinality here, no clue wether or not this would work as is .

[jayunit100]

Some other sane defaults to add which were requested, which seem easy ... access to k8s default service and kubedns, which i think can easily just be done by getting the 1st service ip / slurping up the coredns labels

    K8sDefaultService: true
    KubeDNSService: true

[rikatz]

Here:

            AllNamespaces: true/false
            AllNamespacesRegex: true/false
            IncludedNamespaces: (labels)

what about having two fields: one with the match behavior (exactly or regex) and the other one with the properly regex and/or the field.

As an example:

matchNamespace: regex
namespaceSelector:
  name: "*" # This can be one selector, and here  

or

matchNamespace: label
namespaceSelector:
  labels: 
    protected: true

EDIT: Also, this could be used maybe in a group. Like, can I have a selector that allow both a regex name + a label selector. Imagine the case where you want a double validation, if the name is inside the regex AND the namespace gots the desired label. This way you can have a standard namespace naming but can isolate a namespace if something bad happens (removing its label)

[rikatz]

I like the idea of using booleans for allowing/denying the access to k8services and k8sdns, just wondering how this turns into a deny rule if you say "no" and someone puts a rule there that allow this. Will the controller remove offending policies?

[jayunit100]

deny rules might be another issue we can add in next iteration. If you dont see any major dysfunction, i think maybe ill commit that file as a v0 of a potential CRD and we can iterate via PR's on the file?

[rikatz]

Yeah sure.

I’ve asked about the deny thing mostly because of the boolean k8sapiaccess, etc. can evolve this in a later PR

Em dom., 23 de ago. de 2020 às 18:44, jay vyas notifications@github.com escreveu:

deny rules might be another issue we can add in next iteration. If you dont see any major dysfunction, i think maybe ill commit that file as a v0 of a potential CRD and we can iterate via PR's on the file?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jayunit100/network-policy-subproject/issues/8#issuecomment-678828803, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWZQBMTKJ7WFUUDF5QXBQLSCGEVVANCNFSM4QIXKCKQ .

[jayunit100]

:)

[jayunit100]

ok, commited to master. We can keep this issue open until we feel like were close to an implementation that might cover a good 75% of the cases were interested in

[jayunit100]

now that we have this in master and Matts repo mattfenwick/kube-prototypes is up (https://github.com/mattfenwick/kube-prototypes/tree/master/pkg/netpol/crd) we can follow on in PRs