[Request] Stored Credentials via k8s config

[andrewazores]

Describe the feature

I had a user question/request come in recently so I will summarize it here:

Is there a way to configure Cryostat (JMX) Stored Credentials using k8s resources via the Operator? ie a CRD representing a Stored Credential, or a configuration property of the (Cluster)Cryostat CR

This seems to me like a reasonable request - stored credentials are somewhat akin to TLS secrets, and for most Cryostat deployments I imagine these are a stable configuration property that changes infrequently. Adding these in some way as Operator-managed resources would mean that other Operators can integrate more easily with the Cryostat Operator - for example, an Operator that deploys Java applications and controls the JMX credentials they require can also integrate with the Cryostat Operator so that the Cryostat instance that will monitor those applications already knows their JMX credentials.

From an implementation POV I expect this would look like:

1. Operator completes the existing reconcile loop and creates a Cryostat instance
2. Once the Cryostat instance is running and healthy (responds to liveness probes), the Operator checks the Stored Credentials resources (its own CR or property of the Cryostat CR)
3. The Operator then queries the Cryostat instance ex. GET /api/v2.2/credentials to get the instance's list of Stored Credentials, which the Cryostat instance retrieves from encrypted database
4. The Operator compares the query response from Cryostat in (3) to the k8s configuration from (2) and essentially runs another reconcile loop
5. The Operator makes DELETE /api/v2.2/credentials/:id and POST /api/v2.2/credentials requests to reconcile the Cryostat instance's Stored Credentials with the desired state
6. Once this is complete, the Operator updates the Status of the Cryostat CR to reflect this change

Anything other information?

No response

[andrewazores]

@ryanemerson in the last few releases, the Cryostat Agent has gained a lot of capabilities including "read-write" access so that it is now at feature parity with JMX for Cryostat's purposes, ie any operation you can do via Cryostat's UI or API you can do regardless of whether the target is using JMX or Cryostat Agent HTTP.

Along with that, the Agent generates credentials to secure its own HTTP endpoints and registers those with the Cryostat server automatically.

Would the Agent work for your use case as an alternative path that sidesteps this issue?

[ryanemerson]

Maybe I don't understand your suggested workaround, but I don't think this resolve the problem that I was originally trying to solve.

The idea was that the Infinispan Operator would have some mechanism, ideally a k8s resource, that could be triggered to initialize the Infinispan server credential with Cryostat. Infinispan Cryostsat users could then connect to Infinispan pod's using this pre-defined credential and not have to be concerned with manually creating it.

[andrewazores]

I see what you mean. Using the Cryostat Agent as I suggested above is not a direct drop-in replacement for the concept you're describing, but if these Infinispan Pods were instrumented with the Cryostat Agent, then they could also be configured so that these Agent instances would hook up to a Cryostat instance, and in the end the user would not need to deal with stored credentials.

Of course, getting the Cryostat Agent into the Infinispan Pod takes a bit of extra doing, and then figuring out how to configure those Agents to hook up to a Cryostat instance needs some knowledge about the specific deployment, so this is not necessarily eliminating any complexity but just shifting it around.