Filter for in- and outgoing network traffic

[ThormaehlenFred]

Description

Filter for in- and outgoing network traffic as configurable Karydia feature

User Story

As Kubernetes cluster owner I want to prevent applications and users from reaching remote hosts or from being reached by remote hosts in order to mitigating DDoS attacks, avoiding SPAM, blocking access to or from services for specific geographic regions and so on.

Implementation Idea

This kind of filtering is discussed in the Kubernetes community already in recent blog postings (see Performance Benchmark Analysis of Egress Filtering on Linux and BPF Isn't Just About Speed.
The idea is that one or more Reputation Block Lists are received via HTTPS and a REST based API and are transformed in Cilium or other technology based network filters.

[alban]

Does this REST based API already exist or does it need to be designed? If it exists, it would be good to see documentation with the endpoints, the input/output formats, authentication, whether there is pagination.

Possible list of tasks:

• Update CRD KarydiaConfig (scope: cluster) with additional parameters:
  • enable-block-lists=true
  • block-list-sources=http://rest.example.com/mylist.txt
  • block-list-update-interval=1h (https://golang.org/pkg/time/#ParseDuration)
  • block-list-auth=user/password
  • block-list-output={calico,cilium}
• Implement a new controller for the block lists:
  • Download the block lists regularly via the REST API.
  • Apply the relevant CRDs:
    • Calico: GlobalNetworkSet, GlobalNetworkPolicy
    • Cilium: CiliumNetworkPolicy, CiliumClusterWideNetworkPolicy
  • Whenever the KarydiaConfig changes, an update is scheduled immediately
• Tests
  • Mock REST API server providing the CIDR list
  • Manual functional tests: check that the policy is enforced correctly
    • Connectivity from a pod with networkHost=true (or from the host)
    • Connectivity from a pod with networkHost=false
  • Automatic tests: Karydia has e2e tests (tests/e2e directory) but it does not seem to be integrated in a CI pipeline (.ci directory empty). We can add more e2e tests for this feature.
  • Scalability tests
• Documentation

[CodeClinch]

The authentication information should be stored in the secure store.

[ThormaehlenFred]

Hello @alban there might be two parts:

1. generic part which helps vanilla K8s clusters via own configuration to do the filtering
2. Gardener specific part which provides Gardener managed K8s clusters a central (company) defined configuration which can be consumed by the first part