Configuring logging

Procedure

1. Create a service account for the collector. If you want to write logs to storage that requires a token for authentication, you must include a token in the service account.

2. Bind the appropriate cluster roles to the service account:

   Example binding command

   $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>

Procedure

1. Create a secret using your Base64 encoded Splunk HEC token.

   $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>

2. Create or edit the ClusterLogForwarder Custom Resource (CR) using the template below:

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name>
     namespace: openshift-logging
   spec:
     serviceAccount:
       name: <service_account_name> 

   1

   
     outputs:
       - name: splunk-receiver 

   2

   
         type: splunk 

   3

   
         splunk:
           url: '<http://your.splunk.hec.url:8088>' 

   4

   
           authentication:
             token:
               secretName: splunk-secret
               key: hecToken 

   5

   
           index: '{.log_type||"undefined"}' 

   6

   
           source: '{.log_source||"undefined"}' 

   7

   
           indexedFields: ['.log_type', '.log_source'] 

   8

   
           payloadKey: '.kubernetes' 

   9

   
           tuning:
               compression: gzip 

   10

   
     pipelines:
       - name: my-logs
         inputRefs: 

   11

   
           - application
           - infrastructure
         outputRefs:
           - splunk-receiver 

   12

   1

   The name of your service account.

   2

   Specify a name for the output.

   3

   Specify the output type as splunk.

   5

   Specify the name of the secret that contains your HEC token.

   4

   Specify the URL, including port, of your Splunk HEC.

   6

   Specify the name of the index to send events to. If you do not specify an index, the default index of the splunk server configuration is used. This is an optional field.

   7

   Specify the source of events to be sent to this sink. You can configure dynamic per-event values. This field is optional. If you do not specify a value, the value of the field will be determined by the log_type and log_source values. For example, see Default Splunk metadata key values.

   8

   Specify the fields to be added to the Splunk index. This field is optional. The values are stored directly in the index alongside the raw event data, allowing for faster search performance on those fields. However, indexed_fields fields increase storage use. Use them only for high-value fields that provide significant search benefits, for example, large datasets with frequent queries on specific fields. You can use complex and nested fields as indexed fields. These are automatically transformed to meet Splunk’s requirements.

   9

   Specify the record field to be used as the payload. By default, the payloadKey field is not set, which means the complete log record is forwarded as the payload. Use the payloadKey field carefully. Selecting a single field as the payload may cause other important information in the log to be dropped, potentially leading to inconsistent or incomplete log events.

   10

   Specify the compression configuration, which can be either gzip or none. The default value is none. This field is optional.

   11

   Specify the input names.

   12

   Specify the name of the output to use when forwarding logs with this pipeline.

Procedure

1. Create or edit a YAML file that defines the ClusterLogForwarder CR object:

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: collector
   spec:
     managementState: Managed
     outputs:
     - name: rsyslog-east 

   1

   
       syslog:
         appName: <app_name> 

   2

   
         enrichment: KubernetesMinimal
         facility: <facility_value> 

   3

   
         msgId: <message_ID> 

   4

   
         payloadKey: <record_field> 

   5

   
         procId: <process_ID> 

   6

   
         rfc: <RFC3164_or_RFC5424> 

   7

   
         severity: informational 

   8

   
         tuning:
           deliveryMode: <AtLeastOnce_or_AtMostOnce> 

   9

   
         url: <url> 

   10

   
       tls: 

   11

   
         ca:
           key: ca-bundle.crt
           secretName: syslog-secret
       type: syslog
     pipelines:
     - inputRefs: 

   12

   
       - application
       name: syslog-east 

   13

   
       outputRefs:
       - rsyslog-east
     serviceAccount: 

   14

   
       name: logcollector

   1

   Specify a name for the output.

   2

   Optional: Specify the value for the APP-NAME part of the syslog message header. The value must conform with The Syslog Protocol. The value can be a combination of static and dynamic values consisting of field paths followed by ||, and then followed by another field path or a static value. The maximum length of the final values is truncated to 48 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with ||. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}.

   3

   Optional: Specify the value for Facility part of the syslog-msg header.

   4

   Optional: Specify the value for MSGID part of the syslog-msg header. The value can be a combination of static and dynamic values consisting of field paths followed by ||, and then followed by another field path or a static value. The maximum length of the final values is truncated to 32 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with ||. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}.

   5

   Optional: Specify the record field to use as the payload. The payloadKey value must be a single field path encased in single curly brackets {}. Example: {.<value>}.

   6

   Optional: Specify the value for the PROCID part of the syslog message header. The value must conform with The Syslog Protocol. The value can be a combination of static and dynamic values consisting of field paths followed by ||, and then followed by another field path or a static value. The maximum length of the final values is truncated to 48 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with ||. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}.

   7

   Optional: Set the RFC that the generated messages conform to. The value can be RFC3164 or RFC5424.

   8

   Optional: Set the severity level for the message. For more information, see The Syslog Protocol.

   9

   Optional: Set the delivery mode for log forwarding. The value can be either AtLeastOnce, or AtMostOnce.

   10

   Specify the absolute URL with a scheme. Valid schemes are: tcp, tls, and udp. For example: tls://syslog-receiver.example.com:6514.

   11

   Specify the settings for controlling options of the transport layer security (TLS) client connections.

   12

   Specify which log types to forward by using the pipeline: application, infrastructure, or audit.

   13

   Specify a name for the pipeline.

   14

   The name of your service account.

2. Create the CR object:

   $ oc create -f <filename>.yaml

Procedure

1. Create an IAM policy that grants permissions to write logs to CloudWatch.

   1. Create a file, for example cw-iam-role-policy.json, with the following content:

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "logs:PutLogEvents",
                      "logs:CreateLogGroup",
                      "logs:PutRetentionPolicy",
                      "logs:CreateLogStream",
                      "logs:DescribeLogGroups",
                      "logs:DescribeLogStreams"
                  ],
                  "Resource": "arn:aws:logs:*:*:*"
              }
          ]
      }

   2. Create the IAM policy based on the previous policy definition by running the following command:

      aws iam create-policy \
          --policy-name cluster-logging-allow \
          --policy-document file://cw-iam-role-policy.json

      Note the Arn value of the created policy.

2. Create a trust policy to allow the logging service account to assume an IAM role:

   1. Create a file, for example cw-trust-policy.json, with the following content:

      {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "Federated": "arn:aws:iam::123456789012:oidc-provider/<OPENSHIFT_OIDC_PROVIDER_URL>" 

      1

      
              },
              "Action": "sts:AssumeRoleWithWebIdentity",
              "Condition": {
                  "StringEquals": {
                      "<OPENSHIFT_OIDC_PROVIDER_URL>:sub": "system:serviceaccount:openshift-logging:logcollector" 

      2

      
                  }
              }
          }
      ]
      }

      1

      Replace <OPENSHIFT_OIDC_PROVIDER_URL> with the URL of your Red Hat OpenShift Logging OIDC URL.

      2

      The namespace and service account must match the namespace and service account that the log forwarder uses.

3. Create an IAM role based on the previously defined trust policy by running the following command:

   $ aws iam create-role --role-name openshift-logger --assume-role-policy-document file://cw-trust-policy.json

   Note the Arn value of the created role.

4. Attach the policy to the role by running the following command:

   $ aws iam put-role-policy \
         --role-name openshift-logger --policy-name cluster-logging-allow \
         --policy-document file://cw-role-policy.json

Procedure

1. Create or update a ClusterLogForwarder custom resource (CR):

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name>
   spec:
     serviceAccount:
       name: <service_account_name>
     outputs:
      - name: s3-output
        type: s3
        s3:
          keyPrefix: 's3{.log_type||"missing"}'
          bucket: <bucket_name>
          region: us-east-2
          authentication:
            type: iamRole
            iamRole:
              roleARN:
                key: role_arn
                secretName: sts-secret
              token:
                from: serviceAccount
     pipelines:
       - name: to-s3
         inputRefs:
           - infrastructure
           - audit
           - application
         outputRefs:
           - s3-output

   • keyPrefix: The S3 key prefix for log objects. You can use static or dynamic values consisting of field paths separated by || and ending with a static fallback value.
   • bucket: The S3 bucket name for log storage.

2. Apply the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

1. Initial Authentication: The collector authenticates to the AWS account of your cluster using Identity and Access Management (IAM) roles or access keys.
2. Role Assumption: After initial authentication, the collector assumes a role in the target AWS account.
3. Log Forwarding: The collector forwards logs to CloudWatch or S3 bucket in the target account using credentials of the assumed role.

Procedure

1. Create an initial account in your cluster account to assume the target role with the required permissions.

   The initial account can either be a user or an IAM role. This account assumes the target role.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": "arn:aws:iam::<target-aws-account-id>:role/target-logging-role"
           }
       ]
   }

2. In your target role, create a trust policy and specify the initial cluster role, and optionally an external id.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam:::<role_or_user>/<role-name_or_user-name>"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "sts:ExternalId": "<your-unique-external-id>"
                   }
               }
           }
       ]
   }

   Set the Principal.AWS field as follows:

   • If the initial account is a user, use the format:

     arn:aws:iam::<aws-account-id>:user/<user-name>

   • If the initial account is an IAM role, use the format:

     arn:aws:iam::<aws-account-id>:role/<role-name>

3. Configure CloudWatch or S3 permissions in the target role depending on whether you want to forward logs to the CloudWatch or S3 output:

   CloudWatch permissions

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "logs:CreateLogGroup",
                   "logs:CreateLogStream",
                   "logs:PutLogEvents",
                   "logs:DescribeLogGroups",
                   "logs:DescribeLogStreams"
               ],
               "Resource": "*"
           }
       ]
   }

   S3 permissions

   {
       "Version": "2012-10-17",
       "Statement": [
           {
           "Sid": "AllowRoleToPutObjects",
           "Effect": "Allow",
           "Principal": {
               "AWS": "<assumerole_arn>"
           },
           "Action": [
               "s3:PutObject",
               "s3:PutObjectAcl"
           ],
           "Resource": [
               "arn:<aws_partition>:s3:::<s3_bucket>",
               "arn:<aws_partition>:s3:::<s3_bucket>/*"
           ]
           }
       ]
   }

Procedure

1. Extract the existing ClusterLogForwarder configuration and save it as a local file.

   $ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml

   Where:

   • <name> is the name of the ClusterLogForwarder instance you want to configure.
   • <namespace> is the namespace where you created the ClusterLogForwarder instance, for example openshift-logging.
   • <filename> is the name of the local file where you save the configuration.

2. Add a configuration to drop unwanted log records to the filters spec in the ClusterLogForwarder CR.

   Example ClusterLogForwarder CR

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     # ...
     filters:
     - name: drop-filter
       type: drop 

   1

   
       drop: 

   2

   
         - test: 

   3

   
           - field: .kubernetes.labels."app.version-1.2/beta" 

   4

   
             matches: .+ 

   5

   
           - field: .kubernetes.pod_name
             notMatches: "my-pod" 

   6

   
     pipelines:
     - name: my-pipeline 

   7

   
       filterRefs:
       - drop-filter
     # ...

   1

   Specify the type of filter. The drop filter drops log records that match the filter configuration.

   2

   Specify configuration options for the drop filter.

   3

   Specify conditions for tests to evaluate whether the filter drops a log record.

   4

   Specify dot-delimited paths to fields in log records.

   • Each path segment can contain alphanumeric characters and underscores, a-z, A-Z, 0-9, _, for example, .kubernetes.namespace_name.
   • If segments contain different characters, the segment must be in quotes, for example, .kubernetes.labels."app.version-1.2/beta".
   • You can include several field paths in a single test configuration, but they must all evaluate to true for the test to pass and the drop filter to apply.

   5

   Specify a regular expression. If log records match this regular expression, they are dropped.

   6

   Specify a regular expression. If log records do not match this regular expression, they are dropped.

   7

   Specify the pipeline that uses the drop filter.

   Note

   You can set either the matches or notMatches condition for a single field path, but not both.

   Example configuration that keeps only high-priority log records

   # ...
   filters:
   - name: important
     type: drop
     drop:
       - test:
         - field: .message
           notMatches: "(?i)critical|error"
         - field: .level
           matches: "info|warning"
   # ...

   Example configuration with several tests

   # ...
   filters:
   - name: important
     type: drop
     drop:
       - test: 

   1

   
         - field: .kubernetes.namespace_name
           matches: "openshift.*"
       - test: 

   2

   
         - field: .log_type
           matches: "application"
         - field: .kubernetes.pod_name
           notMatches: "my-pod"
   # ...

   1

   The filter drops logs that contain a namespace that starts with openshift.

   2

   The filter drops application logs that do not have my-pod in the pod name.

3. Apply the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

Procedure

1. Add a configuration for a filter to the input spec in the ClusterLogForwarder CR.

   The following example shows how to configure the ClusterLogForwarder CR to include logs based on label expressions or matched label key/values:

   Example ClusterLogForwarder CR

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   # ...
   spec:
     serviceAccount:
       name: <service_account_name>
     inputs:
       - name: mylogs
         application:
           selector:
             matchExpressions:
             - key: env 

   1

   
               operator: In 

   2

   
               values: ["prod", "qa"] 

   3

   
             - key: zone
               operator: NotIn
               values: ["east", "west"]
             matchLabels: 

   4

   
               app: one
               name: app1
         type: application
   # ...

   1

   Specifies the label key to match.

   2

   Specifies the operator. Valid values include: In, NotIn, Exists, and DoesNotExist.

   3

   Specifies an array of string values. If the operator value is either Exists or DoesNotExist, the value array must be empty.

   4

   Specifies an exact key or value mapping.

2. Apply the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

Procedure

1. Extract the existing ClusterLogForwarder configuration and save it as a local file.

   $ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml

   Where:

   • <name> is the name of the ClusterLogForwarder instance you want to configure.
   • <namespace> is the namespace where you created the ClusterLogForwarder instance, for example openshift-logging.
   • <filename> is the name of the local file where you save the configuration.

2. Add a configuration to prune log records to the filters spec in the ClusterLogForwarder CR.

   Important

   If you specify both in and notIn parameters, the notIn array takes precedence over in during pruning. After records are pruned by using the notIn array, they are then pruned by using the in array.

   Example ClusterLogForwarder CR

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     serviceAccount:
       name: my-account
     filters:
     - name: prune-filter
       type: prune 

   1

   
       prune: 

   2

   
         in: [.kubernetes.annotations, .kubernetes.namespace_id] 

   3

   
         notIn: [.kubernetes,.log_type,.message,."@timestamp",.log_source] 

   4

   
     pipelines:
     - name: my-pipeline 

   5

   
       filterRefs: ["prune-filter"]
     # ...

   1

   Specify the type of filter. The prune filter prunes log records by configured fields.

   2

   Specify configuration options for the prune filter.

   • The in and notIn fields are arrays of dot-delimited paths to fields in log records.
   • Each path segment can contain alpha-numeric characters and underscores, a-z, A-Z, 0-9, _, for example, .kubernetes.namespace_name.
   • If segments contain different characters, the segment must be in quotes, for example, .kubernetes.labels."app.version-1.2/beta".

   3

   Optional: Specify fields to remove from the log record. The log collector keeps all other fields.

   4

   Optional: Specify fields to keep in the log record. The log collector removes all other fields.

   5

   Specify the pipeline that the prune filter is applied to.

   Important

   • The filters cannot remove the .log_type, .log_source, .message fields from the log records. You must include them in the notIn field.
   • If you use the googleCloudLogging output, you must include .hostname in the notIn field.

3. Apply the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

Procedure

1. Modify the ClusterLogForwarder CR to add configuration for the http receiver input:

   Example ClusterLogForwarder CR

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <clusterlogforwarder_name> 

   1

   
     namespace: <namespace>
   # ...
   spec:
     serviceAccount:
       name: <service_account_name>
     inputs:
     - name: http-receiver 

   2

   
       type: receiver
       receiver:
         type: http 

   3

   
         port: 8443 

   4

   
         http:
           format: kubeAPIAudit 

   5

   
     outputs:
     - name: <output_name>
       type: http
       http:
         url: <url>
     pipelines: 

   6

   
       - name: http-pipeline
         inputRefs:
           - http-receiver
         outputRefs:
           - <output_name>
   # ...

   1

   Specify a name for the ClusterLogForwarder CR.

   2

   Specify a name for your input receiver.

   3

   Specify the input receiver type as http.

   4

   Optional: Specify the port that the input receiver listens on. This must be a value between 1024 and 65535. The default value is 8443 if this is not specified.

   5

   Currently, only the kube-apiserver webhook format is supported for http input receivers.

   6

   Configure a pipeline for your input receiver.

2. Apply the changes to the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

3. Verify that the collector is listening on the service that has a name in the <clusterlogforwarder_resource_name>-<input_name> format by running the following command:

   $ oc get svc

   Example output

   NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
   collector                 ClusterIP   172.30.85.239    <none>        24231/TCP          3m6s
   collector-http-receiver   ClusterIP   172.30.205.160   <none>        8443/TCP           3m6s

   In the example, the service name is collector-http-receiver.

Verification

1. Extract the certificate authority (CA) certificate file by running the following command:

   $ oc extract cm/openshift-service-ca.crt -n <namespace>

   Note

   If the CA in the cluster where the collectors are running changes, you must extract the CA certificate file again.

2. As an example, use the curl command to send logs by running the following command:

   $ curl --cacert <openshift_service_ca.crt> https://collector-http-receiver.<namespace>.svc:8443 -XPOST -d '{"<prefix>":"<message>"}'

   Replace <openshift_service_ca.crt> with the extracted CA certificate file.

Procedure

1. Grant the collect-infrastructure-logs cluster role to the service account by running the following command:

   Example binding command

   $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z logcollector

2. Modify the ClusterLogForwarder CR to add configuration for the syslog receiver input:

   Example ClusterLogForwarder CR

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <clusterlogforwarder_name> 

   1

   
     namespace: <namespace>
   # ...
   spec:
     serviceAccount:
       name: <service_account_name> 

   2

   
     inputs:
       - name: syslog-receiver 

   3

   
         type: receiver
         receiver:
           type: syslog 

   4

   
           port: 10514 

   5

   
     outputs:
     - name: <output_name>
       lokiStack:
         authentication:
           token:
             from: serviceAccount
         target:
           name: logging-loki
           namespace: openshift-logging
       tls: 

   6

   
         ca:
           key: service-ca.crt
           configMapName: openshift-service-ca.crt
       type: lokiStack
   # ...
     pipelines: 

   7

   
       - name: syslog-pipeline
         inputRefs:
           - syslog-receiver
         outputRefs:
           - <output_name>
   # ...

   1 2

   Use the service account that you granted the collect-infrastructure-logs permission in the previous step.

   3

   Specify a name for your input receiver.

   4

   Specify the input receiver type as syslog.

   5

   Optional: Specify the port that the input receiver listens on. This must be a value between 1024 and 65535.

   6

   If TLS configuration is not set, the default certificates will be used. For more information, run the command oc explain clusterlogforwarders.spec.inputs.receiver.tls.

   7

   Configure a pipeline for your input receiver.

3. Apply the changes to the ClusterLogForwarder CR by running the following command:

   $ oc apply -f <filename>.yaml

4. Verify that the collector is listening on the service that has a name in the <clusterlogforwarder_resource_name>-<input_name> format by running the following command:

   $ oc get svc

   Example output

   NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
   collector                   ClusterIP   172.30.85.239    <none>        24231/TCP          33m
   collector-syslog-receiver   ClusterIP   172.30.216.142   <none>        10514/TCP          2m20s

   In this example output, the service name is collector-syslog-receiver.

Verification

1. Extract the certificate authority (CA) certificate file by running the following command:

   $ oc extract cm/openshift-service-ca.crt -n <namespace>

   Note

   If the CA in the cluster where the collectors are running changes, you must extract the CA certificate file again.

2. As an example, use the curl command to send logs by running the following command:

   $ curl --cacert <openshift_service_ca.crt> collector-syslog-receiver.<namespace>.svc:10514  “test message”

   Replace <openshift_service_ca.crt> with the extracted CA certificate file.

Procedure

1. Update the ClusterLogForwarder CR:

   apiVersion: observability.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: my-forwarder
     namespace: openshift-logging
   spec:
     collector:
       networkPolicy:
         ruleSet: <RestrictIngressEgress_or_AllowAllIngressEgress>
     # ...

   Where the value for the ruleSet field can be either RestrictIngressEgress or AllowAllIngressEgress.

2. Apply the configuration by running the following command:

   $ oc apply -f <filename>.yaml

Procedure

1. Update the LogFileMetricExporter CR:

   apiVersion: logging.openshift.io/v1alpha1
   kind: LogFileMetricExporter
   metadata:
     name: my-lfme
     namespace: openshift-logging
   spec:
     networkPolicy:
       ruleSet: <AllowAllIngressEgress_or_AllowIngressMetrics>
   #...

   Where the value for the ruleSet field can be either AllowAllIngressEgress or AllowIngressMetrics.

2. Apply the configuration by running the following command:

   $ oc apply -f <filename>.yaml

Procedure

1. Create an AdminNetworkPolicy rule:

   apiVersion: policy.networking.k8s.io/v1alpha1
   kind: AdminNetworkPolicy
   metadata:
     name: allow-logging-collector-delegation
   spec:
     priority: 50 # Adjust based on your cluster's ANP priority scheme. Lower number means higher priority
     subject:
       pods: # Target the pods in openshift-logging namespace
         namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: openshift-logging
         podSelector:
           matchLabels:
             app.kubernetes.io/name: <name>
             app.kubernetes.io/instance: <instance>
             app.kubernetes.io/managed-by: cluster-logging-operator
             app.kubernetes.io/part-of: cluster-logging
             app.kubernetes.io/component: <component>
     ingress:
       - name: "delegate-to-collector-ingress"
         action: "Pass"
         from:
           # Select all pods in all namespaces as the source.
           - pods:
               namespaceSelector: {}
               podSelector: {}
     egress:
       - name: "delegate-to-collector-egress"
         action: "Pass"
         to:
           # Select all pods in all namespaces for internal traffic.
           - pods:
               namespaceSelector: {}
               podSelector: {}
           # Select all external destinations for egress traffic.
           - networks:
             - "0.0.0.0/0"
             - "::/0"

   To apply this network policy to all the resources in a namespace, remove app.kubernetes.io/name, app.kubernetes.io/instance, and app.kubernetes.io/component fields. To apply the admin network policy to specific resources, define the fields as follows:

   • Replace <name> with the name of the collector or the LogFileMetricExporter resource.
   • Replace <instance> with the instance name of the collector or the LogFileMetricExporter resource.
   • Replace <component> with the value collector or logfilesmetricexporter.

2. Apply the AdminNetworkPolicy rule by running the following command:

   $ oc apply -f <filename>.yaml