[Story] Multi-tenant security

[andrewazores]

Related to #760

Overview

https://github.com/cryostatio/cryostat/issues/760#issuecomment-983702154

In the upcoming 2.3 release, Cryostat can be deployed such that it does k8s Endpoints discovery across multiple listed namespaces. The Cryostat Agent will also be launched and available, which implements the Cryostat Discovery Plugin API, and would allow applications in any namespace (or even outside of the cluster) to register with a Cryostat instance. This means that the Cryostat installation namespace is fully decoupled from the namespace(s) that target applications run within.

However, there is an important caveat in that story which users must be aware of. Any and all data that these Cryostat instances may collect is equally available to any and all users who have access to that Cryostat instance.

Consider, if:

• user Alice has a Namespace A, in which she has deployed alice-app
• user Bob has Namespace B, in which he has deployed bob-app
• Cryostat is installed in Namespace C on the cluster and is configured to perform discovery in A, B, and C
• Alice does not have access within B. Bob does not have access within A. Both have permissions to access Cryostat.

Then:

• Alice can request Cryostat connect to bob-app, start recordings, and copy JFR data from B into C. Alice can download any of those JFR files to her workstation. These may contain sensitive information, such as k8s Secrets exposed as environment variables to bob-app which could contain things like API tokens.
• Likewise, Bob also has access to A and alice-app.

Current (version 2.3) best practices

In the scenario above, the cluster administrator who installed Cryostat should not give Alice or Bob access to this instance. Neither Alice nor Bob should have any permissions within C. Instead, there should be one Cryostat installation for Alice and a separate one for Bob. These may be deployed into A and B, or C1 and C2, or any other separate namespaces. Administrators (end users who install Cryostat) should take care and ensure that each installed Cryostat instance has a well-defined set of users who have access, and all of these users must share a common level of group access to all of the applications monitored across the namespaces that the Cryostat instance will have access to.

If the set of users and/or set of monitored applications/namespaces is highly dynamic, and frequent changes to the Cryostat instance configuration are undesirable to avoid redeployments, then use of the Cryostat Agent is encouraged. The Agent can be bundled into a target application relatively easily, and the application's Deployment can be updated to provide environment variables instructing the Agent on where to find the common Cryostat instance that it should register with. The Cryostat instance then has no need to perform Endpoints discovery within any namespaces, and instead will discover Agent instances as they advertise their presence to Cryostat over the HTTP API. The Administrator then only needs to think about which users have access to the Cryostat instance.

Proposed solution

In a future release, Cryostat should maintain and enforce a separation such that users may only see and access targets, and the data sourced from them, if the user also has direct access to the resource associated with the target according to the underlying platform and its auth system. In OpenShift this means, roughly, that Alice should not be able to see that bob-app exists because Cryostat will check with the OpenShift auth server and determine that Alice does not have RBAC permissions within B. If Alice specifically crafts a response attempting to target bob-app then Cryostat should also block this request because of the OpenShift auth check. Cryostat already knows how to perform such access checks against the OpenShift auth server, but support should be expanded to more implementations. Cryostat will need to learn how to map any given target application back to some platform resource that can be queried for with the auth system, and will need to also attach enough information about this mapping to any stored data (ex. archived recordings) so that the same access checks can be performed for stored data as with live access data.