https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# general
a
This message was deleted.
a
To answer my own question a bit: it looks like it's only intended for use with JWTs generated by the downstream cluster (also that line has a bug, 
err
is always 
nil
so the debug message isn't very useful, I imagine it was intended to be 
logrus.Debugf("saauth: JWT sub is not a service account: %v", claims.Subject)
instead)
c
that bug would make things hard to trace if debugging… you should open an issue
a
Is it possible to use a third-party IdP to authenticate to the Rancher API using this new feature at all? I could in theory create a JWT with the 
sub
set to 
system:serviceaccount:example:example
, but I'm not sure how the Rancher auth proxy would handle that
c
https://github.com/rancher/rancher/issues/22417 is the tracking issue for the enhancement
a
I'm not really clear on how the K8s OIDC integration works; do `TokenReview`s created using JWTs signed by the OIDC provider validate? Or do only JWTs signed by the cluster itself validate?
c
any service account token that will pass a TokenReview in the downstream cluster should work
a
Yeah, the 
that will pass a TokenReview in the downstream cluster
bit is what I'm not sure about
c
so, it’d depend on how you set up oidc on the downstream cluster
a
But I'm unclear on whether that configuration affects `TokenReview`s, or only authentication to the K8s API itself
c
the SubjectAccessReview/TokenReview stuff just lets you ask the apiserver if it would allow something. If those APIs indicate success, an actual request made using those credentials should also work.
a
ah, okay! So the answer to my question is: probably, provided I can figure out how to get it set up correctly
I realized my test setup had a mistake in it that was also preventing it from working, and now I think I'm just missing RBAC configurations
I'm not entirely certain this helps with my ultimate goal though, since in reality I won't have control over the 
sub
claim in the JWTs provided by my IdP (GitLab in my case), so I won't be able to get past the Rancher auth proxy, since the ServiceAccountUsernamePrefix check will fail
c
yeah they need to start with systemserviceaccount I think, to pass that check. This feature is not meant for use by end-users.
a
That's kind of what I figured. I guess I should put in a feature request then
Our use case is allowing automated deployments from GitLab to authenticate to Rancher; API keys aren't great for us because we have Shibboleth SSO on our Rancher cluster, so we can't auth to Rancher with an LDAP service account to generate/rotate an API key, forcing us to do that manually (and have the API key eternally attached to an actual developer's account, causing headaches with e.g. offboarding)
API keys also can't really have granular RBAC policies in Rancher, which is unfortunate
It would be awesome if we could just configure our Rancher cluster to trust our GitLab instance's OIDC public keys, and then use GitLab-signed ID tokens in our pipelines to authenticate to Rancher
Could this be possible if we enabled authorized cluster endpoints?
c
if you’re bypassing rancher and talking directly to the downstream cluster (which is what ACE does) then you can do whatever you want.
a
Would we need to disable the 
kube-api-auth
webhook to essentially just bypass Rancher's authentication
c
ACE just allows you to use upstream Rancher server creds in the downstream cluster.
a
Interesting, I might be able to make this work for noninteractive use cases (which is all that matters for me right now), but it might be a job to convince our Rancher team to enable ACEs...
At this point I'll be happy if I can PoC that this JWT auth with a third-party IdP to a Rancher cluster is possible at all
There are certain API calls that are non-cluster-specific (e.g. listing all clusters), do those go to the 
local
(management) cluster?
c
ACE just lets you get a kubeconfig for direct access to the downstream cluster from the Rancher UI. It requires you setting up an endpoint to hit it at, that points at what’s basically an auth proxy. If you already know how to hit the downstream cluster apiserver, and can get valid creds for it, you don’t need to mess around with ACE.
a
Gotcha, that makes sense; I think the issue for me will be getting that access since I'm not sure our downstreams are reachable from our GitLab instance
75 Views
Open in Slack
PreviousNext
Powered by