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
76
+
traffic, ClusterNetworkPolicy will enable administrators to set `Pass`,
77
+
`Deny` or `Accept` as the action of each rule. ClusterNetworkPolicy rules should
63
78
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
79
+
selected by the ClusterNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.
80
+
81
+
-**Accept**: Accepts the selected traffic, allowing it into
82
+
the destination. No further ClusterNetworkPolicy or
83
+
NetworkPolicy rules will be processed.
84
+
85
+
-**Deny**: Drops the selected traffic. No further
86
+
ClusterNetworkPolicy or NetworkPolicy rules will be
87
+
processed.
88
+
89
+
-**Pass**: Skips all further ClusterNetworkPolicy rules in the
90
+
current tier for the selected traffic, and passes
91
+
evaluation to the next tier.
92
+
93
+
ClusterNetworkPolicy `Deny` rules are useful for administrators to explicitly
76
94
block traffic with malicious in-cluster clients, or workloads that pose security risks.
77
95
Those traffic restrictions can only be lifted once the `Deny` rules are deleted,
78
96
modified by the admin, or overridden by a higher priority rule.
79
97
80
-
On the other hand, the `Allow` rules can be used to call out traffic in the cluster
98
+
On the other hand, the `Accept` rules can be used to call out traffic in the cluster
81
99
that needs to be allowed for certain components to work as expected (egress to
82
100
CoreDNS for example). This traffic should not be blocked when developers apply
83
101
NetworkPolicy to their Namespaces which isolates the workloads.
84
102
85
-
AdminNetworkPolicy`Pass` rules allow an admin to delegate security posture for
103
+
ClusterNetworkPolicy`Pass` rules in the `Admin` tier allow an admin to delegate security posture for
86
104
certain traffic to the Namespace owners by overriding any lower precedence Allow
87
-
or Deny rules. For example, intra-tenant traffic management can be delegated to tenant
88
-
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 well defined NetworkPolicies, and if not terminated ultimately be evaluated against any
91
-
BaselineAdminNetworkPolicies.
105
+
or Deny rules. For example, intra-namespace traffic management can be delegated to namespace
106
+
admins explicitly with the use of `Pass` rules. More specifically traffic selected by a `Pass` rule
107
+
will skip any lower precedence `Admin` tier rules and proceed to be evaluated by `NetworkPolicy` and
108
+
`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will
109
+
apply next or if there is no `NetworkPolicy` match, `Baseline` policies will be evaluated.
92
110
93
-
### AdminNetworkPolicy Priorities
111
+
### Priorities
94
112
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.
113
+
Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster
114
+
Admins to express direct and intentional ordering between various CNP Objects.
115
+
The `Priority` field in the CNP spec is defined as a non-negative integer value
116
+
where rules with lower priority values have higher precedence, and are checked
117
+
before policies with higher priority values in the same tier.
101
118
102
-
### AdminNetworkPolicy Rules
119
+
### Rules
103
120
104
-
Each ANP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
121
+
Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
105
122
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`.
123
+
should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`.
107
124
Optionally the user may also define select `Ports` to filter traffic on and also
108
125
a name for each rule to make management and reporting easier for Admins.
109
126
110
-
### AdminNetworkPolicy Status
127
+
### Status
111
128
112
-
For `v1alpha1` of this API the ANP status field is simply defined as a list of
129
+
For `v1alpha2` of this API the ANP status field is simply defined as a list of
113
130
[`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
131
and it is up to each implementation to report what they see fit. For further
115
132
API iterations the community may consider standardizing these conditions based on
116
133
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:
94
+
95
+
```yaml
96
+
--8<-- "user-story-examples/user-story-5.yaml"
97
+
```
98
+
99
+
### Migration
100
+
101
+
We appreciate all early adopters of the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` APIs.
102
+
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)
103
+
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.
104
+
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