Gather use cases for service accounts as selectors

Signed-off-by: Surya Seetharaman <[email protected]>

Author: tssurya

npeps/npep-173-service-account-matches.md

@@ -0,0 +1,51 @@
+# NPEP-173: NPEP template
+
+* Issue: [#173](https://github.com/kubernetes-sigs/network-policy-api/issues/173)
+* Status: Provisional
+
+## TLDR
+
+Ability to express subjects and peers in (Baseline)AdminNetworkPolicy API
+using [Kubernetes service accounts](https://kubernetes.io/docs/concepts/security/service-accounts/).
+
+## Goals
+
+* Implement service account as a way to select pods in the policy's subject
+* Implement service account as a way to select pods in the policy's peers
+
+## Non-Goals
+
+* There might be other identity management constructs like SPIFFE IDs which are outside the scope of this enhancement. We can only provide a way to select constructs known to core Kubernetes.
+
+## Introduction
+
+Every pod in Kubernetes will have an associated service account. If user does not explicitly provide a service account, a default service account is created in the namespace. A given pod will always have 1 service account associated with itself. So instead of using pod labels as a way of selecting pods sometimes there might be use cases to use service accounts as a way of selecting the pods. This NPEP tries to capture the design details for service accounts as selectors for policies.
+
+## User-Stories/Use-Cases
+
+1. **As a** cluster admin **I want** to select pods using their service accounts instead of labels **so that** I can avoid having to setup webhooks and validation admission policies to prevent users from changing labels on their namespaces and pods that will make my policy start/stop matching the traffic which is undesired
+2. **As a** cluster admin **I want** to select pods using their service accounts instead of labels **so that** I can avoid the scale impact caused due to mutation of pod/namespace labels that will cause a churn which makes my CNI implementation react to that every time user changes a label.
+3. **As a** cluster admin **I want** to select pods using their service accounts instead of labels **since** I want to have eventual consistency of that policy in the cluster. I don't have a use case for dynamic selection of workloads and want to use service accounts instead of labels for that very same reason
+
+## 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)