Network policy and (later) linkerd policy generator.

Basic idea:

1. The kubernetes clusters hosts applications
2. Applications communicate to other applications

Allowed communication betwen applications is configured as follows:

communication:

• from: app1 to: app2 ports:
  • 80
  • linkerd-admin

Ports are optional. When omitted all ports are intended

There are pre-defined applications such as api-server. Beyond that thera are two types of applications:

• cidr: a cidr with possible except clauses following netpol syntax
• app: regular app based on matchLabels, together with namespace name.

Application names must be unique.

There are also standard capablities for an application such as:

• linkerd: addes egress to linkerd-jaeger, egress to linkerd, ingress from linkerd-viz

capablities can also be defined at the namespace level, which means they apply to each pod in the namespace.

networks:

• name: internet cidr: 0.0.0.0/0 except:
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

namespaces:

• namespace: wamblee-org capabilities:

  • linkerd applications:
  • name: nexus-server

    ports when specified at the application level are used when

    not explicitly mentioned when a link is made

    ports:
    • 8081
    • 8082 matchLabels: app: nexus-server

• namespace: exposure applications:

  • name: httpd-wamblee-org matchLabels: app: wamblee-org

communications:

• from: # can we support both string and list of strings?
  • httpd-wamblee-org to:
  • nexus-server
  • wamblee-static
  • wamblee-safe

or limiting ports further

• from:
  • httpd-wamblee-org to:
  • nexus-server porst:
  • 8081
  • 8082

Handling of capabilities:

1. capabilities at namespace level is defined a template that gets the namespace name.

   Ingress template

   from: - linkerd-viz to: - {{ application }}

   egress template

   from: - {{ application }} to: - linkerd-jaeger - linkerd

   The templates are evaluated for an application and then parsed, and added to the allowed communications.

Linkerd extension:

• for each application an optional service account is defined, when not defined, 'default' is assumed.
• together with the communication links this determines the authorization policies.

Technical realization could be in the form of go templates where the input the template is:

1. map of app name to definition with for each app also a list of capabilities.
2. a single app config with for each app
   • all ingresses
   • all egresses

Similar and easier technical solution via interface with a network policy implementation and a linkerd implementation.

Then we can have:

1. networkpolicy templates
2. server, meshtls, networkauthentication, authorization policy
   • when linkerd capability for both pods, the tool can generated a meshtlsauthentication, when the target pods does not have linkerd capability, it can be ignored.