You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike the NetworkPolicy resource in which each rule represents an allowed
61
-
traffic, AdminNetworkPolicies will enable administrators to set `Pass`,
62
-
`Deny` or `Allow` as the action of each rule. AdminNetworkPolicy rules should
69
+
traffic, ClusterNetworkPolicy will enable administrators to set `Pass`,
70
+
`Deny` or `Accept` as the action of each rule. ClusterNetworkPolicy rules should
63
71
be read as-is, i.e. there will not be any implicit isolation effects for the Pods
64
-
selected by the AdminNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.
65
-
66
-
-**Pass**: Traffic that matches a `Pass` rule will skip all further rules from all
67
-
numbered ANPs and instead be enforced by the K8s NetworkPolicies.
68
-
If there is no K8s NetworkPolicy of BaselineAdminNetworkPolicy rule match
69
-
traffic will be governed by the implementation. For most implementations,
70
-
this means "allow", but there may be implementations which have their own policies
71
-
outside of the standard Kubernetes APIs.
72
-
-**Deny**: Traffic that matches a `Deny` rule will be dropped.
73
-
-**Allow**: Traffic that matches an `Allow` rule will be allowed.
74
-
75
-
AdminNetworkPolicy `Deny` rules are useful for administrators to explicitly
72
+
selected by the ClusterNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.
73
+
74
+
-**Accept**: Accepts the selected traffic, allowing it into
75
+
the destination. No further ClusterNetworkPolicy or
76
+
NetworkPolicy rules will be processed.
77
+
78
+
-**Deny**: Drops the selected traffic. No further
79
+
ClusterNetworkPolicy or NetworkPolicy rules will be
80
+
processed.
81
+
82
+
-**Pass**: Skips all further ClusterNetworkPolicy rules in the
83
+
current tier for the selected traffic, and passes
84
+
evaluation to the next tier.
85
+
86
+
ClusterNetworkPolicy `Deny` rules are useful for administrators to explicitly
76
87
block traffic with malicious in-cluster clients, or workloads that pose security risks.
77
88
Those traffic restrictions can only be lifted once the `Deny` rules are deleted,
78
89
modified by the admin, or overridden by a higher priority rule.
79
90
80
-
On the other hand, the `Allow` rules can be used to call out traffic in the cluster
91
+
On the other hand, the `Accept` rules can be used to call out traffic in the cluster
81
92
that needs to be allowed for certain components to work as expected (egress to
82
93
CoreDNS for example). This traffic should not be blocked when developers apply
83
94
NetworkPolicy to their Namespaces which isolates the workloads.
84
95
85
-
AdminNetworkPolicy`Pass` rules allow an admin to delegate security posture for
96
+
ClusterNetworkPolicy`Pass` rules in the `Admin` tier allow an admin to delegate security posture for
86
97
certain traffic to the Namespace owners by overriding any lower precedence Allow
87
98
or Deny rules. For example, intra-tenant traffic management can be delegated to tenant
88
99
admins explicitly with the use of `Pass` rules. More specifically traffic selected
89
-
by a `Pass` rule will skip any further ANP rule selection, be evaluated against
90
-
any welldefined NetworkPolicies, and if not terminated ultimately be evaluated against any
91
-
BaselineAdminNetworkPolicies.
100
+
by a `Pass` rule will skip any further `Admin` tier rule selection, be evaluated against
101
+
any well-defined NetworkPolicies, and if not terminated ultimately be evaluated against any
102
+
`Baseline` tier CNP.
92
103
93
-
### AdminNetworkPolicy Priorities
104
+
### ClusterNetworkPolicy Priorities
94
105
95
-
Integer priority values were added to the AdminNetworkPolicy API to allow Cluster
96
-
Admins to express direct and intentional ordering between various ANP Objects.
97
-
The `Priority` field in the ANP spec is defined as an integer value
98
-
within the range 0 to 1000 where rules with lower priority values have higher
99
-
precedence. Regardless of priority value all ANPs have higher precedence than
100
-
any defined NetworkPolicy or BaselineAdminNetworkPolicy objects.
106
+
Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster
107
+
Admins to express direct and intentional ordering between various CNP Objects.
108
+
The `Priority` field in the CNP spec is defined as an integer value
109
+
within the range 0 to 1000 where rules with lower priority values have
110
+
higher precedence, and are checked before policies with higher priority
111
+
values in the same tier.
101
112
102
-
### AdminNetworkPolicy Rules
113
+
### ClusterNetworkPolicy Rules
103
114
104
-
Each ANP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
115
+
Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
105
116
along with the associated Action that should occur. In each `gress` rule the user
106
-
should AT THE MINIMUM define an `Action`, and at least one `AdminNetworkPolicyPeer`.
117
+
should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`.
107
118
Optionally the user may also define select `Ports` to filter traffic on and also
108
119
a name for each rule to make management and reporting easier for Admins.
109
120
110
-
### AdminNetworkPolicy Status
121
+
### ClusterNetworkPolicy Status
111
122
112
-
For `v1alpha1` of this API the ANP status field is simply defined as a list of
123
+
For `v1alpha2` of this API the ANP status field is simply defined as a list of
113
124
[`metav1.condition`](https://github.com/kubernetes/apimachinery/blob/v0.25.0/pkg/apis/meta/v1/types.go#L1464)s. Currently there are no rules as to what these conditions should display,
114
125
and it is up to each implementation to report what they see fit. For further
115
126
API iterations the community may consider standardizing these conditions based on
116
127
the usefulness they provide for various implementors.
117
-
118
-
## The BaselineAdminNetworkPolicy Resource
119
-
120
-
The BaselineAdminNetworkPolicy (BANP) resource will allow administrators to
121
-
set baseline security rules that describes default connectivity for cluster workloads,
122
-
which CAN be overridden by developer NetworkPolicies if needed. The major use case
123
-
BANPs solve is the ability to flip the [default security stance of the
which looks like this with the new `ClusterNetworkPolicy` API:
92
+
93
+
```yaml
94
+
--8<-- "user-story-examples/user-story-5.yaml"
95
+
```
96
+
97
+
### Migration
98
+
99
+
We appreciate all early adopters of the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` APIs.
100
+
You can continue using them at their latest released version [v0.1.7](https://github.com/kubernetes-sigs/network-policy-api/releases/tag/v0.1.7)
101
+
At the same time, we encourage you to plan your migration to the new `ClusterNetworkPolicy` API, which can be done once its first version is available.
102
+
We plan to base our `beta` release on the `ClusterNetworkPolicy` API.
Copy file name to clipboardExpand all lines: site-src/index.md
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,12 @@ multiple K8s CRD resources geared towards different users and use cases.
19
19
20
20
### Active (APIs undergoing active development)
21
21
22
-
-[AdminNetworkPolicy](api-overview.md#the-adminnetworkpolicy-resource) and [BaselineAdminNetworkPolicy](api-overview.md#the-baselineadminnetworkpolicy-resource)
0 commit comments