Generic way to pass through any Cryostat config option

[heubeck]

There seems to be no way for setting arbitrary config options via the Cryostats CRD.

To keep the CRD stable maybe a generic configOptions: map<CONFIG_KEY, CONFIG_VALUE> could be an option?

[ebaron]

Hi Florian, do you have any options in particular that you'd like to be able to set? Some of these variables need to be controlled by the operator. For example, CRYOSTAT_WEB_PORT needs to match the value from the Service Options in the CRD.

[andrewazores]

Related: cryostatio/cryostat-legacy#808

[heubeck]

I wanted to configure CRYOSTAT_AUTH_MANAGER via the operator, and with that, I thought it could be a good idea, to have a generic solution for future flags as well.

[ebaron]

For now, when running on OpenShift the operator will use the OpenShift authentication mechanism, which requires some additional setup and permissions on the operator's part. In Kubernetes, the operator uses no authentication, which is not ideal. We have an open issue to add support for Basic authentication for Kubernetes: #206.

In terms of allowing the user to override any option, we had a discussion previously about doing this, and I think the consensus was to only expose parameters that user couldn't shoot themselves in the foot with.

[heubeck]

Ok, understood.
Sounds sensible.

I investigated on this, as the Cryostat view only showed me "Login" as headline but without a form to fill data in.
I accessed the UI via a port-forward. Any idea what could be the issue?

To put this practice into context: I have an authenticating reverse-proxy in front of internal applications like grafana, prometheus and so on. so I'd like to have Cryostat either completely open, or, if user management is required, accepting a http header carrying the user-name authenticated by the proxy like e.g. grafana supports.
The incoming connection to Cryostat is also plain http, as https is terminated upfront - can this be the issue? In this case, a x-forwarded-proto header could be a solution.

[ebaron]

Are you using OpenShift or Kubernetes?

The operator currently works either using Routes on OpenShift or Ingress on Kubernetes. For the latter, there's some manual setup that must be done when creating the Cryostat CR. If you can't use Routes or Ingress and need to expose Cryostat using the Service, this can only be done with the Helm Chart currently.

By default Cryostat will only accept HTTPS connections, this can be disabled be setting spec.enableCertManager to false in the Cryostat CR.

[heubeck]

It's Kubernetes (Google Kubernetes Engine).
I've installed the operator using your Kustomization (on purpose using the main branch with the dev-version because of the new serviceOptions): https://github.com/cryostatio/cryostat-operator/tree/main/config/default

Configuration looks as follows:

---
apiVersion: operator.cryostat.io/v1beta1
kind: Cryostat
metadata:
  name: cryostat
  namespace: cryostat-operator-system
spec:
  minimal: false
  enableCertManager: false
  storageOptions:
    pvc:
      spec:
        resources:
          requests:
            storage: 10Gi
  serviceOptions:
    coreConfig:
      serviceType: ClusterIP

Accessing the ClusterIP service by port-forwarding looks as follows:

btw: looks exactly the same when using the helm-chart without overriding any values (what makes sense according to your explanation).

Thank you @ebaron for helping - I know that this isn't the scope of this issue ;)

[ebaron]

I don't expect that configuration to work on Kubernetes without setting the Ingress configs in the CR. The empty login screen is somewhat unexpected though, would you be able to share the logs for the main Cryostat container in the Cryostat pod?

Thank you @ebaron for helping - I know that this isn't the scope of this issue ;)

Glad to help. We'd like this to work on as many environments as possible, but have only been able to test with a few of them.

[andrewazores]

The main Cryostat logs as well as the -web logs from the browser developer console, please!

[heubeck]

Thanks to both of you for helping.

I've created a reproducer using a local k8s kind cluster, behavior is identical to what I see in the managed Kubernetes.

Please find my test setup here: https://github.com/heubeck/cryostat-local-test
The log folder contains the output you were interested in.

Please let me know, if I shall try out further things, really looking forward to my full functional Cryostat installation ;)

[ebaron]

Hi again @heubeck, thanks for the logs and sharing your setup steps with us. I'm just working through some tasks for the upcoming 2.1 release, but I'll give it a try myself as soon as I'm able.

[ebaron]

Hi @heubeck! Sorry for taking a while to circle back to this, but our 2.1 release is now out. I took a look at your Kind setup, and in order to work with a ClusterIP service and kubectl port-forward, you would need to use our Helm Chart instead of the operator. I've filed an issue to support this configuration for the operator as well: #403.

You can install the Helm Chart with:
helm install cryostat https://github.com/cryostatio/cryostat-helm/releases/download/v0.1.1/cryostat-0.1.1.tgz

By default, it deploys Cryostat with ClusterIP services and no Ingresses, which I believe matches your desired configuration. After installing, you'll see some post-install commands to run, including setting some environment variables and running kubectl port-forward. I hope this helps!