-
Epic
-
Resolution: Unresolved
-
Major
-
None
-
Network Policy for CLO
-
Product / Portfolio Work
-
True
-
-
False
-
Green
-
NEW
-
Administer, Network, Release Notes, Troubleshoot
-
In Progress
-
OBSDA-1022 - Tailored 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
- 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