-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
None
Feature Overview (aka. Goal Summary)
The control plane thread assessment document listed networking policies as a potential threat here - https://docs.google.com/document/d/1B7ZCfwEfl0AqPoQHqeoAIuBQNoCMAeWwEkMSV_TItjg/edit#bookmark=id.ywnfpwunk3t8
Goals (aka. expected user outcomes)
| 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. |
Requirements (aka. Acceptance Criteria):
A Kube NP YAML file is delivered with OpenShift Auth operator and OAuth server components, that restricts ingress as well as egress communication to only the necessary communication. We may also choose to deliver a default Admin Network Policy that is applied when an OpenShift cluster is installed.
A CIS OpenShift benchmark scan shows that we have comply with item 5.3.2 for all control plane components.
Note: AdminNetworkingPolicy is a K8s mechanism to set strict secure rules for the cluster. The work under this Jira card should consider and prefer the use of AdminNetworkPolicy resources.
Use Cases (Optional):
Include use case diagrams, main success scenarios, alternative flow scenarios. Initial completion during Refinement status.
User stories highlighted https://docs.google.com/document/d/1Q3vilrgXksQfniuT4bq12chl0AbwX-u6904mSU5zFFo/edit#heading=h.1cojzpn9k1oq
Questions to Answer (Optional):
Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.
Out of Scope
- TBD at the moment this is for Ingress and Egress for the Auth Operator and OAuth Components
- TBD on turning on settings for upgraded clusters by default
Background
A default installation of the OpenShift control plane will be able to meet another CIS Kube benchmark control which will reduce friction with prospects and customers.
A default installation of the OpenShift control plane will meet ProdSec guidance.
A default installation of the OpenShift control plane will have additional hardening that moves the deployment toward zero trust.
Customer Considerations
- Customers should be able to not be impacted by this change when they upgrade to 4.18
- Fresh Installs will have this setting added by Default
- TBD on knobs to be able to revert to previous state without Network Policy
Documentation Considerations
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.
Interoperability Considerations
Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?
This impacts Managed Openshift products that use OpenShift Auth Operator such as ROSA, ARO
HCP Team will need to add this to their Authentication Operator.
