|
| 1 | +--- |
| 2 | +title: KaaS Networking Standard |
| 3 | +type: Standard |
| 4 | +status: Draft |
| 5 | +track: KaaS |
| 6 | +--- |
| 7 | + |
| 8 | +## Introduction |
| 9 | + |
| 10 | +Kubernetes defines a networking model that needs to be implemented by a separate CNI plugin. |
| 11 | +Beyond basic connectivity within the cluster, however, there are many networking features that are specified but optional. |
| 12 | +Some of these optional features provide vital functionality, such as the NetworkPolicy API and the Ingress API. |
| 13 | + |
| 14 | +This standard specifies a minimal set of networking features that users can expect in clusters created by an SCS-compliant KaaS provider. |
| 15 | + |
| 16 | +## Terminology |
| 17 | + |
| 18 | +The following terms are used throughout this document: |
| 19 | + |
| 20 | +| Term | Meaning | |
| 21 | +|------|---------| |
| 22 | +| KaaS, managed Kubernetes | Kubernetes as a Service, automated on-demand deployment of Kubernetes clusters. | |
| 23 | +| CSP | Cloud Service Provider, the provider of the KaaS infrastructure. | |
| 24 | +| CNI | Container Network Interface, a standardized networking interface for container runtimes. | |
| 25 | +| CNI plugin, networking plugin | Kubernetes bindings for a CNI implementation, translates Kubernetes API concepts into more basic container networking concepts. | |
| 26 | +| network policy | A set of rules to restrict network traffic in a Kubernetes cluster. | |
| 27 | + |
| 28 | +## Motivation |
| 29 | + |
| 30 | +KaaS providers will typically support aditional networking functionality beyond basic Kubernetes networking. |
| 31 | +The specific range of features depends on the used CNI plugin, but may also be extended by additional operators. |
| 32 | +Users may expect certain optional functionality, so we should define a baseline feature set that has to be available in an SCS-compliant KaaS cluster. |
| 33 | + |
| 34 | +## Design Considerations |
| 35 | + |
| 36 | +The Kubernetes API can be extended arbitrarily. |
| 37 | +Many CNI plugins will define custom resources to enable functionality that is not covered in the official [API specification](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/). |
| 38 | +Sometimes they will even reuse names from different API groups, such as `NetworkPolicy`, which exists in the basic `networking.k8s.io/v1` API, but also in `projectcalico.org/v3`. |
| 39 | + |
| 40 | +To avoid any ambiguity, we should therefore be explicit about the API groups and versions of resources. |
| 41 | +We should also avoid mandating third-party API extensions, to avoid dependencies on specific third-party software and keep the standard as generic as possible. |
| 42 | + |
| 43 | +### Options considered |
| 44 | + |
| 45 | +#### NetworkPolicy API |
| 46 | + |
| 47 | +Kubernetes network policies are used to restrict network traffic between pods in a cluster, but also between pods and external network resources. |
| 48 | +The policy rules can filter based on port and address ranges, but also on Kubernetes-specific target attributes such as namespaces and labels. |
| 49 | +They must be implemented by the CNI plugin, and though they are widely supported, they are still technically optional, and there are some lightweight networking plugins, such as Flannel, that are not enforcing them. |
| 50 | + |
| 51 | +Nonetheless, network policies are widely used and most users will expect them in a managed Kubernetes cluster. |
| 52 | +The wide, but varying support among CNI plugins makes them a good target for SCS standardization. |
| 53 | + |
| 54 | +#### Default Network Policies in Namespaces |
| 55 | + |
| 56 | +Basic network policies are namespaced resources, and can only filter traffic to and from pods in their own namespace. |
| 57 | +In a newly created namespace without policies the default behavior will apply, which is to not restrict traffic at all. |
| 58 | + |
| 59 | +It can be desirable to automatically create default network policies in new namespaces, using a policy operator such as Kyverno. |
| 60 | +A CSP could provide such an operator and offer a number of default policies, like blocking connections to other namespaces by default, or blocking access to the OpenStack metadata service. |
| 61 | + |
| 62 | +Any user with permissions to manage their own network policies in a namespace will of course be able to remove or modify any default network policies in that namespace. |
| 63 | +CSP-provided network policies should thus only be viewed as a safety default, and should only be deployed if they are actually beneficial to users. |
| 64 | + |
| 65 | +#### AdminNetworkPolicy API |
| 66 | + |
| 67 | +An alternative to automatically created default network policies are API extensions that allow cluster-wide networking rules. |
| 68 | +Some CNI plugins have implemented such extensions, e.g. Calico's `GlobalNetworkPolicy` and Cilium's `CiliumClusterwideNetworkPolicy`. |
| 69 | + |
| 70 | +The Kubernetes Network Special Interest Group is currently working on an [official API extension](https://network-policy-api.sigs.k8s.io/api-overview/) to cover this functionality. |
| 71 | +This API extension introduces the new `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources, which represent cluster-wide network policies with respectively higher or lower precedence than namespaced network policies. |
| 72 | + |
| 73 | +This API is also a good candidate for standardization because it consolidates a number of vendor-specific workarounds to limitations of the NetworkPolicy API. |
| 74 | +It has not been stabilized yet, so currently we can at most recommend CNI plugins where there is ongoing work to support these features. |
| 75 | + |
| 76 | +#### Ingress API |
| 77 | + |
| 78 | +The Ingress API allows the external exposure of HTTP/HTTPS-based services running in the cluster. |
| 79 | +Unlike the L3/L4-based LoadBalancer Service type, Ingress provides L7 load balancing, HTTP routing, and TLS termination for services. |
| 80 | +This functionality can be provided within the cluster by a pod-based ingress controller such as `ingress-nginx`, that exposes Ingress resources as Services. |
| 81 | + |
| 82 | +However, there are also Ingress controllers that integrate with underlying infrastructure and may help to reduce overhead. |
| 83 | +Examples for this are the Cilium CNI plugin, which comes with built-in Ingress support, and the Octavia Ingress controller, which may be a good choice if OpenStack Octavia is already used to provide L3/L4 load balancing. |
| 84 | + |
| 85 | +The CSPs that manage the underlying infrastructure can of course make the best choice for such an integrated Ingress controller, so they should be encouraged to do so. |
| 86 | +Even with a CSP-provided default Ingress controller present, users will be able to use alternative Ingress controllers by creating a new `IngressClass`, which can then be referenced in Ingress resources. |
| 87 | + |
| 88 | +## Decision |
| 89 | + |
| 90 | +CSPs MUST provide a network plugin that fully supports `NetworkPolicy` resources in the API version `networking.k8s.io/v1`. |
| 91 | +CSPs SHOULD provide a network plugin that supports or is working on support for the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources of the `policy.networking.k8s.io` API group, in their latest version, up to `v1`. |
| 92 | + |
| 93 | +CSPs SHOULD offer the option for a managed, `networking.k8s.io/v1`-compliant Ingress controller and a default `IngressClass` resource for this controller. |
| 94 | + |
| 95 | +CSPs MAY add default networking restrictions, using either `networking.k8s.io/v1`-compliant `NetworkPolicy` resources with a policy operator, or alternatively any cluster-wide network policy extensions provided by the CNI plugin. |
| 96 | + |
| 97 | +## Conformance Tests |
| 98 | + |
| 99 | +Required support for network policies will be tested using the upstream e2e tests via Sonobuoy. |
0 commit comments