Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-7571

Network Policy for cluster-logging-operator

XMLWordPrintable

    • Network Policy for CLO
    • Product / Portfolio Work
    • True
    • Hide

      Unable to include a NP in the operator manifest because OLMv0 will block upgrade if NP exists. Waiting for an OLM backport which will not block on upgrade and will selectively apply the NP based upon the OCP version

      Show
      Unable to include a NP in the operator manifest because OLMv0 will block upgrade if NP exists. Waiting for an OLM backport which will not block on upgrade and will selectively apply the NP based upon the OCP version
    • False
    • Green
    • NEW
    • Administer, Network, Release Notes, Troubleshoot
    • In Progress
    • OBSDA-1022 - Tailored Network Policies for Cluster Logging Operator
    • OBSDA-1022Tailored Network Policies for Cluster Logging Operator
    • NEW
    • 13% To Do, 63% In Progress, 25% Done
    • Enhancement
    • S

      Goals

      • Provide network policies for the operator and operands to allow them to continue to function in the event an AdminNetworkPolicy is applied which would otherwise restrict their ingress and egress
      • Allowing administrators to edit policies provided by the operator

      Non-Goals

      • Tight restrictions of ingress and egress traffic for policies provided by the operator (e.g. allow everything in/out)

      Motivation

      The primary motivation is to ensure ClusterLogging continues to function should an administrator apply an AdminNetworkPolicy that would generally restrict ingress and egress.  Currently, the absence of a policy means "allow all". Once a policy is in place it potentially could cause log forwarding and ingestion to cease.  The intent is to initially distribute a policy that explicitly allows all traffic and revisit in future if providing tighter restrictions is necessary.

      Alternatives

      • Document and advise administrators how to manually create NetworkPolicy to support log collection and storage

      Acceptance Criteria

      • Verify the operator manifest includes a NetworkPolicy that applies to the operator (Currently blocked by changes in OLM that blocks upgrade if NP exists in the manifest)
      • Verify there is a unique network policy for each ClusterLogForwarder
      • Verify the NP allows all traffic in and out of the collector
      • Verify the collector continues to forwards logs after upgrade
      • Verify NP distributed by the operator and edited by an administrator are not reverted by the operator
      • Verify NP is "opt-in" by enabling NetworkPolicy for the collector
      • Verify NP is removed when it is disabled (un spec'd) for the collector

      When a AdminNetworkPolicy is applied that generally restricts ingress and egress to pods running in the cluster:

      • Verify the collector continues to forwards logs
      • Verify the collector continues to provide metrics
      • Verify the operator continues to provide metrics
      • Verify the operator continues to be discoverable by OLM (Is this a thing?)

      Risk and Assumptions

      Documentation Considerations

      • Identify the operators are now distributing NetworkPolicies
      • Document the network flow into/out of a collector so administrators can intelligently edit NP

      Open Questions

      1. Should we allow editing of the NetworkPolicy? CLO reverts changes to all other resource types.
        •  Per discussion with CEE, yes because some customers have tighter security requirements

      Additional Notes

              rh-ee-calee Calvin Lee
              jcantril@redhat.com Jeffrey Cantrill
              Qiaoling Tang Qiaoling Tang
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: