From e427efc4c5512aae6ef27f0bcfc2f0f6e917177b Mon Sep 17 00:00:00 2001 From: Nadia Pinaeva Date: Thu, 20 Jul 2023 13:20:05 +0200 Subject: [PATCH] Add enhancement proposal for external ingress endpoints. Signed-off-by: Nadia Pinaeva --- npep/npep-127.md | 88 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 npep/npep-127.md diff --git a/npep/npep-127.md b/npep/npep-127.md new file mode 100644 index 00000000..7ce99444 --- /dev/null +++ b/npep/npep-127.md @@ -0,0 +1,88 @@ +# NPEP-127: Add southbound traffic support in (B)ANP API + +* Issue: [#127](https://github.com/kubernetes-sigs/network-policy-api/issues/127) +* Status: Provisional + +## TLDR + +This NPEP proposes adding support for cluster ingress (southbound) traffic control in the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` API objects. + +## Goals + +* Implement ingress traffic control from external destinations (outside the cluster) + +## Non-Goals + +(What is out of scope for this proposal.) + +## Introduction + +Currently, (B)ANP only allows to specify [peers](https://github.com/kubernetes-sigs/network-policy-api/blob/46be90096f23934f56342bc408b94a1aa79a159c/apis/v1alpha1/shared_types.go#L98-L103) +based on pod and namespace selector, that will only apply to non-hostNetwork cluster pods. This enhancement aims to +add more types of incoming connections that may be specified. A similar effort exists for the [egress](https://github.com/kubernetes-sigs/network-policy-api/issues/126) +direction. + +By default, cluster workloads are not accessible from outside the cluster, but there are many ways to expose these workloads +(either with k8s APIs like [Ingress API](https://kubernetes.io/docs/concepts/services-networking/ingress/) or +[Gateway API](https://gateway-api.sigs.k8s.io/), or with downstream implementations, +like [openshift Route](https://docs.openshift.com/container-platform/4.13/rest_api/network_apis/route-route-openshift-io-v1.html)). +Some of the APIs may provide functionality to filter incoming connections, but Network Policy API is different, because +it is applied to the cluster workloads, and should provide the required level of security regardless of how/if a cluster workload +is exposed to the outer world. + +### Use cases + - zero trust policy: As a cluster administrator I want to set up default deny all ingress policy as a BANP. + + Example: when implementing a zero trust policy I want to make sure no ingress connection (unless explicitly allowed) will +get to the cluster workloads. This should apply not only to the connections coming from the other cluster workloads, but to +all incoming connections. + + - block well-known ports: As a cluster administrator I want to block all ingress traffic on specific ports. + + Example: when defining a cluster security policy, we decided that some well-known services like ftp, telnet, SNMP, etc. +should not be allowed for cluster workloads. To implement this policy I want to explicitly deny all ingress connections +for TCP ports 21, 23, 161, etc. + + - compromised node protection: As a cluster administrator I want to make sure a compromised node can't send traffic to the +cluster workloads scheduled on the other nodes. + + Example: my cluster has a set of nodes with very sensitive workloads, I want to make sure that if a worker node A is +compromised, it will not be able to affect other worker nodes. To do so, I want to create a cluster-wide policy to +deny ingress connections from some of the cluster nodes. I may also need to explicitly allow access from the control plane nodes. + + - inter-cluster communication: As a cluster manager for multiple clusters I want to make sure ingress connections +are only allowed from a pre-defined set of related clusters, which are identified by their network CIDR. + + Example: I have a cluster (management cluster) that creates other clusters on request (hosted clusters). +Management cluster assigns a subnet for hosted cluster workloads. I want to make sure that hosted cluster workloads +have limited access to the management cluster workloads by selecting management cluster workloads I want to protect +and a set of allowed subnets for the corresponding hosted clusters. + +- external services: As a cluster manager I want to make sure ingress connections from a pre-defined set of external endpoints +can't be denied by the namespace owners. + + Example: I have an external service to collect telemetry and metrics from multiple clusters, and I want to make sure +namespaced Network Policies won't drop incoming connections from this service. + +## API + +(... details, can point to PR with changes) + +## Conformance Details + +(This section describes the names to be used for the feature or +features in conformance tests and profiles. + +These should be `CamelCase` names that specify the feature as +precisely as possible, and are particularly important for +Extended features, since they may be surfaced to users.) + +## Alternatives + +(List other design alternatives and why we did not go in that +direction) + +## References + +(Add any additional document links. Again, we should try to avoid +too much content not in version control to avoid broken links)