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

 

 

 

 

 

 

 

Stages of content journey

1. Discover

• Objective: Raise awareness about the importance of Network Policies in OpenShift and the MTV feature.
• Content Types:
  • Blog Posts: Articles discussing the risks of unrestricted pod communication and the benefits of implementing Network Policies.
  • Webinars: Live sessions featuring experts discussing security best practices in OpenShift, including the role of Network Policies.
  • Infographics: Visual representations of potential attack vectors in OpenShift without Network Policies and how MTV can mitigate these risks.
  • Case Studies: Real-world examples of organizations that faced data leaks or attacks due to lack of network restrictions.

2. Learn

• Objective: Provide in-depth knowledge about Network Policies and how to implement them using the MTV feature.
• Content Types:
  • Documentation: Comprehensive guides on Kubernetes Network Policies, including syntax, examples, and best practices.
  • Tutorials: Step-by-step instructions on how to create and apply Network Policies using the MTV feature.
  • Videos: Short instructional videos demonstrating the creation and application of Network Policies in OpenShift.
  • FAQs: A collection of frequently asked questions addressing common concerns and misconceptions about Network Policies.

3. Try

• Objective: Encourage users to experiment with the MTV feature and Network Policies in a safe environment.
• Content Types:
  • Hands-on Labs: Interactive labs where users can practice creating and applying Network Policies using the MTV feature in a sandbox environment.
  • Sample Projects: Pre-configured projects that users can deploy to see the MTV feature in action, including example Network Policies.
  • Community Forums: Platforms for users to share their experiences, ask questions, and provide feedback on their trials with the MTV feature.

4. Adopt

• Objective: Support users in integrating the MTV feature and Network Policies into their production environments.
• Content Types:
  • Implementation Guides: Detailed instructions on how to integrate the MTV feature into existing OpenShift environments, including best practices for deployment.
  • Checklists: Step-by-step checklists to ensure all necessary configurations and policies are in place before going live.
  • Support Resources: Access to support channels, including forums, chat, and ticketing systems for troubleshooting and assistance during adoption.
  • Success Stories: Testimonials and case studies from organizations that successfully implemented the MTV feature and Network Policies.

5. Expand

• Objective: Encourage users to explore advanced features and further enhance their OpenShift security posture.
• Content Types:
  • Advanced Tutorials: Guides on creating complex Network Policies, including multi-namespace policies and integration with other security tools.
  • Webinars and Workshops: Sessions focused on advanced use cases and strategies for optimizing Network Policies and security in OpenShift.
  • Community Contributions: Encourage users to share their own Network Policy configurations and experiences, fostering a collaborative environment.
  • Feedback Mechanisms: Channels for users to provide feedback on the MTV feature and suggest improvements or additional resources.

By following this structured content journey, users can effectively discover, learn, try, adopt, and expand their use of the Migration Toolkit for Virtualization feature, ultimately enhancing the security of their OpenShift environments through tailored Network Policies.

 

 

What is the main user goal aka job to be done?

There are several user goals (jobs to be done) that can be defined in the documentation of the Migration Toolkit for Virtualization (MTV) in the context of protecting OpenShift from unintended data leaks and attacks via tailored Network Policies:

1. As a Security Administrator, I want to implement tailored Network Policies in OpenShift so that I can restrict pod communication and enhance the security posture of the cluster.

1. As a DevOps Engineer, I want to automate the deployment of Kubernetes Network Policies during operator installation so that I can ensure consistent security configurations across all namespaces.

1. As a Compliance Officer, I want to audit OpenShift core namespaces for default deny policies so that I can ensure compliance with security standards and regulations.

1. As a Cloud Architect, I want to tag OpenShift namespaces with labels for easy identification so that I can quickly assess the security compliance level of third-party operators installed in the environment.

1. As a System Administrator, I want to test and validate Network Policies in a controlled environment so that I can ensure they function as intended before deploying them to production.

Content journey

https://spaces.redhat.com/display/MMSDOCS/Implementing+OpenShift+Network+Policies+in+MTV+content+journey