search

cryostatio / cryostat

Secure JDK Flight Recorder management for containerized JVMs
https://cryostat.io
Other
19 stars 10 forks source link

[Request] Multitenant RBAC #630

Open grzesuav opened 2 months ago

grzesuav commented 2 months ago

Describe the feature

According to https://github.com/cryostatio/cryostat-operator/blob/cryostat-v3.0/config/crd/bases/operator.cryostat.io_cryostats.yaml#L4887 feature, 

he SubjectAccessReview or TokenAccessReview that all clients (users visiting the application via web browser as well
                          as CLI utilities and other programs presenting Bearer auth tokens) must pass in order to access the application.
                          If not specified, the default role required is "create pods/exec" in the Cryostat application's installation namespace.

what we usually need is to have permission per target namespace, not cryostat namespace

Anything other information?

Related discussion - https://github.com/cryostatio/cryostat/discussions/622#discussioncomment-10487652

andrewazores commented 2 months ago

The current solution to this problem is to create separate Cryostat instances for each team (installation namespace). Solving this so that a single Cryostat instance can be configured to enforce RBAC across different teams/namespaces and keep their data separate from each other would require quite a large API redesign and rearchitecture of the auth proxy system, so it's unlikely this will be done any time soon.

grzesuav commented 2 months ago

Got it, however separate cryostat instance per team is difficult to set up - we need to expose public address via our infra so it would require to have a lot of addresses (cryostat-teamA. xxx) - having that somehow handled in cryostat -like pluggable way to chime in, to add validation if given user can do start/stop recording would be desired.

It would be good to have some design doc which could be idea-proofed against different use case - in mid/large scale companies it would be a must

andrewazores commented 2 months ago

This would go back to the original discussion and abandoned implementation from the old codebase: https://github.com/cryostatio/cryostat-legacy/issues/1409

This becomes difficult because it means that Cryostat has to somehow determine the origin of the JFR data and tag that data with the origin at the time that the data is persisted to storage, or written to database. Then later on read, it must perform the RBAC check for the requesting user against that data. This isn't hard conceptually, but it does get complicated with the realities of trying to ensure that data is fully segregated in the S3 object storage, for example, and it means that the Cryostat application needs to be aware of the RBAC system - it is not aware of this at all anymore in 3.0, relying entirely on the auth proxy instead.

Then the next difficulty comes in making this whole system generic enough that it can be disabled or removed seamlessly, so that Cryostat remains usable for non-Kubernetes use cases, like Podman or Docker (Swarm).

So I'd really love to implement something like that, but it's seriously a large amount of design and work, and I don't think our team is going to have the bandwidth to work on this. But I would gladly participate in any community-driven design discussions and would very happily review and accept PRs.

grzesuav commented 2 months ago

From my perspective it is not much about data access as rather an application access- I doubt our application owner would be happy if someone else would start recording and have some unwanted performance overhead

andrewazores commented 2 months ago

I understand your point, but at the same time I don't think we can design and release some feature that only provides additional access controls for application access and not for accessing the associated data. Otherwise, unauthorized users may not be able to start recordings on your containers and incur some performance overhead, but they would be able to download JFR files from those containers or from the Cryostat Archives, and those JFR files may contain sensitive information - either from custom JFR events, or even because JFR events can capture environment variables and therefore may capture deployment secrets like database keys. So if we do anything here to add additional layers of access controls and concepts of user groups and group ownership, it must be designed to fully cover everything, or else it's a serious footgun for the end user.

grzesuav commented 2 months ago

got it ! Thanks for explaining, for sure it is bigger topic than I had in mind