Discussion on Cryostat Deployment in a Namespace

[Prasunamadasu]

I would like to discuss the guideline mentioned in the Cryostat documentation which states:

The operator creates and manages a Deployment of Cryostat when the user creates or updates a Cryostat object. Only one Cryostat object should exist in a namespace at a time.

In my current setup, I am deploying a Cryostat instance for each application within the same namespace. This means multiple Cryostat objects exist in a single namespace. I would like to understand the implications of this setup and whether there are recommended practices for managing multiple Cryostat instances in the same namespace.

Any insights or recommendations would be greatly appreciated.

[andrewazores]

If I understand correctly, you have something like:

• Application 1 deployed in Namespace A
• Application 2 deployed in Namespace B
• Cryostat 1 created in Namespace C with TargetNamespaces=[A]
• Cryostat 2 created in Namespace C with TargetNamespaces=[B]

Is that roughly what you mean?

[Prasunamadasu]

Thank you for your response. To clarify, my setup involves deploying two applications within the same namespace, let's call it Namespace A. For each application, I have created a separate Cryostat instance within the same Namespace A. This means that multiple Cryostat objects exist simultaneously in Namespace A, each targeting a different application.

I am seeking guidance on the implications of having multiple Cryostat instances in the same namespace and any recommended practices for managing this setup effectively.

[andrewazores]

So you have Application 1, Application 2, Cryostat 1, and Cryostat 2 all in Namespace A?

You'd have the following factors to consider:

1. Users are granted access to Cryostat instances based on namespaced RBAC. In particular, the create pods/exec Role within the Cryostat CR's installation Namespace. So in this scenario, any user who has access to Cryostat 1 also has access to Cryostat 2. Therefore, all users have a sufficient privilege level to pull JFR data out of Application 1 and Application 2. Even if Cryostat 1 is somehow configured to only see Application 1, a user can create a Custom Target definition so that Cryostat 1 sees Application 2.
2. If you are using the built-in OpenShift/Kubernetes discovery mechanism that looks for Endpoints objects within the Cryostat CR TargetNamespaces, then Cryostat 1 and Cryostat 2 will both see both Application 1 and Application 2. If you define any Automated Rules, you'll have to be careful that their match expressions do not overlap or else both Cryostat instances will independently start managing and collecting recordings from the same applications.

Just out of curiosity, why are you deploying two separate Cryostats in this case? Why not just one Cryostat to observe all applications in Namespace A?

[Prasunamadasu]

Thank you for your insights. We would like to deploy Application 1 and Application 2, each with its own Cryostat instance (Cryostat 1 and Cryostat 2) within Namespace A. The primary reason for this setup is security and isolation. By having one Cryostat instance per application, we ensure that developers can only access the monitoring data for their specific application.

[andrewazores]

By deploying both Cryostats into the same Namespace, both of those Cryostats require the create pods/exec in Namespace A Role in order to access them. Therefore, both of these Cryostats grant access to identical sets of users. This is why our recommendation is to place each Cryostat into its own separate Namespace - for security and isolation. If you place each Cryostat into a separate Namespace then you can control which developers have access to each one by using Kubernetes Role assignments for the developers' user accounts and only granting them create pods/exec in the appropriate Namespace that corresponds to the Cryostat instance they should use.

By placing both applications and both Cryostats all together into one Namespace, then you are not really isolating the data or restricting your developers' access to it - you are simply configuring it to not be visible by default, maybe, but there are no actual access controls restricting or isolating it.

[Prasunamadasu]

Thank you for your valuable insights and for highlighting the implications of our current setup.

[andrewazores]

Didn't mean to close this, just to leave it answered.