Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add rbac removal for when auth with proxy #2291

Closed
wants to merge 1 commit into from
Closed

Add rbac removal for when auth with proxy #2291

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 15 additions & 0 deletions docs/install.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,21 @@ By default the Dashboard accesses resources and performs actions in the cluster

Typically when configuring impersonation you would have the proxy forward its ServiceAccount token in the `Authorization` header, and details of the user and groups in the `Impersonate-User` and `Impersonate-Group` headers respectively. See the docs of your chosen solution for details.

When using a reverse proxy, with impersonation headers or the user's account, you should remove the dashboard's privileges to better maintain a "least privileged" approach. This will make it less likely that the dashboard's `ServiceAccount` will be abused:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Suggested change
When using a reverse proxy, with impersonation headers or the user's account, you should remove the dashboard's privileges to better maintain a "least privileged" approach. This will make it less likely that the dashboard's `ServiceAccount` will be abused:
When using a reverse proxy, with impersonation headers or the user's account, you should remove the Dashboard's privileges to better maintain a "least privileged" approach. This will make it less likely that the Dashboard's `ServiceAccount` will be abused:


```
kubectl delete clusterrole tekton-dashboard-backend
kubectl delete clusterrole tekton-dashboard-dashboard
kubectl delete clusterrole tekton-dashboard-pipelines
kubectl delete clusterrole tekton-dashboard-tenant
kubectl delete clusterrole tekton-dashboard-triggers
kubectl delete clusterrolebinding tekton-dashboard-backend
kubectl delete rolebinding tekton-dashboard-pipelines -n tekton-pipelines
kubectl delete rolebinding tekton-dashboard-dashboard -n tekton-pipelines
kubectl delete rolebinding tekton-dashboard-triggers -n tekton-pipelines
kubectl delete clusterrolebinding tekton-dashboard-tenant
Comment on lines +205 to +214
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should consider adding a label to these resources to more easily target them for deletion and avoid having to keep this list up to date. What do you think? e.g. rbac.dashboard.tekton.dev/default: true or similar so we could kubectl delete clusterrole -l rbac.dashboard.tekton.dev/default=true etc.

Technically only the bindings need to be deleted, so maybe rbac.dashboard.tekton.dev/subject: tekton-dashboard or similar would be more suitable on those, to make it clear we're removing the default permissions granted the Dashboard's SA.

I think we'll likely add an additional manifest (or at least an installer script flag) in future to install the Dashboard without these resources. This would probably make sense as part of the remaining work to improve the experience with custom RBAC, impersonation, etc.

```

If you're using one of these proxies to provide authentication but still want to use the Dashboard's ServiceAccount to access the Kubernetes APIs you may need to modify the proxy config to prevent it from sending the `Authorization` header on upstream requests to the Dashboard. Some examples of relevant config:
- oauth2-proxy: add the `--pass-authorization-header=false` command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
- Istio EnvoyFilter: the external authentication service should return a custom header `x-envoy-auth-headers-to-remove: Authorization` https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Expand Down