cryostatio/cryostat-helm

Helm Chart for Cryostat

Cryostat Helm Chart

A Helm chart for deploying Cryostat on Kubernetes and OpenShift.

Requirements

Kubernetes: >= 1.25.0-0

Installation

From Helm repository

The chart is available at the following repositories:

• https://cryostat.io/helm-charts
• https://charts.openshift.io

To install the chart, add the repository and install, for example:

helm repo add cryostat-charts https://cryostat.io/helm-charts
helm repo update
helm install cryostat cryostat-charts/cryostat

From OCI container registry

The chart is also available as an OCI image on GitHub Container Registry (ghcr.io).

To install the chart, run:

helm install cryostat oci://ghcr.io/cryostatio/cryostat-helm --version $VERSION

From source code

To install the chart from source code, run:

git clone https://github.com/cryostatio/cryostat-helm
cd cryostat-helm
helm install cryostat ./charts/cryostat

Parameters

Cryostat Container

Name	Description	Value
core	Configuration for the core Cryostat application
core.image.repository	Repository for the main Cryostat container image	quay.io/cryostat/cryostat
core.image.pullPolicy	Image pull policy for the main Cryostat container image	Always
core.image.tag	Tag for the main Cryostat container image	4.0.0-snapshot
core.service.type	Type of Service to create for the Cryostat application	ClusterIP
core.service.httpPort	Port number to expose on the Service for Cryostat's HTTP server	8181
core.sslProxied	Enables SSL Proxied Environment Variables, useful when you are offloading SSL/TLS at External Loadbalancer instead of Ingress	false
core.ingress.enabled	Whether to create an Ingress object for the Cryostat service	false
core.ingress.className	Ingress class name for the Cryostat application Ingress	""
core.ingress.annotations	Annotations to apply to the Cryostat application Ingress	{}
core.ingress.hosts	Hosts to create rules for in the Cryostat application Ingress. See: IngressSpec	[]
core.ingress.tls	TLS configuration for the Cryostat application Ingress. See: IngressSpec	[]
core.route.enabled	Whether to create a Route object for the Cryostat service. Available only on OpenShift	false
core.route.tls.enabled	Whether to secure the Cryostat application Route with TLS. See: TLSConfig	true
core.route.tls.termination	Type of TLS termination to use for the Cryostat application Route. One of: edge, passthrough, reencrypt	edge
core.route.tls.insecureEdgeTerminationPolicy	Specify how to handle insecure traffic for the Cryostat application Route. One of: Allow, Disable, Redirect	Redirect
core.route.tls.key	Custom private key to use when securing the Cryostat application Route	""
core.route.tls.certificate	Custom certificate to use when securing the Cryostat application Route	""
core.route.tls.caCertificate	Custom CA certificate to use, if needed to complete the certificate chain, when securing the Cryostat application Route	""
core.route.tls.destinationCACertificate	Provides the contents of the CA certificate of the final destination when using reencrypt termination for the Cryostat application Route	""
core.resources	Resource requests/limits for the Cryostat container. See: ResourceRequirements	{}
core.securityContext	Security Context for the Cryostat container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}
core.databaseSecretName	Name of the secret containing database keys. This secret must contain a CONNECTION_KEY secret which is the database connection password, and an ENCRYPTION_KEY secret which is the key used to encrypt sensitive data stored within the database, such as the target credentials keyring. It must not be updated across chart upgrades. It is recommended that the secret should be marked as immutable to avoid accidental changes to secret's data. More details: https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable	""
core.discovery	Configuration options to the Cryostat application's target discovery mechanisms
core.discovery.kubernetes.enabled	Enables Kubernetes API discovery mechanism	true
core.discovery.kubernetes.installNamespaceDisabled	When false and namespaces is empty, the Cryostat application will default to discovery targets in the install namespace (i.e. {{ .Release.Namespace }})	false
core.discovery.kubernetes.namespaces	List of namespaces whose workloads the Cryostat application should be permitted to access and profile	[]
core.discovery.kubernetes.builtInPortNamesDisabled	When false and portNames is empty, the Cryostat application will use the default port name jfr-jmx to look for JMX connectable targets.	false
core.discovery.kubernetes.portNames	List of port names that the Cryostat application should look for in order to consider a target as JMX connectable	[]
core.discovery.kubernetes.builtInPortNumbersDisabled	When false and portNumbers is empty, the Cryostat application will use the default port number 9091 to look for JMX connectable targets.	false
core.discovery.kubernetes.portNumbers	List of port numbers that the Cryostat application should look for in order to consider a target as JMX connectable	[]

Database Container

Name	Description	Value
db	Configuration for Cryostat's database
db.image.repository	Repository for the database container image	quay.io/cryostat/cryostat-db
db.image.pullPolicy	Image pull policy for the database container image	Always
db.image.tag	Tag for the database container image	latest
db.resources	Resource requests/limits for the database container. See: ResourceRequirements	{}
db.securityContext	Security Context for the database container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}

Storage Container

Name	Description	Value
storage	Configuration for Cryostat's object storage provider
storage.image.repository	Repository for the storage container image	quay.io/cryostat/cryostat-storage
storage.image.pullPolicy	Image pull policy for the storage container image	Always
storage.image.tag	Tag for the storage container image	latest
storage.resources	Resource requests/limits for the storage container. See: ResourceRequirements	{}
storage.securityContext	Security Context for the storage container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}

Grafana Container

Name	Description	Value
grafana	Configuration for the customized Grafana instance for Cryostat
grafana.image.repository	Repository for the Grafana container image	quay.io/cryostat/cryostat-grafana-dashboard
grafana.image.pullPolicy	Image pull policy for the Grafana container image	Always
grafana.image.tag	Tag for the Grafana container image	latest
grafana.service.type	Type of Service to create for Grafana	ClusterIP
grafana.service.port	Port number to expose on the Service for Grafana's HTTP server	3000
grafana.resources	Resource requests/limits for the Grafana container. See: ResourceRequirements	{}
grafana.securityContext	Security Context for the Grafana container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}

JFR Data Source Container

Name	Description	Value
datasource	Configuration for the JFR Data Source component, which translates recording events into a format consumable by Grafana
datasource.image.repository	Repository for the JFR Data Source container image	quay.io/cryostat/jfr-datasource
datasource.image.pullPolicy	Image pull policy for the JFR Data Source container image	Always
datasource.image.tag	Tag for the JFR Data Source container image	latest
datasource.resources	Resource requests/limits for the JFR Data Source container. See: ResourceRequirements	{}
datasource.securityContext	Security Context for the JFR Data Source container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}

Authentication

Name	Description	Value
authentication.openshift.enabled	Whether the OAuth Proxy deployed for securing Cryostat's Pods should be one that integrates with OpenShift-specific features, or a generic one.	false
authentication.openshift.clusterRole.name	The name of the ClusterRole to bind for the OpenShift OAuth Proxy	system:auth-delegator
authentication.basicAuth.enabled	Whether Cryostat should use basic authentication for users. When false, Cryostat will not perform any form of authentication	false
authentication.basicAuth.secretName	Name of the Secret that contains the credentials within Cryostat's namespace (Required if basicAuth is enabled)	""
authentication.basicAuth.filename	Key within Secret containing the htpasswd file. The file should contain one user definition entry per line, with the syntax "user:passHash", where "user" is the username and "passHash" is the bcrypt hash of the desired password. Such an entry can be generated with ex. htpasswd -nbB username password (Required if basicAuth is enabled)	""

OAuth2 Proxy

Name	Description	Value
oauth2Proxy.image.repository	Repository for the OAuth2 Proxy container image	quay.io/oauth2-proxy/oauth2-proxy
oauth2Proxy.image.pullPolicy	Image pull policy for the OAuth2 Proxy container image	Always
oauth2Proxy.image.tag	Tag for the OAuth2 Proxy container image	latest
oauth2Proxy.securityContext	Security Context for the OAuth2 Proxy container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext. If the chart is installed in default namespaces (e.g. default), securityContext.runAsUser must be set if the proxy image does not specify a numeric non-root user. This is due to OpenShift Security Context Constraints are not applied in default namespaces. See Understanding and Managing Pod Security Admission.	{}

OpenShift OAuth Proxy

Name	Description	Value
openshiftOauthProxy.image.repository	Repository for the OpenShift OAuth Proxy container image	quay.io/cryostat/openshift-oauth-proxy
openshiftOauthProxy.image.pullPolicy	Image pull policy for the OpenShift OAuth Proxy container image	Always
openshiftOauthProxy.image.tag	Tag for the OpenShift OAuth Proxy container image	cryostat-v3.0
openshiftOauthProxy.accessReview.enabled	Whether the SubjectAccessReview/TokenAccessReview role checks for users and clients are enabled. If this is disabled then the proxy will only check that the user has valid credentials or holds a valid token.	true
openshiftOauthProxy.accessReview.group	The OpenShift resource group that the SubjectAccessReview/TokenAccessReview will be performed for. See https://github.com/openshift/oauth-proxy/?tab=readme-ov-file#delegate-authentication-and-authorization-to-openshift-for-infrastructure	""
openshiftOauthProxy.accessReview.resource	The OpenShift resource that the SubjectAccessReview/TokenAccessReview will be performed for.	pods
openshiftOauthProxy.accessReview.subresource	The OpenShift resource that the SubjectAccessReview/TokenAccessReview will be performed for.	exec
openshiftOauthProxy.accessReview.name	The OpenShift resource name that the SubjectAccessReview/TokenAccessReview will be performed for.	""
openshiftOauthProxy.accessReview.namespace	The OpenShift namespace that the SubjectAccessReview/TokenAccessReview will be performed for.	{{ .Release.Namespace }}
openshiftOauthProxy.accessReview.verb	The OpenShift resource name that the SubjectAccessReview/TokenAccessReview will be performed for.	create
openshiftOauthProxy.accessReview.version	The OpenShift resource version that the SubjectAccessReview/TokenAccessReview will be performed for.	""
openshiftOauthProxy.securityContext	Security Context for the OpenShift OAuth Proxy container. Defaults to meet "restricted" Pod Security Standard. See: SecurityContext	{}

Other Parameters

Name	Description	Value
imagePullSecrets	Image pull secrets to be used for the Cryostat deployment	[]
nameOverride	Overrides the name of this Chart	""
fullnameOverride	Overrides the fully qualified application name of [release name]-[chart name]	""
rbac.create	Specifies whether RBAC resources should be created	true
serviceAccount.create	Specifies whether a service account should be created	true
serviceAccount.annotations	Annotations to add to the service account	{}
serviceAccount.name	The name of the service account to use. If not set and create is true, a name is generated using the fullname template	""
podAnnotations	Annotations to be applied to the Cryostat Pod	{}
podSecurityContext	Security Context for the Cryostat Pod. Defaults to meet "restricted" Pod Security Standard. See: PodSecurityContext	{}
nodeSelector	Node Selector for the Cryostat Pod. See: NodeSelector	{}
tolerations	Tolerations for the Cryostat Pod. See: Tolerations	[]
affinity	Affinity for the Cryostat Pod. See: Affinity	{}
pvc.enabled	Specify whether to use persistentVolumeClaim or EmptyDir storage	false
pvc.annotations	Annotations to add to the persistentVolumeClaim	{}
pvc.storage	Storage size to request for the persistentVolumeClaim	500Mi
pvc.accessModes	Access mode for the persistentVolumeClaim. See: Access Modes	["ReadWriteOnce"]
pvc.selector	Selector for the persistentVolumeClaim. See: Selector	{}
pvc.storageClassName	The name of the StorageClass for the persistentVolumeClaim. See: Class	undefined

cryostat-helm's Issues

[Bug] Cryostat can't discover its own namespace

Current Behavior

Cryostat installed with the Helm Chart no longer sees any applications due to not setting CRYOSTAT_K8S_NAMESPACES.

Expected Behavior

Applications in Cryostat's namespace should be discovered.

Steps To Reproduce

1. Install Cryostat latest/2.3.0-SNAPSHOT using the Helm Chart
2. Check list of targets

Environment

No response

Anything else?

[Request] CI test lint and test chart

Describe the feature

We should have some CI jobs to lint/validate and run tests against helm chart releases.

Anything other information?

https://github.com/helm/chart-testing

Allow user to provide their own Grafana instance

See: cryostatio/cryostat-operator#347

[Request] Automatic safe-to-test label for reviewers

Describe the feature

Pull requests from reviewers should automatically labelled safe-to-test.

Anything other information?

References: https://github.com/cryostatio/cryostat/blob/main/.mergify.yml

Add a schema for chart values

We should include a values.schema.json file to validate chart values:
https://helm.sh/docs/topics/charts/#schema-files

This can be generated by readme-generator-for-helm.

[Request] Allow to edit CRYOSTAT_K8S_NAMESPACES

Describe the feature

Would be good to be able to edit CRYOSTAT_K8S_NAMESPACES to watch multiple namespaces.

Probabily also Role and RoleBinding needs fixes to support that

Anything other information?

No response

kubeVersion does not match with EKS

I am using EKS with crossplane helm provider to deploy helm charts. Trying to deploy this chart I got:

create failed: failed to install release: chart requires kubeVersion: >=1.19.0 which is incompatible with Kubernetes v1.24.8-eks-ffeb93d

Removing line from Chart.yaml helped to run smoothly.

Set SecurityContext defaults for restricted PSA

It would be useful to set this by default to not require the user to specify it themselves.

[Task] Move cryostat-storage into its own Deployment with its own oauth2-proxy

See https://github.com/cryostatio/cryostat-operator/wiki/Security-and-Authz#scenario , #114

[Request] Deployment on non-root URL path, reintroduce Minimal deployment

Hello!
Thanks for your project - it's awesome!

I'm trying to apply it in my K8S installation and it would be cool to have a few more options to configure:

1. Disable Grafana container entirely (in a case when we use something else or just don't need Grafana here)
2. Override the root web URL path (from "/" to "/cryostat", for instance)
3. Volumes for recordings

Thanks in advance!

[Task] Add PR and issue templates

Related: https://github.com/cryostatio/cryostat/issues/1269

Simliar to https://github.com/cryostatio/cryostat/issues/1268

Use Markdown syntax for code in NOTES.txt

For example, in the OpenShift Console, NOTES.txt is interpreted as Markdown. This can cause some variable names to be incorrect.

Set credentials password

After https://github.com/cryostatio/cryostat/pull/1083, Cryostat needs a CRYOSTAT_JMX_CREDENTIALS_DB_PASSWORD environment variable set for its JMX credentials database. At minimum, this can be generated using randAlphaNum.

[Bug] Website submodule workflow does not trigger on release

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow

Use `/health/liveness` endpoint for liveness probe

Helm chart equivalent to cryostatio/cryostat-operator#399 (comment)

Add optional Basic Authentication for Cryostat

It would be useful to support some form of authentication when accessing Cryostat.

See also: cryostatio/cryostat-operator#206

[Task] Switch to GitHub's generated release notes

The Release Drafter action creates draft releases, which will probably conflict with the releases that the Chart Releaser Action tries to make. I think it should actually be possible to substitute GitHub's built-in release notes generator for this action. We add a file to customize the format of the release notes, using labels as we do currently:
https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes

The Chart Releaser Action uses the GitHub Release API to generate release notes if they're not provided. Unfortunately this API doesn't provide a way to specify the previous tag to compare against. It does have a separate API to do this and return the release notes as JSON: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#generate-release-notes-content-for-a-release

We can call this API inside the workflow which should already have the GitHub CLI installed:

# GitHub CLI api
# https://cli.github.com/manual/gh_api

gh api \
  --method POST \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  /repos/OWNER/REPO/releases/generate-notes \
  -f tag_name='v1.0.0' \
 -f target_commitish='main' \
 -f previous_tag_name='v0.9.2' \
 -f configuration_file_path='.github/custom_release_config.yml' 

We can use jq to grab the body from the response and output it to a file. Then create a config.yaml with release-notes-file: /path/to/release-notes[1]. Then pass the config file to the Chart Releaser Action like this: https://github.com/helm/chart-releaser-action#example-using-custom-config

We might be able to use this action to quickly compute the previous semver tag. If not it should be easy to do ourselves.

[1] https://github.com/helm/chart-releaser/blob/fce24e7688b7dd9b6091ff2e84d1eaabce8de1ee/pkg/config/config.go#LL61C45-L61C63

Originally posted by @ebaron in #71 (comment)

[Task] Add switch to deploy openshift-oauth-proxy instead of oauth2-proxy

After #114 (and #116), https://github.com/openshift/oauth-proxy/ can be deployed instead of oauth2-proxy. This should also respect the Basic auth configuration from #116 and its htpasswd file, if the user provides this configuration. The container should be dropped in in place of oauth2-proxy in all instances and should be configured to pass requests to the same containers in the same manners. The only effective difference to the user should be that the login screen looks different and the credentials are OpenShift account credentials rather than htpasswd Basic credentials.

[Request] Allow user-supplied labels and annotations to be applied to created resources

          Ah make sense to me! There is also another service case, related to service configurations.

With service type LoadBalancer:

helm install cryostat-with-svc ./charts/cryostat/ \
--set core.service.type=LoadBalancer \
--set grafana.service.type=LoadBalancer

Since its relying cloud providers, likely there are additional annotations required on the Service. For example, with AWS, I have been manually patching the Services after installing the chart:

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
service.beta.kubernetes.io/aws-load-balancer-type: external

Do you think it would be good to allow setting those on chart values? Currently, we can only set Service's port and type.

Maybe, not this PR scope though.

Originally posted by @tthvo in #122 (comment)

[Bug] Use release name for credentials secret

The credentials secret should use {{ .Release.Name }} instead of cryostat to avoid conflicting with other releases in the same namespace.

cryostat-helm/cryostat/templates/secret.yaml

Line 5 in e111695

name: cryostat-jmx-credentials-db

[Bug] storage and db containers use core's security context

          > https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Maybe it makes sense for us to apply a general Pod security context around everything, and then have optional container security contexts for each container within the Pod:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Except for cases like this where we seem to know that a container will not run under the general Pod context, or at least on some common and supported k8s/OCP versions it won't, then we can provide a default for that particular container.

After saying all that, I see we do have separate container security contexts:

https://github.com/cryostatio/cryostat-helm?tab=readme-ov-file#jfr-data-source-container

But the new storage and db containers don't have their own. They are mistakenly reusing the core context.

Originally posted by @andrewazores in #133 (comment)

Add Cryostat icon to this repository

Once added, this can be referenced in the Chart.yaml.

[Task] Allow backport command to cryostatio teams

Yeh exactly! https://docs.mergify.com/commands/restrictions/#command-restriction-format

Perhaps we want something along these lines instead:

commands_restrictions:
  backport:
    conditions:
      - sender=@team

Originally posted by @ebaron in #90 (comment)

[Request] Unit/Template Tests for helm chart

Describe the feature

Not related to this PR but one suggestion I think we might benefit from is unit/template testing for helm chart. This can help: https://github.com/helm-unittest/helm-unittest

During this PR, it took me a while to see that the --- (yaml separator) leaked into a template field (e.g. namespace: myns---) due to space trimming but chart renders fine. It would be nice to have testing to ease debugging :D

Originally posted by @tthvo in #128 (comment)

Anything other information?

Down the line, we can establish some more e2e tests like scorecards, on top of the connection test: https://helm.sh/docs/topics/chart_tests/

[Task] Deploy Cryostat 3.0 with cryostat-storage, cryostat-db

[Task] Update TLS truststore paths

Describe the feature

See cryostatio/cryostat#355

Anything other information?

No response

[Bug] Cryostat 3 fails to download recordings

Current Behavior

See also cryostatio/cryostat#266

?f=b25nb2luZy5qZnI failed, error id: 77f79b02-233e-44f9-b36d-fa359db7d470-3: software.amazon.awssdk.core.exception.SdkClientException: Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(credentialsProviders=[SystemPropertyCredentialsProvider(), EnvironmentVariableCredentialsProvider(), WebIdentityTokenCredentialsProvider(), ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(profilesAndSectionsMap=[])), ContainerCredentialsProvider(), InstanceProfileCredentialsProvider()]) : [SystemPropertyCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., EnvironmentVariableCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., WebIdentityTokenCredentialsProvider(): Either the environment variable AWS_WEB_IDENTITY_TOKEN_FILE or the javaproperty aws.webIdentityTokenFile must be set., ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(profilesAndSectionsMap=[])): Profile file contained no credentials for profile 'default': ProfileFile(profilesAndSectionsMap=[]), ContainerCredentialsProvider(): Cannot fetch credentials from container - neither AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variables are set., InstanceProfileCredentialsProvider(): Failed to load credentials from IMDS.]
	at software.amazon.awssdk.core.exception.SdkClientException$BuilderImpl.build(SdkClientException.java:111)
	at software.amazon.awssdk.auth.credentials.AwsCredentialsProviderChain.resolveCredentials(AwsCredentialsProviderChain.java:117)
	at software.amazon.awssdk.auth.credentials.internal.LazyAwsCredentialsProvider.resolveCredentials(LazyAwsCredentialsProvider.java:45)
	at software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider.resolveCredentials(DefaultCredentialsProvider.java:128)
	at software.amazon.awssdk.core.internal.util.MetricUtils.measureDuration(MetricUtils.java:54)
	at software.amazon.awssdk.awscore.internal.authcontext.AwsCredentialsAuthorizationStrategy.resolveCredentials(AwsCredentialsAuthorizationStrategy.java:100)
	at software.amazon.awssdk.awscore.internal.authcontext.AwsCredentialsAuthorizationStrategy.addCredentialsToExecutionAttributes(AwsCredentialsAuthorizationStrategy.java:77)
	at software.amazon.awssdk.services.s3.internal.signing.DefaultS3Presigner.invokeInterceptorsAndCreateExecutionContext(DefaultS3Presigner.java:366)
	at software.amazon.awssdk.services.s3.internal.signing.DefaultS3Presigner.presign(DefaultS3Presigner.java:308)
	at software.amazon.awssdk.services.s3.internal.signing.DefaultS3Presigner.presignGetObject(DefaultS3Presigner.java:230)
	at software.amazon.awssdk.services.s3.presigner.Producers_ProducerMethod_produceS3Presigner_439b267c3ef704c1a556181cdfd1b3e0d8559840_ClientProxy.presignGetObject(Unknown Source)
	at io.cryostat.recordings.Recordings.redirectPresignedDownload(Recordings.java:1009)
	at io.cryostat.recordings.Recordings$quarkusrestinvoker$redirectPresignedDownload_67828a00204dd3db027761f338e40a95b09257e0.invoke(Unknown Source)
	at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
	at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
	at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840)

Expected Behavior

No response

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

Release chart for Cryostat 2.1.0

Set images to released versions and release chart

[Bug] Missing k8s secret for JMX credentials of cryostat

That being said, I think helm chart (3.0) also has jmx auth enabled for cryostat. For it 2.x, CRYOSTAT_DISABLE_JMX_AUTH is set to true. I think the password are generated by default in the entrypoint. It's not reported in a k8s secret like on the operator side. Should it be generated by helm template or just disable auth like in 2.x?

Originally posted by @tthvo in cryostatio/cryostat-operator#815 (comment)

Scope: Cryostat 3.0

Question: Should JMX auth be disabled like 2.x? Otherwise, we should generate and same them in a k8s secret, similar to the operator.

Currently, the user has no way to find the credentials to authenticate over JMX for cryostat itself.

[Task] Deploy oauth2-proxy in front of Cryostat, storage, db, jfr-datasource, and Grafana

References:

• https://github.com/cryostatio/cryostat-operator/wiki/Security-and-Authz#scenario
• https://github.com/cryostatio/cryostat3/blob/997f1419e77a5776b7e92368069ca007b86cb287/smoketest.bash#L161
• https://github.com/cryostatio/cryostat3/blob/997f1419e77a5776b7e92368069ca007b86cb287/smoketest/compose/auth_proxy.yml#L32
• https://github.com/cryostatio/cryostat3/blob/997f1419e77a5776b7e92368069ca007b86cb287/smoketest/compose/auth_proxy_alpha_config.yaml#L1

This either depends on #116 , or else --skip-auth-route can be used initially so that the proxy can be deployed on its own acting as a passthrough gateway and requiring no authentication on any requests.

[Epic] TLS configuration enhancements

Describe the feature

End users should have the following new options for TLS:

1. If using OpenShift, enable the serving-cert feature. This is implemented now, but only in a way where it is tied to deployment of the openshift-oauth-proxy
2. Supply their own custom certs
3. Configure the auth proxy (OpenShift or OAuth2) to use custom certs
4. Auto-configure the auth proxy (OpenShift or OAuth2) to use OpenShift serving-cert, if serving-cert is enabled and no custom certs are supplied

Anything other information?

No response

Main branch should use latest development images

As done in the operator, we should change image versions to latest in our main branch.

Don't use latest tag for release branches

The tests are failing because the cryostat-v2.4 branch is still using latest for various image tags. So this is actually deploying Cryostat 2.5.0-snapshot and not 2.4.0-snapshot.

[Request] Chart release for cryostat v3

Describe the feature

Currently chart version 0.4.0 was targeted for cryostat v2.4.0, I see lot of changes since then, but no new chart version was released

Anything other information?

N/A

[Story] Deploy Cryostat 3.0

Describe the feature

The chart should be updated to deploy the development builds of Cryostat 3.0.

• #113
• #114
• #115
• #116
• #117

Anything other information?

No response

Should chart have minimum k8s version as 1.25.0?

Upstream docs specifies >= 1.25 as k8s version constraint, but chart info shows:

cryostat-helm/charts/cryostat/Chart.yaml

Line 9 in 3570abd

kubeVersion: ">= 1.21.0-0"

Related to cryostatio/cryostatio.github.io#194

Should this be 1.25 too? Or our chart has a different version constraint than the operator?

Upgrade chart-releaser-action

Describe the feature

https://github.com/helm/chart-releaser-action/releases/tag/v1.6.0

Anything other information?

No response

Optionally enable basic authentication for Grafana

The operator generates credentials for Grafana and places them in a secret, we should explore options for how to enable Grafana authentication here.

See: #4

Minimal deployment option

Similar to the operator, the Helm chart should offer configuration to deploy Cryostat without Grafana integration.

Add test to verify deployment

The current test is a boilerplate one, we should modify this test to check health endpoints where possible.

Update logo/icon

[Story] Provide option for PVC storage instead of emptyDir

Like with the operator, it would be useful to allow persistence of recordings/templates/credentials with a Persistent Volume Claim.

[Story] Explore release options

Look into way we can publish releases to coincide with Cryostat project releases, and also snapshot releases of the latest development branch.

Relevant GH action:
https://helm.sh/docs/howto/chart_releaser_action/

README should list configurable values

We use readme-generator-for-helm to generate this section of the README by marking up our comments in values.yaml

[Task] Reimplement Basic auth via oauth2-proxy htpasswd config

References:

• https://github.com/cryostatio/cryostat3/blob/997f1419e77a5776b7e92368069ca007b86cb287/smoketest/compose/auth_proxy.yml#L41
• https://github.com/cryostatio/cryostat3/blob/997f1419e77a5776b7e92368069ca007b86cb287/smoketest/compose/auth_proxy_htpasswd#L1
• https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview (search for htpasswd)

Chart.yaml should include kubeVersion

This should be set to ">=1.19.0".

[Story] CI should update website submodule

We should have something here similar to our workflow for updating the web-client module. When a new commit is made to the gh-pages branch, CI should push an update to the submodule reference on https://github.com/cryostatio/cryostatio.github.io.

Create a basic Helm chart for installing Cryostat

Start with minimal functionality:

• TLS disabled
• emptyDir for storage
• No optional volume mounts

[Request] Upload helm charts to github packages registry

Describe the feature

Currently helm chart is published as a release file, this is feature request to push it also to OCI registry associated with github project. It makes it easier to use with i.e. argocd

Anything other information?

One ammong many guides is https://trstringer.com/helm-charts-github-container-registry/

[Bug] OpenShift OAuth Proxy container failed to launch in default namespace

Current Behavior

It seems like the Openshift OAuth proxy image does not specify a numeric non-root user. Thus, runAsNonRoot: true cannot be specified on pod.

$ podman image inspect quay.io/openshift/origin-oauth-proxy:latest --format '{{.Config.User}}'
0

Container failed to launch with status:

  - image: quay.io/openshift/origin-oauth-proxy:latest
    imageID: ""
    lastState: {}
    name: cryostat-authproxy
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: 'container has runAsNonRoot and image will run as root (pod: "cryostat-579d45489-2nt7w_default(337845d4-41c2-4fbb-ab29-3882be6d771a)",
          container: cryostat-authproxy)'
        reason: CreateContainerConfigError

Expected Behavior

Openshift Oauth proxy container should launch successfully.

Steps To Reproduce

helm install cryostat --set authentication.openshift.enabled=true --set core.route.enabled=true ./charts/cryostat/

Environment

CRC version: 2.26.0+233df0
OpenShift version: 4.13.9

Anything else?

Should the chart default to set runAsUser for the proxy container?