Kubeflow Pipelines and Jupyter Notebooks Ingress authentication and NetworkPolicy interoperability for public exposure prevention

Kubeflow Pipelines and Jupyter Notebooks coexist within a single Kubernetes deployment, each exposing services through Ingress and service-type configurations that govern external access. A core interoperability question emerges from the interaction between Jupyter Notebook Ingress authentication—TLS secrets and OIDC middleware—and the absence of default NetworkPolicy objects that leave MLflow tracking server endpoints in Kubeflow Pipelines unrestricted. Documented behavior indicates that without an explicit TLS secret and host-based authentication, the default Ingress may route external traffic to the notebook service, while a LoadBalancer-type MLflow service can expose artifact endpoints over HTTP if firewall rules are absent. In Kubeflow releases preceding the gatekeeper redesign, Ingress defaults permitted broader external access; version upgrades may migrate services behind a gatekeeper but can leave legacy endpoints with prior access patterns reachable. Given these overlapping surface areas, what mechanism ensures that authentication and network isolation synchronize consistently across both service families without introducing unintended public exposure?

• How do Ingress TLS and authentication annotations interact with dynamically generated NetworkPolicy rules for Kubeflow Pipelines services?
• Can a misconfigured RBAC role binding for the authorization proxy independently expose notebook or pipeline endpoints?
• What is the expected behavior when an Ingress host lacks a TLS secret but a NetworkPolicy restricts inbound traffic to a specific service account?