Details
-
Epic
-
Resolution: Unresolved
-
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
-
-
0
-
0%
-
0
-
0.0
Description
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.
Deliverables:
- 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.
- Con: Complicates the security model.
