Issue with Auth in Singularity 1.2.0
yuriy-filatov opened this issue · 4 comments
Hey
We're currently adding another layer of security into our current cluster, but have already faced several issues.
We've managed to add webhook into our, I'd say, thingy, which is serving login page and goes into LDAP for user verification.
Output is pushed into cookie and passed to Singularity.
First issue -- we were unable to feed that to Singularity through header, 'cause js scripts which are 'talking' to api were ignoring forwarded authorization header and used null instead -- that's why we've used cookie wrapping.
Second -- any emailed action doesn't have singularityUserId anymore (actually this is a long-runner, unrelated to current issue and is observed at least for last 12 months). Can singularityUserId be also parsed from http://URI/singularity/api/auth/user from user:id field if auth is enabled?
And the main issue is that I don't get how groups are working.
Users who are enrolled into jitaGroups+requiredGroups are unable to browse UI at all, everything blows up with something like
An error occurred while accessing /requests/ids?useWebCache=true&state=ACTIVE&state=PAUSED&state=SYSTEM_COOLDOWN&state=FINISHED&state=DEPLOYING_TO_UNPAUSE
Unable to authenticate using methods: [SingularityWebhookAuthenticator (Exception while verifying token: java.lang.RuntimeException: javax.ws.rs.WebApplicationException: HTTP 401 Unauthorized)]
Although everything is working as intended (I mean -- whole our machinery with blows and whistles).
Users who are enrolled into globalReadOnlyGroups+requiredGroups are able to pause/unpause jobs and edit anything (wut?).
Users who are enrolled into adminGroups+requiredGroups -- can do pretty much the same as RO users do.
Can you please clarify how this feature is working (or not)? Can we assign more granular rights to groups? Thanks!
So there is a bunch here and I can provide a more detailed response tomorrow. but some shorter highlights:
- I totally acknowledge Singularity auth was an afterthought. As an internal-only tool it went from totally open for a small team of engineers to trying to figure out how to mesh an oss project with our internal home-built auth system
- We recently added more granular permissions and updated how Singularity does its checks a bit in #2092 . tl;dr on that one is that originally the old auth was aimed at 'is this person at least allowed to be in Singularity'. The options aren't quite as granular as I would want, but at least allow it to distinguish read/write/admin scopes on top of existing groups. (i.e. fixes the anyone in a valid group can do stuff issue). This will be in a 1.3.0 andI can try and get a public release out soon-ish if you're interested
Great news, thank you!
We'd happy to test new release as soon as it will be available
1.3.0 jars should be on maven central in a bit, just released. Gonna close this one for now and we can open new/specific issues as they pop up 👍
Amazing, thank you!
We'll start testing asap.