Gateway API: Guide for removing ClusterRole privileges (Remove unnecessary permissions / ... could lead to takeover of the cluster)

[erikschul]

Please describe the problem you have

I'd like to use Contour with Gateway API, and unfortunately the suggested installation method contains a ClusterRole with full read privileges to all secrets/configmaps, as well as creating deployments.

Since Envoy is publicly exposed, a vulnerability might be used to attack the cluster (although it'd have to jump to the Contour control plane first), as discussed before:

• A potential risk in contour that could lead to takeover of the cluster #6384
• Bug: Remove unnecessary permissions in Helm Charts #6475

Would it be possible for ProjectContour to explicitly support an installation method with reduced privileges?
I'm concerned about overriding these roles and having instability in production because it deviates from the recommended defaults.

Specifically, I'd be happy with:

• installing Gateway Provisioner into projectcontour namespace
• creating all Gateway (Contour/Envoy) instances in that same namespace
• creating all Certificate (TLS secrets) in the same namespace
• watching Gateway API resources (routes) globally (minimal ClusterRole)

Wouldn't this remove all the concerning privileges?

• creating deployments/daemonsets (pods)
• getting secrets

I think this would also work when using HTTPProxy with includes from the namespace, which I think is already a best practice for a cluster operator to avoid access to the certificates from workload namespaces?

[github-actions]

Hey @erikschul! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[erikschul]

@tsaarni

[tsaarni]

I'm not entirely sure, but I believe it would require changes in how the controller-runtime informers are used to watch updates for different resource types. This complexity comes from the way the Kubernetes REST API works, having one endpoint to watch globally for a resource type, and multiple endpoints for namespace-specific watches. Currently, we support configuring the client to watch all relevant resource types in multiple/specific namespaces using --watch-namespaces=<ns,ns> option, as I also mentioned in the issue you referenced, or in all namespaces. The provisioner also supports this via the ContourDeployment.spec.contour.watchNamespaces parameter.

In the scenario you described, there are two types of watches at the same time e.g. a global watch for Gateway API resource types and namespaced watch for Secrets. I doubt it would be possible to achieve this just by modifying the RBAC rules, I think it requires a code change.

[erikschul]

Thanks @tsaarni .
In that case, the feature request is more specifically:

• modify the (contour?) code so that it will search for Gateway API resources in all namespaces (when not using --watch-namespaces), but only search for secrets in other namespaces than projectcontour when necessary (e.g. if an HTTPProxy explicitly requires it, in which case its up to the namespace to provide relevant RoleBindings).

I consider it relatively low risk, but perhaps also in the context of migrating to Gateway API, it would be interesting to support this privilege-limited use case, for example with a 6 month timeframe?