Skip to content

Commit c53903f

Browse files
tssuryatssurya
committed
Gather use cases for service accounts as selectors
Signed-off-by: Surya Seetharaman <[email protected]>
1 parent 825ded8 commit c53903f

File tree

2 files changed

+198
-0
lines changed

2 files changed

+198
-0
lines changed

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

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# NPEP-173: NPEP template
2+
3+
* Issue: [#173](https://github.com/kubernetes-sigs/network-policy-api/issues/173)
4+
* Status: Provisional
5+
6+
## TLDR
7+
8+
Ability to create policies that control network traffic based on workload identities a.ka.
9+
[Kubernetes service accounts](https://kubernetes.io/docs/concepts/security/service-accounts/).
10+
11+
## Goals
12+
13+
* Use service accounts (identities) as a way of describing (admin) network policies for pods
14+
15+
## Non-Goals
16+
17+
* There might be other identity management constructs like SPIFFE IDs which
18+
are outside the scope of this enhancement. We can only provide a way to select
19+
constructs known to core Kubernetes.
20+
21+
## Introduction
22+
23+
Every pod in Kubernetes will have an associated service account. If user does
24+
not explicitly provide a service account, a default service account is created
25+
in the namespace. A given pod will always have 1 service account associated
26+
with itself. So instead of using pod labels as a way of selecting pods sometimes
27+
there might be use cases to use service accounts as a way of selecting the pods.
28+
This NPEP tries to capture the design details for service accounts as selectors
29+
for policies.
30+
31+
## User-Stories/Use-Cases
32+
33+
1. **As a** cluster admin **I want** to select pods using their service accounts
34+
instead of labels **so that** I can avoid having to setup webhooks and
35+
validation admission policies to prevent users from changing labels on their
36+
namespaces and pods that will make my policy start/stop matching the traffic
37+
which is undesired
38+
2. **As a** cluster admin **I want** to select pods using their service accounts
39+
instead of labels **so that** I can avoid the scale impact caused due to
40+
mutation of pod/namespace labels that will cause a churn which makes my CNI
41+
implementation react to that every time user changes a label.
42+
3. **As a** cluster admin my workloads have immutable identities and **I want**
43+
to apply policies per workloads using their service accounts instead of labels
44+
**since** I want to have eventual consistency of that policy in the cluster.
45+
46+
## Unresolved Discussions
47+
48+
* How to provide a standard way to configure/describe the service mesh behavior
49+
of intercepting traffic and deciding whether to allow it based on information
50+
in the TLS packets?
51+
* NetworkPolicies apply on L3 and L4 while Meshes operate at L7 mostly. So when
52+
trying to express "denyAll connections except the allowed serviceAccount to
53+
serviceAccount connections"; how do we split the enforcement in this scenario
54+
between the CNI plugin that implementations the network policy at L3/L4 and
55+
service mesh implementation that implements the policy at L7?
56+
* One way is to probably split the implementation responsibility:
57+
1. CNI plugin can take of implementing denyAll connections and
58+
allowed serviceAccount to serviceAccount connections upto L3/L4
59+
2. service mesh implementation can implement the allowed serviceAccount to
60+
serviceAccount connections on L7
61+
* NOTE: There are some service mesh implementations which have a
62+
CNI component in them that collapses the logic of enforcement - so maybe
63+
that might become a requirement that the implementation be able to handle
64+
end to end enforcement of the full policy
65+
* We might also want to express additional constraints at L7 (such as only
66+
allowing requests from a given identity on specific paths or with specific
67+
HTTP/gRPC methods) - Ideally we would want these extra fields to be coexisting
68+
with the L3/L4 Authorization policy
69+
* Should this really be part of AdminNetworkPolicy and NetworkPolicy APIs or should
70+
this be a new CRD?
71+
* Making it part of existing APIs: Existing network policy APIs are pretty heavy
72+
with other types of selectors like namespaces, pods, nodes, networks, fqdns and
73+
expecting mesh implementations to implement the full CRD just to get the identity
74+
based selection might not be practical
75+
* Making it part of new API: We fall back to compatibility problem of the different
76+
layers and coexistence of this new API on a same cluster as existing network policy APIs
77+
78+
## API
79+
80+
(... details, can point to PR with changes)
81+
82+
## Conformance Details
83+
84+
(This section describes the names to be used for the feature or
85+
features in conformance tests and profiles.
86+
87+
These should be `CamelCase` names that specify the feature as
88+
precisely as possible, and are particularly important for
89+
Extended features, since they may be surfaced to users.)
90+
91+
## Alternatives
92+
93+
(List other design alternatives and why we did not go in that
94+
direction)
95+
96+
## References
97+
98+
(Add any additional document links. Again, we should try to avoid
99+
too much content not in version control to avoid broken links)

‎site-src/npeps/npep-173-service-account-matches.md

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# NPEP-173: NPEP template
2+
3+
* Issue: [#173](https://github.com/kubernetes-sigs/network-policy-api/issues/173)
4+
* Status: Provisional
5+
6+
## TLDR
7+
8+
Ability to create policies that control network traffic based on workload identities a.ka.
9+
[Kubernetes service accounts](https://kubernetes.io/docs/concepts/security/service-accounts/).
10+
11+
## Goals
12+
13+
* Use service accounts (identities) as a way of describing (admin) network policies for pods
14+
15+
## Non-Goals
16+
17+
* There might be other identity management constructs like SPIFFE IDs which
18+
are outside the scope of this enhancement. We can only provide a way to select
19+
constructs known to core Kubernetes.
20+
21+
## Introduction
22+
23+
Every pod in Kubernetes will have an associated service account. If user does
24+
not explicitly provide a service account, a default service account is created
25+
in the namespace. A given pod will always have 1 service account associated
26+
with itself. So instead of using pod labels as a way of selecting pods sometimes
27+
there might be use cases to use service accounts as a way of selecting the pods.
28+
This NPEP tries to capture the design details for service accounts as selectors
29+
for policies.
30+
31+
## User-Stories/Use-Cases
32+
33+
1. **As a** cluster admin **I want** to select pods using their service accounts
34+
instead of labels **so that** I can avoid having to setup webhooks and
35+
validation admission policies to prevent users from changing labels on their
36+
namespaces and pods that will make my policy start/stop matching the traffic
37+
which is undesired
38+
2. **As a** cluster admin **I want** to select pods using their service accounts
39+
instead of labels **so that** I can avoid the scale impact caused due to
40+
mutation of pod/namespace labels that will cause a churn which makes my CNI
41+
implementation react to that every time user changes a label.
42+
3. **As a** cluster admin my workloads have immutable identities and **I want**
43+
to apply policies per workloads using their service accounts instead of labels
44+
**since** I want to have eventual consistency of that policy in the cluster.
45+
46+
## Unresolved Discussions
47+
48+
* How to provide a standard way to configure/describe the service mesh behavior
49+
of intercepting traffic and deciding whether to allow it based on information
50+
in the TLS packets?
51+
* NetworkPolicies apply on L3 and L4 while Meshes operate at L7 mostly. So when
52+
trying to express "denyAll connections except the allowed serviceAccount to
53+
serviceAccount connections"; how do we split the enforcement in this scenario
54+
between the CNI plugin that implementations the network policy at L3/L4 and
55+
service mesh implementation that implements the policy at L7?
56+
* One way is to probably split the implementation responsibility:
57+
1. CNI plugin can take of implementing denyAll connections and
58+
allowed serviceAccount to serviceAccount connections upto L3/L4
59+
2. service mesh implementation can implement the allowed serviceAccount to
60+
serviceAccount connections on L7
61+
* NOTE: There are some service mesh implementations which have a
62+
CNI component in them that collapses the logic of enforcement - so maybe
63+
that might become a requirement that the implementation be able to handle
64+
end to end enforcement of the full policy
65+
* We might also want to express additional constraints at L7 (such as only
66+
allowing requests from a given identity on specific paths or with specific
67+
HTTP/gRPC methods) - Ideally we would want these extra fields to be coexisting
68+
with the L3/L4 Authorization policy
69+
* Should this really be part of AdminNetworkPolicy and NetworkPolicy APIs or should
70+
this be a new CRD?
71+
* Making it part of existing APIs: Existing network policy APIs are pretty heavy
72+
with other types of selectors like namespaces, pods, nodes, networks, fqdns and
73+
expecting mesh implementations to implement the full CRD just to get the identity
74+
based selection might not be practical
75+
* Making it part of new API: We fall back to compatibility problem of the different
76+
layers and coexistence of this new API on a same cluster as existing network policy APIs
77+
78+
## API
79+
80+
(... details, can point to PR with changes)
81+
82+
## Conformance Details
83+
84+
(This section describes the names to be used for the feature or
85+
features in conformance tests and profiles.
86+
87+
These should be `CamelCase` names that specify the feature as
88+
precisely as possible, and are particularly important for
89+
Extended features, since they may be surfaced to users.)
90+
91+
## Alternatives
92+
93+
(List other design alternatives and why we did not go in that
94+
direction)
95+
96+
## References
97+
98+
(Add any additional document links. Again, we should try to avoid
99+
too much content not in version control to avoid broken links)

0 commit comments

Comments
 (0)