Uploaded image for project: 'Network Edge'
  1. Network Edge
  2. NE-1112

[GWAPI-TP] Develop a security model for tech preview


    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • None
    • Develop a Security Model
    • 8
    • False
    • None
    • False
    • To Do
    • OCPSTRAT-247 - Gateway API using Istio for Cluster Ingress - Tech Preview
    • OCPSTRAT-247Gateway API using Istio for Cluster Ingress - Tech Preview
    • 100% To Do, 0% In Progress, 0% Done
    • M
    • 0
    • 0.0

      Develop an initial security model, including any RBAC we need, as we uncover customer requirements.

      • Determine in which namespaces admins may create Gateways, at a minimum
      • Which namespaces are allowed by default
      • Which roles are allowed to do which operations (get, create, delete, etc) on which objects (gatewayclass, gateway, xRoute etc)
      • Do we want Istio  to watch all namespace and rely on RBAC to control who can create what.
      • Does istio-operator configure RBAC

      See https://issues.redhat.com/browse/OSSM-2221 and answer the question about whether it's ok to inject pods into the control plane namespace. 


      • the default RBAC policy
      • document outcomes on the open questions below, and customizations allowed by the user

      Open Questions

      • Do we allow project admins (or other users) to create Gateway objects in arbitrary namespaces?
        • Pro: The only way to configure custom certificates is to do so on the Gateway.
        • Con: Complicates the security model. 
          • To do: Research listener collapsing (NE-1000)
          • To do: Research Istio's conflict resolution.
        • Con: Increases the attack surface.
          • To do: Research whether users are restricted from modifying automatic deployments or reading certificates etc. that Istio injects, and what kind of attack surface these automatic deployments add. 
          • To do: Research whether users are allowed to create LoadBalancer-type services by default (how did we restrict this on OpenShift Starter/Online?). 
          • To do: Research how Service Mesh dealt with PodSecurityConstraints, and whether the existing solution is sufficient for automatic deployments in arbitrary namespaces. 
        • Con: Complicates DNS management.
          • Maybe not really an issue—if the project admin wants a DNS record for a custom domain, then OpenShift cannot create the DNS record anyway since OpenShift doesn't own the hosted zone.
          • Possible solution: Allow automatic deployments, but only manage DNS for Gateways in the openshift-ingress namespace. 

            Unassigned Unassigned
            cholman@redhat.com Candace Holman
            0 Vote for this issue
            2 Start watching this issue