Add user-facing role definitions for Envoy Gateway and Gateway API

[evankanderson]

What type of PR is this?

feat: Add admin/edit/view namespaced rolebindings for gateway.networking.k8s.io and gateway.envoyproxy.io resources

What this PR does / why we need it:

Adds cluster roles which aggregate to the built-in user-facing cluster roles to allow users with namespace-level admin, edit, or view permissions to view the appropriate Gateway API resources.

Which issue(s) this PR fixes:

I didn't open an issue, but with the default helm chart install and view on a namespace, I get the following error:

$ kubectl get backendtrafficpolicy --context staging -n foo
Error from server (Forbidden): backendtrafficpolicies.gateway.envoyproxy.io is forbidden: User "engineering" cannot list resource "backendtrafficpolicies" in API group "gateway.envoyproxy.io" in the namespace "foo"

Release Notes: Yes

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.45%. Comparing base (6f5ae8e) to head (5468f84).
Report is 134 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4532      +/-   ##
==========================================
- Coverage   65.72%   65.45%   -0.27%     
==========================================
  Files         211      211              
  Lines       31669    31858     +189     
==========================================
+ Hits        20813    20854      +41     
- Misses       9656     9759     +103     
- Partials     1200     1245      +45     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zhaohuabing]

@evankanderson Thanks for adding this. The gen-check check failed. To fix it, could you please run make gen-check loacally and submitted the generate files?

[evankanderson]

Updated, sorry for the delay!

[evankanderson]

... and fixed whatever happened with merges and DCO that made the DCO-bot mad.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[arkodg]

thanks for adding this @evankanderson , should we instead generate ClusterRoles that represent the core personas in the project ? https://gateway.envoyproxy.io/about/#personas / https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/
cc @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

[zirain]

thanks for adding this @evankanderson , should we instead generate ClusterRoles that represent the core personas in the project ? https://gateway.envoyproxy.io/about/#personas / https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/ cc @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

I recall I asked you why EG didn't use ClusterRole, but I forgot the answer.

[evankanderson]

thanks for adding this @evankanderson , should we instead generate ClusterRoles that represent the core personas in the project ? https://gateway.envoyproxy.io/about/#personas / https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/
cc @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

I'm happy to add those as well, but the aggregated ClusterRoles are handy for smaller clusters where users may be directly assigned the editor or viewer roles on a namespace or the whole cluster level without specific role grants for specific installed software.

[arkodg]

thanks for adding this @evankanderson , should we instead generate ClusterRoles that represent the core personas in the project ? https://gateway.envoyproxy.io/about/#personas / https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/
cc @envoyproxy/gateway-maintainers @envoyproxy/gateway-reviewers

I'm happy to add those as well, but the aggregated ClusterRoles are handy for smaller clusters where users may be directly assigned the editor or viewer roles on a namespace or the whole cluster level without specific role grants for specific installed software.

thinking out loud, we may still be able to achieve your use case of admin and editor roles, if we chose to go ahead with the existing personas described in the Envoy Gateway docs

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: envoy-gateway-platform-admin
  labels:
  {{- include "eg.labels" . | nindent 4 }}
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
  - apiGroups: ["gateway.networking.k8s.io", "gateway.envoyproxy.io"]
    resources: // everything minus GatewayClass, xRoutes
    verbs: ["*"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: envoy-gateway-app-developer
  labels:
  {{- include "eg.labels" . | nindent 4 }}
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
  - apiGroups: ["gateway.networking.k8s.io", "gateway.envoyproxy.io"]
    resources: // everything minus GatewayClass, Gateway, EnvoyProxy
    verbs: ["*"]