Questo contenuto non è disponibile nella lingua selezionata.
Chapter 2. Admin network policy
2.1. OVN-Kubernetes AdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
2.1.1. AdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
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
priorityvalue 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 Copia collegamentoCollegamento copiato negli appunti!
Example 2.1. Example YAML file for an ANP
- 1
- Specify a name for your ANP.
- 2
- The
spec.priorityfield supports a maximum of 100 ANPs in the range of values0-99in 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.ingressfield accepts values ofPass,Deny, andAllowfor theactionfield. - 5
- Specify a name for the
ingress.name. - 6
- Specify
podSelector.matchLabelsto select pods within the namespaces selected bynamespaceSelector.matchLabelsas ingress peers. - 7
- ANPs have both ingress and egress rules. ANP rules for
spec.egressfield accepts values ofPass,Deny, andAllowfor theactionfield.
Additional resources
2.1.1.2. AdminNetworkPolicy actions for rules Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
2.2.1. BaselineAdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
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
subjectthat 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 Copia collegamentoCollegamento copiato negli appunti!
Example 2.5. Example YAML file for BANP
- 1
- The policy name must be
defaultbecause 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.ingressandspec.egressfields accepts values ofDenyandAllowfor theactionfield. - 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.matchLabelsname of the pods to apply the BANP resource.
2.2.1.2. BaselineAdminNetworkPolicy Deny example Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
| 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 Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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
nodesegress peer -
Implement egress traffic control towards Kubernetes API servers using
nodesornetworksegress peers -
Implement egress traffic control towards external destinations outside the cluster using
networkspeer
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 Copia collegamentoCollegamento copiato negli appunti!
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
matchExpressionsfield. - 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, orinternallevel ofsecurity. - 4
- Specifies key/value pairs for
matchExpressionsfield.
2.4.1.2. Using networks peer to control egress traffic towards external destinations Copia collegamentoCollegamento copiato negli appunti!
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
networksto 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
Denyegress to everything by settingnetworksvalues to0.0.0.0/0. Make sure you have a higher priorityAllowrule to necessary destinations before setting aDenyto0.0.0.0/0because 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
Passrule and the strong BANPDenyrule a guardrail policy is created that secures traffic in the cluster.
2.4.1.3. Using nodes peer and networks peer together Copia collegamentoCollegamento copiato negli appunti!
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
nodesandnetworkspeers, 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-appslabel across all namespaces are thesubjectof the policy.
2.5. Troubleshooting AdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
2.5.1. Checking creation of ANP Copia collegamentoCollegamento copiato negli appunti!
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 Copia collegamentoCollegamento copiato negli appunti!
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-adminrole. -
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 -owideCopy 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-524dtCopy 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
AdminNetworkPolicyyou are troubleshooting. - AdminNetworkPolicy
-
Specifies the type:
AdminNetworkPolicyorBaselineAdminNetworkPolicy.
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
matchtheactionis 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
nameof your ANP. Ingress-
Specifies the
directionof traffic either of typeIngressorEgress. 1- Specifies the rule you want to look at.
For the example ANP named
cluster-controlatpriority34, the following is an example output forIngressrule1: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_SetCopy 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 : a11452480169090787059Copy 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 Copia collegamentoCollegamento copiato negli appunti!
This section provides best practices for the AdminNetworkPolicy and BaselineAdminNetworkPolicy resources.
2.6.1. Designing AdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
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-100is 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/0or::/0to create a strongDenypolicy, ensure that you have higher priorityAlloworPassrules for essential traffic. -
Use
Allowas youractionfield when you want to ensure that a connection is allowed no matter what. AnAllowrule in an ANP means that the connection will always be allowed, andNetworkPolicywill be ignored. -
Use
Passas youractionfield to delegate the policy decision of allowing or denying the connection to theNetworkPolicylayer. - 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
namedPortsin conjunction withPortNumberandPortRangebecause this creates 6 ACLs and cause inefficiencies in your cluster.
2.6.1.1. Considerations for using BaselineAdminNetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
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
NetworkPolicyobjects 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
NetworkPolicyobjects 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
NetworkPolicyto 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/0and::/0). This BANP allows user workloads to send traffic to other in-cluster endpoints, but not to external endpoints by default.NetworkPolicycan 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
NetworkPolicyobjects to override your BANP.
2.6.1.2. Differences to consider between AdminNetworkPolicy and NetworkPolicy Copia collegamentoCollegamento copiato negli appunti!
-
Unlike
NetworkPolicyobjects, 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
NetworkPolicyobjects which have an implicit deny. -
Unlike
NetworkPolicyobjects,AdminNetworkPolicyobjects 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.