Lokomotive: Network policies: namespaces (kube-system, etc.) should have labels

[alban]

Currently, namespaces in Lokomotive don't have labels:

$ kubectl get ns --show-labels
NAME              STATUS   AGE   LABELS
default           Active   42m   <none>
kube-node-lease   Active   42m   <none>
kube-public       Active   42m   <none>
kube-system       Active   42m   <none>
projectcontour    Active   41m   <none>

This makes it difficult for users to write network policies for cross-namespace communication. A common example is a network policy allowing egress traffic to coredns in the kube-system namespace.

Examples in other projects:

• In the Calico documentation, the "Allow DNS egress traffic" section suggests to add the name=kube-system label with kubectl label namespace kube-system name=kube-system in order to use this namespace selector in network policies:

    - namespaceSelector:
        matchLabels:
          name: kube-system

• The Gardener project uses the label role=kube-system: see the network policy for the nginx controller in the kube-system namespace

    - namespaceSelector:
        matchLabels:
          role: kube-system
      podSelector:
        matchLabels:
          app: nginx-ingress
          component: controller

• Or this network policy for accessing kube-dns or coredns:

    - namespaceSelector:
        matchLabels:
          role: kube-system
      podSelector:
        matchExpressions:
        - {key: k8s-app, operator: In, values: [kube-dns,coredns]}

We should add labels for namespaces in Lokomotive in order to:

• make it easier for users to create their network policies without patching the kube-system and other namespaces.
• make it possible to add Lokomotive components with additional network policies that would handle cross-namespace communication.
• make it possible for Inspektor Gadget's Network Policy Advisor to suggest more correct cross-namespace network policies. In https://github.com/kinvolk/inspektor-gadget/pull/42, I currently just assume that the "name" label exists.

[surajssd]

So which labelling scheme are you suggesting here name= or role=?

[invidian]

In some of my projects, I used the following approach:

apiVersion: v1
kind: Namespace
metadata:
  name: kube-system
  labels:
    name: kube-system

However... We need a solution, which will allow to automatically apply and update such labels. Maybe crds directory from Helm would be capable of doing that.

[invidian]

See also https://github.com/kubernetes/kubernetes/issues/88253

[thockin]

Please note that un-scoped label and annotation keys (e.g. "name" rather than "kinvolk.io/name") are reserved for end-users.

[ipochi]

Can we have a consensus on the labeling scheme ? This issue I believe is a prerequisite to #315 ?

[ipochi]

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#label-selector-and-annotation-conventions

Excerpt:

In early versions of Kubernetes, some in-development features represented new
API fields as annotations, generally with the form `something.alpha.kubernetes.io/name` or
`something.beta.kubernetes.io/name` (depending on our confidence in it). This
pattern is deprecated.  Some such annotations may still exist, but no new
annotations may be defined.  New API fields are now developed as regular fields.

Other advice regarding use of labels, annotations, taints, and other generic map keys by
Kubernetes components and tools:
  - Key names should be all lowercase, with words separated by dashes instead of camelCase
    - For instance, prefer `foo.kubernetes.io/foo-bar` over `foo.kubernetes.io/fooBar`, prefer
    `desired-replicas` over `DesiredReplicas`
  - Unprefixed keys are reserved for end-users.  All other labels and annotations must be prefixed.
  - Key prefixes under "kubernetes.io" and "k8s.io" are reserved for the Kubernetes
    project.
    - Such keys are effectively part of the kubernetes API and may be subject
      to deprecation and compatibility policies. 
  - Key names, including prefixes, should be precise enough that a user could
    plausibly understand where it came from and what it is for.
  - Key prefixes should carry as much context as possible.
    - For instance, prefer `subsystem.kubernetes.io/parameter` over `kubernetes.io/subsystem-parameter`
  - Use annotations to store API extensions that the controller responsible for
the resource doesn't need to know about, experimental fields that aren't
intended to be generally used API fields, etc. Beware that annotations aren't
automatically handled by the API conversion machinery.

[knrt10]

labeling scheme should be kinvolk.io/name AFAIT after reading above comment. It should be reserved for lokomotive project

[iaguis]

We're already using lokomotive.alpha.kinvolk.io/public-ipv4 to label nodes with their public IP. This follows the recommendations above AFAICT so we can just use that.

We could consider removing the alpha subdomain if that's not recommended anymore but I think the lokomotive subdomain makes sense in this case.

[knrt10]

If anyone is not working, I can take up this issue

[surajssd]

@knrt10 Imran is working on this. This is precursor to the work of adding NetworkPolicies to the Lokomotive.