Initial FQDN Selector NPEP with User stories

Author: rahulkjoshi

npep/npep-133.md

@@ -0,0 +1,89 @@
+# NPEP-133: FQDN Selector for Egress Traffic
+
+* Issue:
+  [#133](https://github.com/kubernetes-sigs/network-policy-api/issues/133)
+* Status: Provisional
+
+## TLDR
+
+This enhancement proposes adding a new selector to specify egress peers using
+Fully Qualified Domain Names (FQDNs). 
+
+## Goals
+
+* Provide a selector to specify egress peers using a Fully Qualified Domain Name
+  (for example `kubernetes.io`).
+* Support a restricted set of regex matching capabilities when specifying FQDNs. 
+
+## Non-Goals
+
+* This enhancement does not include a FQDN selector for allowing ingress
+  traffic.
+* This enhancement does not include any L7 matching or filtering capabilities,
+  like matching HTTP traffic or URL paths.
+    * This selector should not control what DNS records are resolvable from a
+      particular workload.
+* This enhancement does not provide a mechanism for selecting in-cluster
+  endpoints using FQDNs. This is explicitly disallowed by the spec.
+    * To select Pods, Nodes, API Server, AdminNetworkPolicy has more first party
+      selector with better UX.
+* This enhancement does not specify the details of how traffic is routed to the
+  specified destination. For example, it does not prescribe details around NAT
+  or egress gateways.
+* This enhancement does not require a particular mechanism for securing DNS
+  resolution (e.g. DNSSEC or DNS-over-TLS).
+    * TODO: Is this up to implementations? Maybe an optional enum describing
+      what security mechanims to use and providers can chose whther to support
+      or not.
+
+## Introduction
+
+FQDN-based egress controls are a common enterprise security practice.
+Administrators often prefer to write security policies using DNS names such as
+“www.kubernetes.io” instead of capturing all the IP addresses the DNS name might
+resolve to. Keeping up with changing IP addresses is a maintenance burden, and
+hampers the readability of the network policies.
+
+## User Stories
+
+* As a cluster admin, I want to allow certain workloads to send traffic to a
+  service specified by a well-known domain name (e.g. on-prem logging service)
+* As a cluster admin, I want to allow the cluster to communitcate with services
+  provided by a Cloud provider by allowing their whole domain.
+
+## API
+
+TODO
+
+## Alternatives
+
+### IP Block Selector
+
+IP blocks are an important tool for specifying Network Policies. However, they
+do not address all user needs and have a few short-comings when compared to FQDN
+selectors:
+
+* IP-based selectors can become verbose if a single logical service has numerous
+  IPs backing it.
+* IP-based selectors pose an ongoing maintanance burden for administrators, who
+  need to be aware of changing IPs.
+* IP-based selectors can result in policies that are difficult to read and
+  audit.
+
+### L7 Policy
+
+Another alternative is to provide a true L7 selector, similar to the policies
+provided by Service Mesh providers. While L7 selectors can offer more
+expressibility, they often come trade-offs that are not suitable for all users:
+
+* L7 selectors necessarily support a select set of protocols. Customers may be
+  using a custom protocol for application-level communication, but still want
+  the ability to specify endpoints using DNS.
+* L7 selectors often require proxies to perform deep packet inspection and
+  enforce the policies. These proxies can introduce un-desireable latencies in
+  the datapath of applications.
+
+## References
+
+* [NPEP #126](https://github.com/kubernetes-sigs/network-policy-api/issues/126):
+  Egress Control in ANP