Feature Overview

Each operator will deploy Kubernetes Network Policy resources into the namespaces it is responsible for. This was identified as a risk in the OCP Threat Model from product security.

Goals

• OpenShift GitOps operator pods have network policy that prevent unnecessary Ingress and Egress. This reduces the risk of cluster compromise in the even the operator pod is attacked.
• OpenShift GitOps operands (controller, webhook, Shared Resource CSI Driver) have network policy that prevent unnecessary Ingress and Egress. This reduces risk of cluster compromise in the event one of the operand pods is attacked.

Requirements

Use Cases

Without network policies, any pod within the Openshift cluster can communicate freely with other pods, regardless of their intended level of access. Attackers or compromised pods can exploit this lack of restriction to move laterally within the cluster and potentially compromise critical components. In the absence of network policies, pods may have unrestricted communication with external networks, this can result in unintended data leakage, where sensitive information is transmitted to unauthorized destinations.

Out of scope

• NA

Dependencies

• OLM support for installing Network Policies packaged in an OLM bundle.
• Kubernetes NetworkPolicy API

Background, and strategic fit

• OpenShift Network Policy Docs
• Upstream Kubernetes Network Policy Docs
• Developing Network Policies guide

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

• OLM is capable of deploying Network Policies for layered products

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

• Network policy must not break clusters that are air-gapped, or run behind a proxy.

Documentation/QE Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
< Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

This feature should be documented in a release note, as it is a security enhancement. Users will not be able to interact with this feature - therefore further documentation may not be needed here.

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

• Call to Action - OpenShift Network Policy
• Developing Network Policy
• Kubernetes Network Policy

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken down into epics.
• The feature has been stack ranked.
• Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).