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.

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

docs: document how to add OAuth with OauthProxy in front of Capacitor #39

Open
laszlocph opened this issue Jan 26, 2024 · 6 comments
Open
Labels
good first issue Good for newcomers

Comments

@laszlocph
Copy link
Contributor

No description provided.

@laszlocph laszlocph added the good first issue Good for newcomers label Jan 26, 2024
@evandam
Copy link

evandam commented Mar 27, 2024

Hey @laszlocph, first wanted to say thanks for this project!

I was considering switching to Capacitor from the Weave GitOps Dashboard, and was curious about this one.

Weave had a lot of functionality that hooked into k8s RBAC with user/group impersonation through OIDC groups - are there plans to do anything similar with Capacitor? For example, if groups or some attribute gets passed through OAuth/OIDC, would we be able to use that for permissions?

General use case is a cluster admin vs a developer using Capacitor, where developers may not need to see things in the flux-system namespace but rather in their own tenant namespace only.

If this is the wrong place to ask no worries, I'm happy to move this to a separate issue 🙌

@laszlocph
Copy link
Contributor Author

Hello @evandam thanks for your question.

The tldr is that we are investigating the how, and over time this will land in Capacitor.

This question popped up on Kubecon a couple of times, and you summarized it perfectly for Github.

To respect Kubernetes RBAC in Capacitor we need to do two things:

  • We need to be certain about the user's identity
  • We need to impersonate the user in our Kubernetes API calls.

An alternative to Kubernetes RBAC would be Capacitor's own RBAC, but it is considered as a subpar option.

We need to be certain about the user's identity
This needs some investigation, but either we integrate with auth systems like OIDC (maybe more?), or we utilize something like oauth2-proxy and that will forward the authenticated identity to Capacitor.

Then we need to impersonate the user in our Kubernetes API calls. This is fairly understood how it can be done with client-go. Here is a codesample on how Weave did it: https://github.com/weaveworks/weave-gitops/blob/2af6d1133a5717fc3b0f367734443557074b1548/pkg/kube/config_getter.go#L74

If we ever cache API responses and share them between users, the client-go equivalent of kubectl auth can-i feature can help us filtering the cached results and prevent privilege escalation.
https://stackoverflow.com/questions/66994829/how-to-make-impersonate-work-with-kubernetes-go-client

@Cajga
Copy link

Cajga commented Mar 28, 2024

@laszlocph , nice project, also landed here from weave-gitops.

I would second @evandam on this and vote for this nice feature (if users could only see the flux resources to what they have access to).
However, I would like to drop in the fact that weave-gitops did not implement this properly as for their implementation the users had to have access to flux-system (see this ticket for more details).

Flux has a multi-tenancy deployment model that is considered best practice from security point of view when you have multiple teams using the platform. Implementing something that supports that model sounds like the right way to go.

@evandam
Copy link

evandam commented Mar 28, 2024

For what it's worth, I thought having Dex do the heavy lifting for OIDC and even controlling access (required GitHub org, groups, etc.) was a really good way to handle it, without weighing down the GitOps/Capacitor configuration and code base (I'm assuming).

@Cajga
Copy link

Cajga commented Apr 8, 2024

@laszlocph do you think we should create a new ticket about this request? By now, this seems like way more than just a documentation issue... (and possibly not good for a first issue)

@django1194
Copy link

I've done this in the past with some toy applications. It generally boils down to:

  1. Authenticate the user using the same OIDC provider as Kubernetes itself
  2. Extract impersonation information from the OAuth token claims
  3. Proxy requests to the Kubernetes API and inject impersonation headers

Doing this, all authentication is deferred to Kubernetes/OIDC provider and Capacitor doesn't need to much.

I'd be happy to take a shot at it if you'd like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants