Networking

Procedure

1. You can deploy the AWS Load Balancer Operator on demand from OperatorHub, by creating a Subscription object by running the following command:

   $ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

   Example output

   install-zlfbt

2. Check if the status of an install plan is Complete by running the following command:

   $ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'

   Example output

   Complete

3. View the status of the aws-load-balancer-operator-controller-manager deployment by running the following command:

   $ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

   Example output

   NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-operator-controller-manager  1/1       1            1           23h

Procedure

1. Navigate to Operators → OperatorHub in the OpenShift Container Platform web console.
2. Select the AWS Load Balancer Operator. You can use the Filter by keyword text box or use the filter list to search for the AWS Load Balancer Operator from the list of Operators.
3. Select the aws-load-balancer-operator namespace.

4. On the Install Operator page, select the following options:

   1. Update the channel as stable-v1.
   2. Installation mode as All namespaces on the cluster (default).
   3. Installed Namespace as aws-load-balancer-operator. If the aws-load-balancer-operator namespace does not exist, it gets created during the Operator installation.
   4. Select Update approval as Automatic or Manual. By default, the Update approval is set to Automatic. If you select automatic updates, the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention. If you select manual updates, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to update the Operator updated to the new version.
5. Click Install.

Procedure

1. Create a Namespace object:

   1. Create a YAML file that defines the Namespace object:

      Example namespace.yaml file

      apiVersion: v1
      kind: Namespace
      metadata:
        name: aws-load-balancer-operator

   2. Create the Namespace object by running the following command:

      $ oc apply -f namespace.yaml

2. Create an OperatorGroup object:

   1. Create a YAML file that defines the OperatorGroup object:

      Example operatorgroup.yaml file

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: aws-lb-operatorgroup
        namespace: aws-load-balancer-operator
      spec:
        upgradeStrategy: Default

   2. Create the OperatorGroup object by running the following command:

      $ oc apply -f operatorgroup.yaml

3. Create a Subscription object:

   1. Create a YAML file that defines the Subscription object:

      Example subscription.yaml file

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: aws-load-balancer-operator
        namespace: aws-load-balancer-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: aws-load-balancer-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. Create the Subscription object by running the following command:

      $ oc apply -f subscription.yaml

Verification

1. Get the name of the install plan from the subscription:

   $ oc -n aws-load-balancer-operator \
       get subscription aws-load-balancer-operator \
       --template='{{.status.installplan.name}}{{"\n"}}'

2. Check the status of the install plan:

   $ oc -n aws-load-balancer-operator \
       get ip <install_plan_name> \
       --template='{{.status.phase}}{{"\n"}}'

   The output must be Complete.

Procedure

1. Create the aws-load-balancer-operator project by running the following command:

   $ oc new-project aws-load-balancer-operator

2. Create the OperatorGroup object by running the following command:

   $ cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     targetNamespaces: []
   EOF

3. Create the Subscription object by running the following command:

   $ cat <<EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     config:
       env:
       - name: ROLEARN
         value: "<albo_role_arn>" 1
   EOF

   1

   Specifies the ARN role to be used in the CredentialsRequest to provision the AWS credentials for the AWS Load Balancer Operator. An example for <albo_role_arn> is arn:aws:iam::<aws_account_number>:role/albo-operator.

   Note

   The AWS Load Balancer Operator waits until the secret is created before moving to the Available status.

Procedure

1. Create a YAML file that defines the AWSLoadBalancerController object:

   Example sample-aws-lb.yaml file

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController 1
   metadata:
     name: cluster 2
   spec:
     subnetTagging: Auto 3
     additionalResourceTags: 4
     - key: example.org/security-scope
       value: staging
     ingressClass: alb 5
     config:
       replicas: 2 6
     enabledAddons: 7
       - AWSWAFv2 8

   1

   Defines the AWSLoadBalancerController object.

   2

   Defines the AWS Load Balancer Controller name. This instance name gets added as a suffix to all related resources.

   3

   Configures the subnet tagging method for the AWS Load Balancer Controller. The following values are valid:

   • Auto: The AWS Load Balancer Operator determines the subnets that belong to the cluster and tags them appropriately. The Operator cannot determine the role correctly if the internal subnet tags are not present on internal subnet.
   • Manual: You manually tag the subnets that belong to the cluster with the appropriate role tags. Use this option if you installed your cluster on user-provided infrastructure.

   4

   Defines the tags used by the AWS Load Balancer Controller when it provisions AWS resources.

   5

   Defines the ingress class name. The default value is alb.

   6

   Specifies the number of replicas of the AWS Load Balancer Controller.

   7

   Specifies annotations as an add-on for the AWS Load Balancer Controller.

   8

   Enables the alb.ingress.kubernetes.io/wafv2-acl-arn annotation.

2. Create the AWSLoadBalancerController object by running the following command:

   $ oc create -f sample-aws-lb.yaml

3. Create a YAML file that defines the Deployment resource:

   Example sample-aws-lb.yaml file

   apiVersion: apps/v1
   kind: Deployment 1
   metadata:
     name: <echoserver> 2
     namespace: echoserver
   spec:
     selector:
       matchLabels:
         app: echoserver
     replicas: 3 3
     template:
       metadata:
         labels:
           app: echoserver
       spec:
         containers:
           - image: openshift/origin-node
             command:
              - "/bin/socat"
             args:
               - TCP4-LISTEN:8080,reuseaddr,fork
               - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
             imagePullPolicy: Always
             name: echoserver
             ports:
               - containerPort: 8080

   1

   Defines the deployment resource.

   2

   Specifies the deployment name.

   3

   Specifies the number of replicas of the deployment.

4. Create a YAML file that defines the Service resource:

   Example service-albo.yaml file

   apiVersion: v1
   kind: Service 1
   metadata:
     name: <echoserver> 2
     namespace: echoserver
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector:
       app: echoserver

   1

   Defines the service resource.

   2

   Specifies the service name.

5. Create a YAML file that defines the Ingress resource:

   Example ingress-albo.yaml file

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: <name> 1
     namespace: echoserver
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: <echoserver> 2
                   port:
                     number: 80

   1

   Specify a name for the Ingress resource.

   2

   Specifies the service name.

Procedure

1. Create an IngressClassParams resource YAML file, for example, sample-single-lb-params.yaml, as follows:

   apiVersion: elbv2.k8s.aws/v1beta1 1
   kind: IngressClassParams
   metadata:
     name: single-lb-params 2
   spec:
     group:
       name: single-lb 3

   1

   Defines the API group and version of the IngressClassParams resource.

   2

   Specifies the IngressClassParams resource name.

   3

   Specifies the IngressGroup resource name. All of the Ingress resources of this class belong to this IngressGroup.

2. Create the IngressClassParams resource by running the following command:

   $ oc create -f sample-single-lb-params.yaml

3. Create the IngressClass resource YAML file, for example, sample-single-lb-class.yaml, as follows:

   apiVersion: networking.k8s.io/v1 1
   kind: IngressClass
   metadata:
     name: single-lb 2
   spec:
     controller: ingress.k8s.aws/alb 3
     parameters:
       apiGroup: elbv2.k8s.aws 4
       kind: IngressClassParams 5
       name: single-lb-params 6

   1

   Defines the API group and version of the IngressClass resource.

   2

   Specifies the ingress class name.

   3

   Defines the controller name. The ingress.k8s.aws/alb value denotes that all ingress resources of this class should be managed by the AWS Load Balancer Controller.

   4

   Defines the API group of the IngressClassParams resource.

   5

   Defines the resource type of the IngressClassParams resource.

   6

   Defines the IngressClassParams resource name.

4. Create the IngressClass resource by running the following command:

   $ oc create -f sample-single-lb-class.yaml

5. Create the AWSLoadBalancerController resource YAML file, for example, sample-single-lb.yaml, as follows:

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     subnetTagging: Auto
     ingressClass: single-lb 1

   1

   Defines the name of the IngressClass resource.

6. Create the AWSLoadBalancerController resource by running the following command:

   $ oc create -f sample-single-lb.yaml

7. Create the Ingress resource YAML file, for example, sample-multiple-ingress.yaml, as follows:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-1 1
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing 2
       alb.ingress.kubernetes.io/group.order: "1" 3
       alb.ingress.kubernetes.io/target-type: instance 4
   spec:
     ingressClassName: single-lb 5
     rules:
     - host: example.com 6
       http:
           paths:
           - path: /blog 7
             pathType: Prefix
             backend:
               service:
                 name: example-1 8
                 port:
                   number: 80 9
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-2
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/group.order: "2"
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: single-lb
     rules:
     - host: example.com
       http:
           paths:
           - path: /store
             pathType: Prefix
             backend:
               service:
                 name: example-2
                 port:
                   number: 80
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-3
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/group.order: "3"
       alb.ingress.kubernetes.io/target-type: instance
   spec:
     ingressClassName: single-lb
     rules:
     - host: example.com
       http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: example-3
                 port:
                   number: 80

   1

   Specifies the ingress name.

   2

   Indicates the load balancer to provision in the public subnet to access the internet.

   3

   Specifies the order in which the rules from the multiple ingress resources are matched when the request is received at the load balancer.

   4

   Indicates that the load balancer will target OpenShift Container Platform nodes to reach the service.

   5

   Specifies the ingress class that belongs to this ingress.

   6

   Defines a domain name used for request routing.

   7

   Defines the path that must route to the service.

   8

   Defines the service name that serves the endpoint configured in the Ingress resource.

   9

   Defines the port on the service that serves the endpoint.

8. Create the Ingress resource by running the following command:

   $ oc create -f sample-multiple-ingress.yaml

Procedure

1. Create a YAML file that defines the AWSLoadBalancerController resource:

   Example add-tls-termination-albc.yaml file

   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     subnetTagging: Auto
     ingressClass: tls-termination 1

   1

   Defines the ingress class name. If the ingress class is not present in your cluster the AWS Load Balancer Controller creates one. The AWS Load Balancer Controller reconciles the additional ingress class values if spec.controller is set to ingress.k8s.aws/alb.

2. Create a YAML file that defines the Ingress resource:

   Example add-tls-termination-ingress.yaml file

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: <example> 1
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing 2
       alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 3
   spec:
     ingressClassName: tls-termination 4
     rules:
     - host: <example.com> 5
       http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: <example-service> 6
                   port:
                     number: 80

   1

   Specifies the ingress name.

   2

   The controller provisions the load balancer for ingress in a public subnet to access the load balancer over the internet.

   3

   The Amazon Resource Name (ARN) of the certificate that you attach to the load balancer.

   4

   Defines the ingress class name.

   5

   Defines the domain for traffic routing.

   6

   Defines the service for traffic routing.

1. Create the config map to contain the certificate authority (CA) bundle in the aws-load-balancer-operator namespace by running the following command:

   $ oc -n aws-load-balancer-operator create configmap trusted-ca

2. To inject the trusted CA bundle into the config map, add the config.openshift.io/inject-trusted-cabundle=true label to the config map by running the following command:

   $ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true

3. Update the AWS Load Balancer Operator subscription to access the config map in the AWS Load Balancer Operator deployment by running the following command:

   $ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'

4. After the AWS Load Balancer Operator is deployed, verify that the CA bundle is added to the aws-load-balancer-operator-controller-manager deployment by running the following command:

   $ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"

   Example output

   -rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
   trusted-ca

5. Optional: Restart deployment of the AWS Load Balancer Operator every time the config map changes by running the following command:

   $ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager

Procedure

1. Log in as a user with cluster-admin privileges.

2. Generate the default project template:

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. Use a text editor to modify the generated template.yaml file by adding objects or modifying existing objects.

4. The project template must be created in the openshift-config namespace. Load your modified template:

   $ oc create -f template.yaml -n openshift-config

5. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

6. Update the spec section to include the projectRequestTemplate and name parameters, and set the name of your uploaded project template. The default name is project-request.

   Project configuration resource with custom project template

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
   # ...
   spec:
     projectRequestTemplate:
       name: <template_name>
   # ...

7. After you save your changes, create a new project to verify that your changes were successfully applied.

Procedure

1. Edit the default template for a new project by running the following command:

   $ oc edit template <project_template> -n openshift-config

   Replace <project_template> with the name of the default template that you configured for your cluster. The default template name is project-request.

2. In the template, add each NetworkPolicy object as an element to the objects parameter. The objects parameter accepts a collection of one or more objects.

   In the following example, the objects parameter collection includes several NetworkPolicy objects.

   objects:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-same-namespace
     spec:
       podSelector: {}
       ingress:
       - from:
         - podSelector: {}
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-openshift-ingress
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               network.openshift.io/policy-group: ingress
       podSelector: {}
       policyTypes:
       - Ingress
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-kube-apiserver-operator
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               kubernetes.io/metadata.name: openshift-kube-apiserver-operator
           podSelector:
             matchLabels:
               app: kube-apiserver-operator
       policyTypes:
       - Ingress
   ...

3. Optional: Create a new project to confirm that your network policy objects are created successfully by running the following commands:

   1. Create a new project:

      $ oc new-project <project> 1

      1

      Replace <project> with the name for the project you are creating.

   2. Confirm that the network policy objects in the new project template exist in the new project:

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

Procedure

1. Create the following NetworkPolicy objects:

   1. A policy named allow-from-openshift-ingress.

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

      Note

      policy-group.network.openshift.io/ingress: "" is the preferred namespace selector label for OVN-Kubernetes.

   2. A policy named allow-from-openshift-monitoring:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. A policy named allow-same-namespace:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

   4. A policy named allow-from-kube-apiserver-operator:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-kube-apiserver-operator
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: openshift-kube-apiserver-operator
            podSelector:
              matchLabels:
                app: kube-apiserver-operator
        policyTypes:
        - Ingress
      EOF

      For more details, see New kube-apiserver-operator webhook controller validating health of webhook.

2. Optional: To confirm that the network policies exist in your current project, enter the following command:

   $ oc describe networkpolicy

   Example output

   Name:         allow-from-openshift-ingress
   Namespace:    example1
   Created on:   2020-06-09 00:28:17 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: ingress
     Not affecting egress traffic
     Policy Types: Ingress
   
   
   Name:         allow-from-openshift-monitoring
   Namespace:    example1
   Created on:   2020-06-09 00:29:57 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: monitoring
     Not affecting egress traffic
     Policy Types: Ingress

Procedure

1. To create the openshift-ingress-node-firewall namespace, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       pod-security.kubernetes.io/enforce: privileged
       pod-security.kubernetes.io/enforce-version: v1.24
     name: openshift-ingress-node-firewall
   EOF

2. To create an OperatorGroup CR, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ingress-node-firewall-operators
     namespace: openshift-ingress-node-firewall
   EOF

3. Subscribe to the Ingress Node Firewall Operator.

   1. To create a Subscription CR for the Ingress Node Firewall Operator, enter the following command:

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF

4. To verify that the Operator is installed, enter the following command:

   $ oc get ip -n openshift-ingress-node-firewall

   Example output

   NAME            CSV                                         APPROVAL    APPROVED
   install-5cvnz   ingress-node-firewall.4.17.0-202211122336   Automatic   true

5. To verify the version of the Operator, enter the following command:

   $ oc get csv -n openshift-ingress-node-firewall

   Example output

   NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
   ingress-node-firewall.4.17.0-202211122336   Ingress Node Firewall Operator   4.17.0-202211122336   ingress-node-firewall.4.17.0-202211102047   Succeeded

Procedure

1. Install the Ingress Node Firewall Operator:

   1. In the OpenShift Container Platform web console, click Operators → OperatorHub.
   2. Select Ingress Node Firewall Operator from the list of available Operators, and then click Install.
   3. On the Install Operator page, under Installed Namespace, select Operator recommended Namespace.
   4. Click Install.

2. Verify that the Ingress Node Firewall Operator is installed successfully:

   1. Navigate to the Operators → Installed Operators page.

   2. Ensure that Ingress Node Firewall Operator is listed in the openshift-ingress-node-firewall project with a Status of InstallSucceeded.

      Note

      During installation an Operator might display a Failed status. If the installation later succeeds with an InstallSucceeded message, you can ignore the Failed message.

      If the Operator does not have a Status of InstallSucceeded, troubleshoot using the following steps:

      • Inspect the Operator Subscriptions and Install Plans tabs for any failures or errors under Status.
      • Navigate to the Workloads → Pods page and check the logs for pods in the openshift-ingress-node-firewall project.

      • Check the namespace of the YAML file. If the annotation is missing, you can add the annotation workload.openshift.io/allowed=management to the Operator namespace with the following command:

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management

        Note

        For single-node OpenShift clusters, the openshift-ingress-node-firewall namespace requires the workload.openshift.io/allowed=management annotation.

Procedure

1. To create the bpfman namespace, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       pod-security.kubernetes.io/enforce: privileged
       pod-security.kubernetes.io/enforce-version: v1.24
     name: bpfman
   EOF

2. To create an OperatorGroup CR, enter the following command:

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: bpfman-operators
     namespace: bpfman
   EOF

3. Subscribe to the eBPF Manager Operator.

   1. To create a Subscription CR for the eBPF Manager Operator, enter the following command:

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bpfman-operator
        namespace: bpfman
      spec:
        name: bpfman-operator
        channel: alpha
        source: community-operators
        sourceNamespace: openshift-marketplace
      EOF

4. To verify that the Operator is installed, enter the following command:

   $ oc get ip -n bpfman

   Example output

   NAME            CSV                                 APPROVAL    APPROVED
   install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true

5. To verify the version of the Operator, enter the following command:

   $ oc get csv -n bpfman

   Example output

   NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
   bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded

Procedure

1. Install the eBPF Manager Operator:

   1. In the OpenShift Container Platform web console, click Operators → OperatorHub.
   2. Select eBPF Manager Operator from the list of available Operators, and if prompted to Show community Operator, click Continue.
   3. Click Install.
   4. On the Install Operator page, under Installed Namespace, select Operator recommended Namespace.
   5. Click Install.

2. Verify that the eBPF Manager Operator is installed successfully:

   1. Navigate to the Operators → Installed Operators page.

   2. Ensure that eBPF Manager Operator is listed in the openshift-ingress-node-firewall project with a Status of InstallSucceeded.

      Note

      During installation an Operator might display a Failed status. If the installation later succeeds with an InstallSucceeded message, you can ignore the Failed message.

      If the Operator does not have a Status of InstallSucceeded, troubleshoot using the following steps:

      • Inspect the Operator Subscriptions and Install Plans tabs for any failures or errors under Status.
      • Navigate to the Workloads → Pods page and check the logs for pods in the bpfman project.

Procedure

1. To download the manifest, enter the following command:

   $ curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml

2. To deploy the sample eBPF application, enter the following command:

   $ oc create -f go-xdp-counter-install-selinux.yaml

   Example output

   namespace/go-xdp-counter created
   serviceaccount/bpfman-app-go-xdp-counter created
   clusterrolebinding.rbac.authorization.k8s.io/xdp-binding created
   daemonset.apps/go-xdp-counter-ds created
   xdpprogram.bpfman.io/go-xdp-counter-example created
   selinuxprofile.security-profiles-operator.x-k8s.io/bpfman-secure created

3. To confirm that the eBPF sample application deployed successfully, enter the following command:

   $ oc get all -o wide -n go-xdp-counter

   Example output

   NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
   pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
   pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
   pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>
   
   NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
   daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter

4. To confirm that the example XDP program is running, enter the following command:

   $ oc get xdpprogram go-xdp-counter-example

   Example output

   NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
   go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess

5. To confirm that the XDP program is collecting data, enter the following command:

   $ oc logs <pod_name> -n go-xdp-counter

   Replace <pod_name> with the name of a XDP program pod, such as go-xdp-counter-ds-4m9cw.

   Example output

   2024/08/13 15:20:06 15016 packets received
   2024/08/13 15:20:06 93581579 bytes received
   
   2024/08/13 15:20:09 19284 packets received
   2024/08/13 15:20:09 99638680 bytes received
   
   2024/08/13 15:20:12 23522 packets received
   2024/08/13 15:20:12 105666062 bytes received
   
   2024/08/13 15:20:15 27276 packets received
   2024/08/13 15:20:15 112028608 bytes received
   
   2024/08/13 15:20:18 29470 packets received
   2024/08/13 15:20:18 112732299 bytes received
   
   2024/08/13 15:20:21 32588 packets received
   2024/08/13 15:20:21 113813781 bytes received

Procedure

1. Optional: To view the names of the EgressFirewall objects defined in your cluster, enter the following command:

   $ oc get egressfirewall --all-namespaces

2. To inspect a policy, enter the following command. Replace <policy_name> with the name of the policy to inspect.

   $ oc describe egressfirewall <policy_name>

   Example output

   Name:		default
   Namespace:	project1
   Created:	20 minutes ago
   Labels:		<none>
   Annotations:	<none>
   Rule:		Allow to 1.2.3.0/24
   Rule:		Allow to www.example.com
   Rule:		Deny to 0.0.0.0/0

Procedure

1. Find the name of the EgressFirewall object for the project. Replace <project> with the name of the project.

   $ oc get -n <project> egressfirewall

2. Optional: If you did not save a copy of the EgressFirewall object when you created the egress network firewall, enter the following command to create a copy.

   $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml

   Replace <project> with the name of the project. Replace <name> with the name of the object. Replace <filename> with the name of the file to save the YAML to.

3. After making changes to the policy rules, enter the following command to replace the EgressFirewall object. Replace <filename> with the name of the file containing the updated EgressFirewall object.

   $ oc replace -f <filename>.yaml

Procedure

1. Find the name of the EgressFirewall object for the project. Replace <project> with the name of the project.

   $ oc get -n <project> egressfirewall

2. Enter the following command to delete the EgressFirewall object. Replace <project> with the name of the project and <name> with the name of the object.

   $ oc delete -n <project> egressfirewall <name>

Procedure

1. Create a policy rule:

   1. Create a <policy_name>.yaml file where <policy_name> describes the egress policy rules.
   2. In the file you created, define an egress policy object.

2. Enter the following command to create the policy object. Replace <policy_name> with the name of the policy and <project> with the project that the rule applies to.

   $ oc create -f <policy_name>.yaml -n <project>

   In the following example, a new EgressFirewall object is created in a project named project1:

   $ oc create -f default.yaml -n project1

   Example output

   egressfirewall.k8s.ovn.org/v1 created

3. Optional: Save the <policy_name>.yaml file so that you can make changes later.