136 lines
3.1 KiB
Markdown
136 lines
3.1 KiB
Markdown
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|