Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-2501

Namespace-based NetObserv Configuration for Multi-Tenant Environments

XMLWordPrintable

    • Product / Portfolio Work
    • None
    • 100% To Do, 0% In Progress, 0% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • L
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Feature Summary

      Support some per-tenant configuration of Network Observability without requiring cluster admin privileges, in multi-tenant deployments. ** 

      Feature Overview  

      In multi-tenant OpenShift environments, users have expressed the need for more autonomy in configuring Network Observability at the tenant (namespace) level, without requiring cluster-admin privileges. For example, currently, flow collection and subnet labeling configurations are global and managed exclusively by cluster admins.

      This feature introduces a namespace-scoped Custom Resource Definition (CRD) to complement the global FlowCollector configuration and enable project admins (tenant admins) to manage flow collection and subnet labeling within their own namespaces.

      Cluster admins will retain control through global defaults and policy boundaries.

      Goals

      • Project admins can enable or disable NetObserv flow collection on a per-namespace basis.
      • Project admins can define subnet labels for external workloads relevant to their namespaces.
      • Project admins may also define per-tenant quick filters for simplified flow analysis.
      • Cluster admins can globally enable or disable per-tenant configuration.
      • Cluster admins can define default behavior for unconfigured tenants (flow collection enabled or disabled by default).
      • Cluster admins can maintain a list of non-tenant namespaces (e.g., openshift-*) where flow collection is always enabled.
      • The feature improves multi-tenancy usability while preserving cluster-wide governance.

      Requirements:

      Functional Requirements

      1. A new namespace-scoped CRD (e.g., NamespaceFlowCollectorConfig) must be created.
      2. The CRD must allow project admins to:
        • Enable/disable flow collection for their namespace.
        • Define subnet labels for external workloads.
        • Configure per-tenant quick filters.
      3. The global FlowCollector CRD must include options for cluster admins to:
        • Enable or disable per-tenant configuration globally.
        • Set a default behavior (flow collection enabled or disabled by default for unconfigured tenants).
        • Maintain a list of non-tenant namespaces where flow collection is always enabled.
      4. If per-tenant configuration is disabled globally, namespace-level CRs must be ignored.
      5. Default values must apply when a namespace does not provide a CR.

      Non-Functional Requirements

      • The solution must respect RBAC: only project admins can create/edit namespace-level CRs for their namespaces.
      • The feature must be backward compatible with existing cluster-wide NetObserv configurations.
      • Documentation must be updated to describe usage for both cluster admins and project admins.
      • Performance should not be significantly impacted when enabling per-tenant configurations at scale.

       

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both  
      Classic (standalone cluster)  
      Hosted control planes  
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network  
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x)  
      Operator compatibility  
      Backport needed (list applicable versions)  
      UI need (e.g. OpenShift Console, dynamic plugin, OCM)  
      Other (please specify)  

      Use Cases (Optional):

       

      • As a project admin, I want to enable flow collection only for my namespace so that I can analyze traffic relevant to my applications, without needing cluster-admin privileges.
      • As a project admin, I want to configure subnet labels for my namespace, so I can categorize traffic to and from my external workloads.
      • As a project admin, I want to define quick filters, so I can easily analyze traffic patterns relevant to my team.
      • As a cluster admin, I want to retain control over global defaults and ensure non-tenant namespaces are always monitored, so compliance and visibility requirements are not compromised.
      • As a cluster admin, I want to decide whether flow collection should be enabled or disabled by default for namespaces that do not explicitly configure it, ensuring flexibility across different environments.

      Questions to Answer (Optional):

      • Is it accurate to assume namespace = tenant?

      Out of Scope

      •  

      Background

      •  

      Customer Considerations

      •  

      Documentation Considerations

      •  

      Interoperability Considerations

      • This feature must work in Hosted Control Plane environments

              mcurry@redhat.com Marc Curry
              mcurry@redhat.com Marc Curry
              None
              Julien Pinsonneau
              Joel Takvorian Joel Takvorian
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: