3
3
** ALL** Network Policy API resources and future API developments should start with
4
4
a ** well-defined** and ** intentional** user story(s).
5
5
6
- ## AdminNetworkPolicy + BaselineAdminNetworkPolicy
6
+ ## ClusterNetworkPolicy (CNP)
7
7
8
- ### v1alpha1 User Stories
8
+ ### User Stories
9
+
10
+ The following user stories drive the concepts for the adminstrative resources.
11
+ Discussions on the user stories can be found here:
12
+
13
+ * [ API KEP] ( https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/2091-admin-network-policy )
14
+ * [ KEP PR] ( https://github.com/kubernetes/enhancements/pull/2522 )
9
15
10
- The following user stories drive the concepts for the ` v1alpha1 ` version of the
11
- ANP and BANP resources. More information on how the community ended up here
12
- can be found in the [ API KEP] ( https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/2091-admin-network-policy )
13
- and in the accompanying [ KEP PR] ( https://github.com/kubernetes/enhancements/pull/2522 )
14
16
15
17
#### Story 1: Deny traffic at a cluster level
16
18
17
19
As a cluster admin, I want to apply non-overridable deny rules
18
20
to certain pod(s) and(or) Namespace(s) that isolate the selected
19
21
resources from all other cluster internal traffic.
20
22
21
- For Example: In this diagram there is a AdminNetworkPolicy applied to the
22
- ` sensitive-ns ` denying ingress from all other in-cluster resources for all
23
- ports and protocols.
23
+ For Example: In this diagram there is a ` ClusterNetworkPolicy ` in the ` Admin `
24
+ tier applied to the ` sensitive-ns ` denying ingress from all other in-cluster
25
+ resources for all ports and protocols.
24
26
25
27
![ Alt text] ( ./images/explicit_deny.png?raw=true " Explicit Deny ")
26
28
@@ -35,9 +37,10 @@ As a cluster admin, I want to apply non-overridable allow rules to
35
37
certain pods(s) and(or) Namespace(s) that enable the selected resources
36
38
to communicate with all other cluster internal entities.
37
39
38
- For Example: In this diagram there is a AdminNetworkPolicy applied to every
39
- namespace in the cluster allowing egress traffic to ` kube-dns ` pods, and ingress
40
- traffic from pods in ` monitoring-ns ` for all ports and protocols.
40
+ For Example: In this diagram there is a ` ClusterNetworkPolicy ` in the ` Admin `
41
+ tier applied to every namespace in the cluster allowing egress traffic to
42
+ ` kube-dns ` pods, and ingress traffic from pods in ` monitoring-ns ` for all ports
43
+ and protocols.
41
44
42
45
![ Alt text] ( ./images/explicit_allow.png?raw=true " Explicit Allow ")
43
46
@@ -52,10 +55,10 @@ As a cluster admin, I want to explicitly delegate traffic so that it
52
55
skips any remaining cluster network policies and is handled by standard
53
56
namespace scoped network policies.
54
57
55
- For Example: In the diagram below egress traffic destined for the service svc-pub
56
- in namespace bar-ns-1 on TCP port 8080 is delegated to the k8s network policies
57
- implemented in foo-ns-1 and foo-ns-2. If no k8s network policies touch the
58
- delegated traffic the traffic will be allowed.
58
+ For Example: In the diagram below egress traffic destined for the service
59
+ ` svc-pub ` in namespace ` bar-ns-1 ` on TCP port 8080 is delegated to the k8s
60
+ network policies implemented in ` foo-ns-1 ` and ` foo-ns-2 ` . If no k8s network
61
+ policies match the delegated traffic, the traffic will be allowed.
59
62
60
63
![ Alt text] ( ./images/delegation.png?raw=true " Delegate ")
61
64
@@ -66,6 +69,8 @@ delegated traffic the traffic will be allowed.
66
69
67
70
#### Story 4: Create and Isolate multiple tenants in a cluster
68
71
72
+ (Currently not implementable)
73
+
69
74
As a cluster admin, I want to build tenants in my cluster that are isolated from
70
75
each other by default. Tenancy may be modeled as 1:1, where 1 tenant is mapped
71
76
to a single Namespace, or 1: n , where a single tenant may own more than 1 Namespace.
@@ -93,7 +98,7 @@ so that all intra-cluster traffic (except for certain essential traffic) is
93
98
blocked by default. Namespace owners will need to use NetworkPolicies to
94
99
explicitly allow known traffic. This follows a whitelist model which is
95
100
familiar to many security administrators, and similar
96
- to how [ kubernetes suggests network policy be used] ( https://kubernetes.io/docs/concepts/services-networking/network-policies/# default-policies) .
101
+ to how [ kubernetes suggests network policy be used] [ k8s- default-policies] .
97
102
98
103
For Example: In the following diagram all Ingress traffic to every cluster
99
104
resource is denied by a baseline deny rule.
@@ -104,3 +109,5 @@ resource is denied by a baseline deny rule.
104
109
```yaml
105
110
--8<-- "user-story-examples/user-story-5.yaml"
106
111
```
112
+
113
+ [ k8s-default-policies ] : https://kubernetes.io/docs/concepts/services-networking/network-policies/#default-policies
0 commit comments