Goal

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.

Red Hat Product Security has asked that we address this risk, by shipping OpenShift components with Kubernetes Network Policies ( OCPSTRAT-819 ) starting with the control plane and followed by the optional Red Hat OpenShift Operators. More information on the threat assessment from Product Security is available here.

Solution

1. Each operator will deploy Kubernetes Network Policy resources into the namespaces it is responsible for

1. Implement an enhancement to tag all OpenShift core namespaces with a label, and audit all such namespaces to ensure they have a default deny all policy in place for egress and ingress.  This will be used to identify namespaces missing policy in our tests, and later will be used to give customers visibility into the compliance level of third-party operators installed into OpenShift namespaces

Call for Action - prioritize

1. This activity had been planned for OCP 4.19 but it’s now clear that it will span both 4.19 and 4.20.
   A handful of OpenShift core namespaces are on track to ship network policies in the 4.19 timeframe. All other operators, including optional operators (e.g. logging, ServiceMesh, GitOps, etc.) and layered product operators (e.g. ACM, ACS, Quay, ODF, etc.), are expected to meet the 4.20 timeline. This is an Extended Update Support (EUS) release. 

1. OpenShift teams are requested to:

1. Develop and test tight ingress and egress K8s Network Policies to restrict communication to only the necessary communication.

1. Apply the network policies during the operator installation

1. Please look for the respective Jira feature for your team in OCPSTRAT-819 and add a feature for your operator if it is missing.

Resources:

1. Developing Network Policies

1. Cillium network policy interactive editor  

1. Slack #proj-ocp-shipping-network-policies-ocpstrat-819. 

• Say hello, share that you started. Share any concerns (or happy news!)

• For assistance please mention

• Engineering: Ben Bennett(@bbennett)

• PM: Boaz Michaely(@Boaz Michaely)

1. Talk to ACS team for their experience in shipping NP for many years and handling some tricky obstacles on the way

1. Related Enhancement for a migration path for network policies in all OpenShift namespaces: https://github.com/openshift/enhancements/pull/1720 

If you are not sure about what traffic connections you need to allow, inspecting a live system can help. For assistance with one of these tools please mention us on Slack

1. Network Observability Topology view (pic below)

1. ACS Network Graph 

User Stories

• High-Level goal-based user story, with context.
  "As a <VM owner/cluster administrator>, I want <to Achieve Some Goal>, so that <Some Reason/Context>."
• another user story

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

• Any additional details or decisions made/needed