Restructure and extend design considerations

Signed-off-by: Konrad Gube <[email protected]>

Author: kgube

Standards/scs-XXXX-v1-kaas-networking.md

@@ -35,46 +35,44 @@ We should also be explicit about the required versions of the APIs.
 
 #### NetworkPolicy API
 
-Kubernetes network policies allow the restrict network traffic within a cluster based on labels and namespaces.
-They must be implemented by the CNI plugin of the cluster and are technically optional, though they are few CNI plugins that do not support them.
+Kubernetes network policies can restrict network traffic within a cluster based on labels and namespaces.
+They must be implemented by the CNI plugin of the cluster and are technically optional, though the majority of CNI plugins support them.
 
-Network policies are an important security feature that allows a separation of components and namespaces on a network level.
+Network policies are an important and widely used security feature, and the existing wide support among CNI plugins makes them a good target for SCS standardization.
 
-- already defacto standard, will be expected by many users, so we should make it explicit
-
-#### AdminNetworkPolicy API
+#### Default Network Policies in Namespaces
 
 Basic network policies are always bound to a namespace, and only affect connections to and from pods within this namespace.
-Restricting certain traffic within the whole cluster requires a policy to be replicated across all namespaces.
-There are operators, such as Kyverno, that can handle this replication automatically and will also create policies for newly created namespaces.
+Without them, pods are reachable by any other pod in the cluster and also can connect to any external address.
+
+Automatically creating default network policies in new namespaces can be desirable but requires an operator such as Kyverno.
+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.
 
-Some CNI plugins have implemented their own extensions for cluster-wide networking rules, such as Calico's `GlobalNetworkPolicy` and Cilium's `CiliumClusterwideNetworkPolicy`.
-The Kubernetes Network Policy Special Interest Group is currently working on an official API extension to cover this functionality.
+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.
+CSP-provided network policies should therefore only be viewed as a safety default, and should only be deployed if they are actually beneficial to users.
+
+#### AdminNetworkPolicy API
 
-- AdminNetworkPolicy replaces CNI-specific APIs
-- we can not mandate this until it is stable
-- could be required in a future version of this standard
-- we can recomend CNIs that are already working on support
+An alternative to automatically created default network policies are API extensions that allow cluster-wide networking rules.
+Some CNI plugins have implemented such extensions, e.g. Calico's `GlobalNetworkPolicy` and Cilium's `CiliumClusterwideNetworkPolicy`.
 
-#### Default Network Policies in Cluster
+The Kubernetes Network Policy Special Interest Group is currently working on an official API extension to cover this functionality [^adminnetpol].
+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.
 
-- providing defaults is possible even without AdminNetworkPolicy by either operator or CNI-specifics
-- what are useful defaults?
-- is there actually a demand for CSP-set defaults?
+This API is also a good candidate for standardization because it consolidates a number of vendor-specific workarounds to limitations of the NetworkPolicy API.
+It has not been stabilized yet, so currently we can at most recommend CNI plugins where there is ongoing work to support this feature.
 
 #### Ingress API
 
-The Ingress API allows the external exposure of HTTP(S)-based services running in the cluster.
+The Ingress API allows the external exposure of HTTP/HTTPS-based services running in the cluster.
 Unlike the L3/L4-based LoadBalancer Service type, Ingress provides L7 load balancing, HTTP routing, and TLS termination for services.
 This functionality can be provided within the cluster by a pod-based ingress controller such as `ingress-nginx`, that is itself exposed as a Service.
 
-However, there are also Ingress controllers that integrate with the underlying infrastructure and may reduce some overhead.
-Examples for this are the Cilium CNI plugin, which comes with bhuilt-in Ingress support, and the Octavia ingress controller, which might be a good choice if OpenStack Octavia is already used to provide Service load balancing.
+However, there are also Ingress controllers that integrate with underlying infrastructure and may help to reduce overhead.
+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.
 
-- Ingress controllers seem to be regularly requested by managed k8s users
-- managed ingress controller may have better integration in infrastructure
-- some users may prefer to deploy their own ingress controllers, e.g. if they have additional requirements such as the gateway API
-- CSPs could offer option to set up ingress controller
+The choice for such an externally integrated Ingress controller can of course be best made by the CSP that manages the underlying infrastructure.
+While some users may still want to deploy their own ingress controller, many will also use a CSP-provided one if available.
 
 ### Open questions