Users should be able to specify to which namespaces their policies can apply to.

[mvladev]

Description

Right now end-users cannot specify in which namespaces their policies are deployed into.

User Story

End user creates network policy called foo which needs to deployed in namespaced labeled with foo-policy=enabled

[OPTIONAL] Implementation idea

Introduce a new resource called KarydiaNetworkPolicy which contains both NetworkPolicyTemplate and Namespace selector:

apiVersion: karydia.gardener.cloud/v1alpha1
kind: KarydiaNetworkPolicy
metadata:
  name: foo
spec:
  namespaceSelector: # LabelSelector https://github.com/kubernetes/api/blob/00c78f6603af046dfcada47ba511ddc94e7a64ce/admissionregistration/v1beta1/types.go#L193
    matchExpressions: 
    - key: foo-policy
      operator: In
      values:
      - enabled
  template: # PodSecurityPolicySpecification https://github.com/kubernetes/api/blob/61630f889b3c3efb8c3a4ba377da1a421d9ff6ce/networking/v1/types.go#L53
    podSelector: {}
    policyTypes:
    - Egress

Given that end-user has a namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: some-namespace
  labels:
    foo-policy: enabled

This should produce the following NetworkPolicy in namespace some-namespace:

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
  name: foo
  namespace: some-namespace
spec:
  podSelector: {}
  policyTypes:
  - Egress

[CodeClinch]

@mvladev I like your approach, but this would mean that a user has to label the namespace to get the policy. We would like to provide secure by default, which means even so the user forgets the label a network policy should be created. But may be we could at lease use a "black list" version.

[mvladev]

@CodeClinch if it should be applied to ALL namespaces than

spec:
  namespaceSelector: {}

can be used (it selects all namespaces) or

spec:
  matchExpressions: 
  - key: role
    operator: NotIn
    values:
    - system
    - logging

selecting all namespaces, except for those labeled with role=system or role=logging.

This frees the end-user to customize the behavior it wants to have on its cluster.

[CodeClinch]

@mvladev thank you for your explanation. The strategy should be:

• [ ] use kubebuilder
• [ ] Custom Resource with embedded type network policy
• [ ] Do not block if configuration is updated, reconcile later (additional annotation for default NP)

[mvladev]

The problem with #148 is that it applies the same network policy for ALL namespaces. There is no option to specify to which namespaces it applies to

[marcrahnsap]

The problem with #148 is that it applies the same network policy for ALL namespaces. There is no option to specify to which namespaces it applies to

We solved this problem with the annotation "karydia.gardener.cloud/networkPolicy". With that annotation you can specify the network policy on namespace level.

[mvladev]

We solved this problem with the annotation "karydia.gardener.cloud/networkPolicy". With that annotation you can specify the network policy on namespace level.

With this approach it's impossible to apply more than 1 Policy to a namespace:

https://github.com/karydia/karydia/blob/f20ce85803f60468132c449cb1eaba002b01ce27/pkg/controller/networkpolicy_reconciler.go#L327-L335

[marcrahnsap]

We did not consider such a scenario where a karydia user wants to apply more than one network policy to a specific namespace. @CodeClinch what do you think about this idea?

[CodeClinch]

We should check again. There will be no additional network policy possible.

[marcrahnsap]

We decided to apply only one network policy per namespace, which will be maintained by karydia.

[mvladev]

I wish you luck with the adoption then.

[dacappo]

No customers, no problems 😂

[CodeClinch]

Currently, we support only one network policy. It should be possible to reconcile multiple.

[Neumann-Nils]

Wanted to give a preview of the upcoming changes regarding multiple network policies.

We are going to support multiple network policies (see #241). One can define multiple network policies using a ;-separated syntax. For example:

karydia-default-network-policy;karydia-default-network-policy-l2;karydia-default-network-policy-l3

Moreover, one can specify which network policies should apply to which namespace by adding the karydia.gardener.cloud/networkPolicy annotation (using the same ;-separated syntax) to each namespace.

Surely, this implementation is different than the idea proposed by @mvladev. However, I believe that this is a rather simple solution to the problem and should fulfill all requirements. There are some advantages and disadvantages for both approaches.