Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 6. Network Policy
As a user with the admin role, you can create a network policy for the netobserv namespace to secure inbound access to the Network Observability Operator.
6.1. Configuring an ingress network policy by using the FlowCollector custom resource
You can configure the FlowCollector custom resource (CR) to deploy an ingress network policy for Network Observability by setting the spec.NetworkPolicy.enable specification to true. By default, the specification is false.
If you have installed Loki, Kafka or any exporter in a different namespace that also has a network policy, you must ensure that the Network Observability components can communicate with them. Consider the following about your setup:
-
Connection to Loki (as defined in the
FlowCollectorCRspec.lokiparameter) -
Connection to Kafka (as defined in the
FlowCollectorCRspec.kafkaparameter) -
Connection to any exporter (as defined in FlowCollector CR
spec.exportersparameter) -
If you are using Loki and including it in the policy target, connection to an external object storage (as defined in your
LokiStackrelated secret)
Procedure
-
. In the web console, go to Operators
Installed Operators page. - Under the Provided APIs heading for Network Observability, select Flow Collector.
- Select cluster then select the YAML tab.
Configure the
FlowCollectorCR. A sample configuration is as follows:Example
FlowCollectorCR for network policyapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv networkPolicy: enable: true 1 additionalNamespaces: ["openshift-console", "openshift-monitoring"] 2 # ...
6.2. Creating a network policy for Network Observability
If you want to further customize the network policies for the netobserv and netobserv-privileged namespaces, you must disable the managed installation of the policy from the FlowCollector CR, and create your own. You can use the network policy resources that are enabled from the FlowCollector CR as a starting point for the procedure that follows:
Example netobserv network policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
ingress:
- from:
- podSelector: {}
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: netobserv-privileged
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshift-console
ports:
- port: 9001
protocol: TCP
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshift-monitoring
podSelector: {}
policyTypes:
- Ingress
Example netobserv-privileged network policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: netobserv
namespace: netobserv-privileged
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshift-monitoring
podSelector: {}
policyTypes:
- Ingress
Procedure
-
Navigate to Networking
NetworkPolicies. -
Select the
netobservproject from the Project dropdown menu. -
Name the policy. For this example, the policy name is
allow-ingress. - Click Add ingress rule three times to create three ingress rules.
Specify the following in the form:
Make the following specifications for the first Ingress rule:
- From the Add allowed source dropdown menu, select Allow pods from the same namespace.
Make the following specifications for the second Ingress rule:
- From the Add allowed source dropdown menu, select Allow pods from inside the cluster.
- Click + Add namespace selector.
-
Add the label,
kubernetes.io/metadata.name, and the selector,openshift-console.
Make the following specifications for the third Ingress rule:
- From the Add allowed source dropdown menu, select Allow pods from inside the cluster.
- Click + Add namespace selector.
-
Add the label,
kubernetes.io/metadata.name, and the selector,openshift-monitoring.
Verification
-
Navigate to Observe
Network Traffic. - View the Traffic Flows tab, or any tab, to verify that the data is displayed.
-
Navigate to Observe
Dashboards. In the NetObserv/Health selection, verify that the flows are being ingested and sent to Loki, which is represented in the first graph.
Additional resources
