Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Admin network policy
2.1. OVN-Kubernetes AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
2.1.1. AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
An AdminNetworkPolicy
(ANP) is a cluster-scoped custom resource definition (CRD). As a OpenShift Container Platform administrator, you can use ANP to secure your network by creating network policies before creating namespaces. Additionally, you can create network policies on a cluster-scoped level that is non-overridable by NetworkPolicy
objects.
The key difference between AdminNetworkPolicy
and NetworkPolicy
objects are that the former is for administrators and is cluster scoped while the latter is for tenant owners and is namespace scoped.
An ANP allows administrators to specify the following:
-
A
priority
value that determines the order of its evaluation. The lower the value the higher the precedence. - A set of pods that consists of a set of namespaces or namespace on which the policy is applied.
-
A list of ingress rules to be applied for all ingress traffic towards the
subject
. -
A list of egress rules to be applied for all egress traffic from the
subject
.
2.1.1.1. AdminNetworkPolicy example Copier lienLien copié sur presse-papiers!
Example 2.1. Example YAML file for an ANP
- 1
- Specify a name for your ANP.
- 2
- The
spec.priority
field supports a maximum of 100 ANPs in the range of values0-99
in a cluster. The lower the value, the higher the precedence because the range is read in order from the lowest to highest value. Because there is no guarantee which policy takes precedence when ANPs are created at the same priority, set ANPs at different priorities so that precedence is deliberate. - 3
- Specify the namespace to apply the ANP resource.
- 4
- ANP have both ingress and egress rules. ANP rules for
spec.ingress
field accepts values ofPass
,Deny
, andAllow
for theaction
field. - 5
- Specify a name for the
ingress.name
. - 6
- Specify
podSelector.matchLabels
to select pods within the namespaces selected bynamespaceSelector.matchLabels
as ingress peers. - 7
- ANPs have both ingress and egress rules. ANP rules for
spec.egress
field accepts values ofPass
,Deny
, andAllow
for theaction
field.
Additional resources
2.1.1.2. AdminNetworkPolicy actions for rules Copier lienLien copié sur presse-papiers!
As an administrator, you can set Allow
, Deny
, or Pass
as the action
field for your AdminNetworkPolicy
rules. Because OVN-Kubernetes uses a tiered ACLs to evaluate network traffic rules, ANP allow you to set very strong policy rules that can only be changed by an administrator modifying them, deleting the rule, or overriding them by setting a higher priority rule.
2.1.1.2.1. AdminNetworkPolicy Allow example Copier lienLien copié sur presse-papiers!
The following ANP that is defined at priority 9 ensures all ingress traffic is allowed from the monitoring
namespace towards any tenant (all other namespaces) in the cluster.
Example 2.2. Example YAML file for a strong Allow
ANP
This is an example of a strong Allow
ANP because it is non-overridable by all the parties involved. No tenants can block themselves from being monitored using NetworkPolicy
objects and the monitoring tenant also has no say in what it can or cannot monitor.
2.1.1.2.2. AdminNetworkPolicy Deny example Copier lienLien copié sur presse-papiers!
The following ANP that is defined at priority 5 ensures all ingress traffic from the monitoring
namespace is blocked towards restricted tenants (namespaces that have labels security: restricted
).
Example 2.3. Example YAML file for a strong Deny
ANP
This is a strong Deny
ANP that is non-overridable by all the parties involved. The restricted tenant owners cannot authorize themselves to allow monitoring traffic, and the infrastructure’s monitoring service cannot scrape anything from these sensitive namespaces.
When combined with the strong Allow
example, the block-monitoring
ANP has a lower priority value giving it higher precedence, which ensures restricted tenants are never monitored.
2.1.1.2.3. AdminNetworkPolicy Pass example Copier lienLien copié sur presse-papiers!
The following ANP that is defined at priority 7 ensures all ingress traffic from the monitoring
namespace towards internal infrastructure tenants (namespaces that have labels security: internal
) are passed on to tier 2 of the ACLs and evaluated by the namespaces’ NetworkPolicy
objects.
Example 2.4. Example YAML file for a strong Pass
ANP
This example is a strong Pass
action ANP because it delegates the decision to NetworkPolicy
objects defined by tenant owners. This pass-monitoring
ANP allows all tenant owners grouped at security level internal
to choose if their metrics should be scraped by the infrastructures' monitoring service using namespace scoped NetworkPolicy
objects.
2.2. OVN-Kubernetes BaselineAdminNetworkPolicy Copier lienLien copié sur presse-papiers!
2.2.1. BaselineAdminNetworkPolicy Copier lienLien copié sur presse-papiers!
BaselineAdminNetworkPolicy
(BANP) is a cluster-scoped custom resource definition (CRD). As a OpenShift Container Platform administrator, you can use BANP to setup and enforce optional baseline network policy rules that are overridable by users using NetworkPolicy
objects if need be. Rule actions for BANP are allow
or deny
.
The BaselineAdminNetworkPolicy
resource is a cluster singleton object that can be used as a guardrail policy incase a passed traffic policy does not match any NetworkPolicy
objects in the cluster. A BANP can also be used as a default security model that provides guardrails that intra-cluster traffic is blocked by default and a user will need to use NetworkPolicy
objects to allow known traffic. You must use default
as the name when creating a BANP resource.
A BANP allows administrators to specify:
-
A
subject
that consists of a set of namespaces or namespace. -
A list of ingress rules to be applied for all ingress traffic towards the
subject
. -
A list of egress rules to be applied for all egress traffic from the
subject
.
2.2.1.1. BaselineAdminNetworkPolicy example Copier lienLien copié sur presse-papiers!
Example 2.5. Example YAML file for BANP
- 1
- The policy name must be
default
because BANP is a singleton object. - 2
- Specify the namespace to apply the ANP to.
- 3
- BANP have both ingress and egress rules. BANP rules for
spec.ingress
andspec.egress
fields accepts values ofDeny
andAllow
for theaction
field. - 4
- Specify a name for the
ingress.name
- 5
- Specify the namespaces to select the pods from to apply the BANP resource.
- 6
- Specify
podSelector.matchLabels
name of the pods to apply the BANP resource.
2.2.1.2. BaselineAdminNetworkPolicy Deny example Copier lienLien copié sur presse-papiers!
The following BANP singleton ensures that the administrator has set up a default deny policy for all ingress monitoring traffic coming into the tenants at internal
security level. When combined with the "AdminNetworkPolicy Pass example", this deny policy acts as a guardrail policy for all ingress traffic that is passed by the ANP pass-monitoring
policy.
Example 2.6. Example YAML file for a guardrail Deny
rule
You can use an AdminNetworkPolicy
resource with a Pass
value for the action
field in conjunction with the BaselineAdminNetworkPolicy
resource to create a multi-tenant policy. This multi-tenant policy allows one tenant to collect monitoring data on their application while simultaneously not collecting data from a second tenant.
As an administrator, if you apply both the "AdminNetworkPolicy Pass
action example" and the "BaselineAdminNetwork Policy Deny
example", tenants are then left with the ability to choose to create a NetworkPolicy
resource that will be evaluated before the BANP.
For example, Tenant 1 can set up the following NetworkPolicy
resource to monitor ingress traffic:
Example 2.7. Example NetworkPolicy
In this scenario, Tenant 1’s policy would be evaluated after the "AdminNetworkPolicy Pass
action example" and before the "BaselineAdminNetwork Policy Deny
example", which denies all ingress monitoring traffic coming into tenants with security
level internal
. With Tenant 1’s NetworkPolicy
object in place, they will be able to collect data on their application. Tenant 2, however, who does not have any NetworkPolicy
objects in place, will not be able to collect data. As an administrator, you have not by default monitored internal tenants, but instead, you created a BANP that allows tenants to use NetworkPolicy
objects to override the default behavior of your BANP.
2.3. Monitoring ANP and BANP Copier lienLien copié sur presse-papiers!
AdminNetworkPolicy
and BaselineAdminNetworkPolicy
resources have metrics that can be used for monitoring and managing your policies. See the following table for more details on the metrics.
2.3.1. Metrics for AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
Name | Description | Explanation |
---|---|---|
| Not applicable |
The total number of |
| Not applicable |
The total number of |
|
|
The total number of rules across all ANP policies in the cluster grouped by |
|
|
The total number of rules across all BANP policies in the cluster grouped by |
|
|
The total number of OVN Northbound database (nbdb) objects that are created by all the ANP in the cluster grouped by the |
|
|
The total number of OVN Northbound database (nbdb) objects that are created by all the BANP in the cluster grouped by the |
2.4. Egress nodes and networks peer for AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
This section explains nodes
and networks
peers. Administrators can use the examples in this section to design AdminNetworkPolicy
and BaselineAdminNetworkPolicy
to control northbound traffic in their cluster.
2.4.1. Northbound traffic controls for AdminNetworkPolicy and BaselineAdminNetworkPolicy Copier lienLien copié sur presse-papiers!
In addition to supporting east-west traffic controls, ANP and BANP also allow administrators to control their northbound traffic leaving the cluster or traffic leaving the node to other nodes in the cluster. End-users can do the following:
-
Implement egress traffic control towards cluster nodes using
nodes
egress peer -
Implement egress traffic control towards Kubernetes API servers using
nodes
ornetworks
egress peers -
Implement egress traffic control towards external destinations outside the cluster using
networks
peer
For ANP and BANP, nodes
and networks
peers can be specified for egress rules only.
2.4.1.1. Using nodes peer to control egress traffic to cluster nodes Copier lienLien copié sur presse-papiers!
Using the nodes
peer administrators can control egress traffic from pods to nodes in the cluster. A benefit of this is that you do not have to change the policy when nodes are added to or deleted from the cluster.
The following example allows egress traffic to the Kubernetes API server on port 6443
by any of the namespaces with a restricted
, confidential
, or internal
level of security using the node selector peer. It also denies traffic to all worker nodes in your cluster from any of the namespaces with a restricted
, confidential
, or internal
level of security.
Example 2.8. Example of ANP Allow
egress using nodes
peer
- 1
- Specifies a node or set of nodes in the cluster using the
matchExpressions
field. - 2
- Specifies all the pods labeled with
dept: engr
. - 3
- Specifies the subject of the ANP which includes any namespaces that match the labels used by the network policy. The example matches any of the namespaces with
restricted
,confidential
, orinternal
level ofsecurity
. - 4
- Specifies key/value pairs for
matchExpressions
field.
2.4.1.2. Using networks peer to control egress traffic towards external destinations Copier lienLien copié sur presse-papiers!
Cluster administrators can use CIDR ranges in networks
peer and apply a policy to control egress traffic leaving from pods and going to a destination configured at the IP address that is within the CIDR range specified with networks
field.
The following example uses networks
peer and combines ANP and BANP policies to restrict egress traffic.
Use the empty selector ({}) in the namespace
field for ANP and BANP with caution. When using an empty selector, it also selects OpenShift namespaces.
If you use values of 0.0.0.0/0
in a ANP or BANP Deny
rule, you must set a higher priority ANP Allow
rule to necessary destinations before setting the Deny
to 0.0.0.0/0
.
Example 2.9. Example of ANP and BANP using networks
peers
- 1
- Use
networks
to specify a range of CIDR networks outside of the cluster. - 2
- Specifies the CIDR ranges for the intra-cluster traffic from your resources.
- 3 4
- Specifies a
Deny
egress to everything by settingnetworks
values to0.0.0.0/0
. Make sure you have a higher priorityAllow
rule to necessary destinations before setting aDeny
to0.0.0.0/0
because this will deny all traffic including to Kubernetes API and DNS servers.
Collectively the network-as-egress-peer
ANP and default
BANP using networks
peers enforces the following egress policy:
- All pods cannot talk to external DNS servers at the listed IP addresses.
- All pods can talk to rest of the company’s intranet.
- All pods can talk to other pods, nodes, and services.
-
All pods cannot talk to the internet. Combining the last ANP
Pass
rule and the strong BANPDeny
rule a guardrail policy is created that secures traffic in the cluster.
2.4.1.3. Using nodes peer and networks peer together Copier lienLien copié sur presse-papiers!
Cluster administrators can combine nodes
and networks
peer in your ANP and BANP policies.
Example 2.10. Example of nodes
and networks
peer
- 1
- Specifies the name of the policy.
- 2
- For
nodes
andnetworks
peers, you can only use northbound traffic controls in ANP asegress
. - 3
- Specifies the priority of the ANP, determining the order in which they should be evaluated. Lower priority rules have higher precedence. ANP accepts values of 0-99 with 0 being the highest priority and 99 being the lowest.
- 4
- Specifies the set of pods in the cluster on which the rules of the policy are to be applied. In the example, any pods with the
apps: all-apps
label across all namespaces are thesubject
of the policy.
2.5. Troubleshooting AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
2.5.1. Checking creation of ANP Copier lienLien copié sur presse-papiers!
To check that your AdminNetworkPolicy
(ANP) and BaselineAdminNetworkPolicy
(BANP) are created correctly, check the status outputs of the following commands: oc describe anp
or oc describe banp
.
A good status indicates OVN DB plumbing was successful
and the SetupSucceeded
.
Example 2.11. Example ANP with a good status
If plumbing is unsuccessful, an error is reported from the respective zone controller.
Example 2.12. Example of an ANP with a bad status and error message
See the following section for nbctl
commands to help troubleshoot unsuccessful policies.
2.5.1.1. Using nbctl commands for ANP and BANP Copier lienLien copié sur presse-papiers!
To troubleshoot an unsuccessful setup, start by looking at OVN Northbound database (nbdb) objects including ACL
, AdressSet
, and Port_Group
. To view the nbdb, you need to be inside the pod on that node to view the objects in that node’s database.
Prerequisites
-
Access to the cluster as a user with the
cluster-admin
role. -
The OpenShift CLI (
oc
) installed.
To run ovn nbctl
commands in a cluster, you must open a remote shell into the `nbdb`on the relevant node.
The following policy was used to generate outputs.
Example 2.13. AdminNetworkPolicy
used to generate outputs
Procedure
List pods with node information by running the following command:
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Navigate into a pod to look at the northbound database by running the following command:
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the following command to look at the ACLs nbdb:
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Where, cluster-control
-
Specifies the name of the
AdminNetworkPolicy
you are troubleshooting. - AdminNetworkPolicy
-
Specifies the type:
AdminNetworkPolicy
orBaselineAdminNetworkPolicy
.
Example 2.14. Example output for ACLs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe outputs for ingress and egress show you the logic of the policy in the ACL. For example, every time a packet matches the provided
match
theaction
is taken.Examine the specific ACL for the rule by running the following command:
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Where,
cluster-control
-
Specifies the
name
of your ANP. Ingress
-
Specifies the
direction
of traffic either of typeIngress
orEgress
. 1
- Specifies the rule you want to look at.
For the example ANP named
cluster-control
atpriority
34
, the following is an example output forIngress
rule
1:Example 2.15. Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Where,
Run the following command to look at address sets in the nbdb:
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 2.16. Example outputs for
Address_Set
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Examine the specific address set of the rule by running the following command:
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'
$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 2.17. Example outputs for
Address_Set
_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059
_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Run the following command to look at the port groups in the nbdb:
ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
$ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 2.18. Example outputs for
Port_Group
_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]
_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. Best practices for AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
This section provides best practices for the AdminNetworkPolicy
and BaselineAdminNetworkPolicy
resources.
2.6.1. Designing AdminNetworkPolicy Copier lienLien copié sur presse-papiers!
When building AdminNetworkPolicy
(ANP) resources, you might consider the following when creating your policies:
- You can create ANPs that have the same priority. If you do create two ANPs at the same priority, ensure that they do not apply overlapping rules to the same traffic. Only one rule per value is applied and there is no guarantee which rule is applied when there is more than one at the same priority value. Because there is no guarantee which policy takes precedence when overlapping ANPs are created, set ANPs at different priorities so that precedence is well defined.
- Administrators must create ANP that apply to user namespaces not system namespaces.
Applying ANP and BaselineAdminNetworkPolicy
(BANP) to system namespaces (default
, kube-system
, any namespace whose name starts with openshift-
, etc) is not supported, and this can leave your cluster unresponsive and in a non-functional state.
-
Because
0-100
is the supported priority range, you might design your ANP to use a middle range like30-70
. This leaves some placeholder for priorities before and after. Even in the middle range, you might want to leave gaps so that as your infrastructure requirements evolve over time, you are able to insert new ANPs when needed at the right priority level. If you pack your ANPs, then you might need to recreate all of them to accommodate any changes in the future. -
When using
0.0.0.0/0
or::/0
to create a strongDeny
policy, ensure that you have higher priorityAllow
orPass
rules for essential traffic. -
Use
Allow
as youraction
field when you want to ensure that a connection is allowed no matter what. AnAllow
rule in an ANP means that the connection will always be allowed, andNetworkPolicy
will be ignored. -
Use
Pass
as youraction
field to delegate the policy decision of allowing or denying the connection to theNetworkPolicy
layer. - Ensure that the selectors across multiple rules do not overlap so that the same IPs do not appear in multiple policies, which can cause performance and scale limitations.
-
Avoid using
namedPorts
in conjunction withPortNumber
andPortRange
because this creates 6 ACLs and cause inefficiencies in your cluster.
2.6.1.1. Considerations for using BaselineAdminNetworkPolicy Copier lienLien copié sur presse-papiers!
You can define only a single
BaselineAdminNetworkPolicy
(BANP) resource within a cluster. The following are supported uses for BANP that administrators might consider in designing their BANP:-
You can set a default deny policy for cluster-local ingress in user namespaces. This BANP will force developers to have to add
NetworkPolicy
objects to allow the ingress traffic that they want to allow, and if they do not add network policies for ingress it will be denied. -
You can set a default deny policy for cluster-local egress in user namespaces. This BANP will force developers to have to add
NetworkPolicy
objects to allow the egress traffic that they want to allow, and if they do not add network policies it will be denied. -
You can set a default allow policy for egress to the in-cluster DNS service. Such a BANP ensures that the namespaced users do not have to set an allow egress
NetworkPolicy
to the in-cluster DNS service. -
You can set an egress policy that allows internal egress traffic to all pods but denies access to all external endpoints (i.e
0.0.0.0/0
and::/0
). This BANP allows user workloads to send traffic to other in-cluster endpoints, but not to external endpoints by default.NetworkPolicy
can then be used by developers in order to allow their applications to send traffic to an explicit set of external services.
-
You can set a default deny policy for cluster-local ingress in user namespaces. This BANP will force developers to have to add
-
Ensure you scope your BANP so that it only denies traffic to user namespaces and not to system namespaces. This is because the system namespaces do not have
NetworkPolicy
objects to override your BANP.
2.6.1.2. Differences to consider between AdminNetworkPolicy and NetworkPolicy Copier lienLien copié sur presse-papiers!
-
Unlike
NetworkPolicy
objects, you must use explicit labels to reference your workloads within ANP and BANP rather than using the empty ({}
) catch all selector to avoid accidental traffic selection.
An empty namespace selector applied to a infrastructure namespace can make your cluster unresponsive and in a non-functional state.
-
In API semantics for ANP, you have to explicitly define allow or deny rules when you create the policy, unlike
NetworkPolicy
objects which have an implicit deny. -
Unlike
NetworkPolicy
objects,AdminNetworkPolicy
objects ingress rules are limited to in-cluster pods and namespaces so you cannot, and do not need to, set rules for ingress from the host network.