{"id":15069318,"url":"https://github.com/cryostatio/cryostat-legacy","last_synced_at":"2025-04-06T10:12:49.381Z","repository":{"id":37053642,"uuid":"164922080","full_name":"cryostatio/cryostat-legacy","owner":"cryostatio","description":"OUTDATED - See the new repository below! -- Secure JDK Flight Recorder management for containerized JVMs","archived":false,"fork":false,"pushed_at":"2024-09-05T00:46:54.000Z","size":7616,"stargazers_count":225,"open_issues_count":99,"forks_count":31,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-03-30T08:11:12.329Z","etag":null,"topics":["containerjfr","containers","docker","flightrecorder","hacktoberfest","hacktoberfest2021","java","jdk","jfr","jmx","jvm","kubernetes","mission-control","missioncontrol","monitoring","observability","oci","openshift","podman","profiling"],"latest_commit_sha":null,"homepage":"https://github.com/cryostatio/cryostat","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cryostatio.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-01-09T19:09:43.000Z","updated_at":"2024-12-18T02:46:47.000Z","dependencies_parsed_at":"2023-09-22T04:33:32.563Z","dependency_job_id":"a78a1454-a73e-4349-a5f8-1cd3a47142d8","html_url":"https://github.com/cryostatio/cryostat-legacy","commit_stats":{"total_commits":1741,"total_committers":27,"mean_commits":64.48148148148148,"dds":0.6042504307869041,"last_synced_commit":"6612edfca222eac9472bcfda418346b71fc667bf"},"previous_names":[],"tags_count":53,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryostatio%2Fcryostat-legacy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryostatio%2Fcryostat-legacy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryostatio%2Fcryostat-legacy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryostatio%2Fcryostat-legacy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cryostatio","download_url":"https://codeload.github.com/cryostatio/cryostat-legacy/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247464222,"owners_count":20942970,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["containerjfr","containers","docker","flightrecorder","hacktoberfest","hacktoberfest2021","java","jdk","jfr","jmx","jvm","kubernetes","mission-control","missioncontrol","monitoring","observability","oci","openshift","podman","profiling"],"created_at":"2024-09-25T01:41:46.224Z","updated_at":"2025-04-06T10:12:49.347Z","avatar_url":"https://github.com/cryostatio.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003ca target=\"_blank\" href=\"https://cryostat.io\"\u003e\n  \u003cpicture\u003e\n    \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"./docs/images/cryostat_logo_hori_rgb_reverse.svg\"\u003e\n    \u003cimg src=\"./docs/images/cryostat_logo_hori_rgb_default.svg\"\u003e\n  \u003c/picture\u003e\n\u003c/a\u003e\n\n[![CI build](https://github.com/cryostatio/cryostat/actions/workflows/push-ci.yml/badge.svg)](https://github.com/cryostatio/cryostat/actions/workflows/push-ci.yml)\n[![Quay Repository](https://quay.io/repository/cryostat/cryostat/status \"Quay Repository\")](https://quay.io/repository/cryostat/cryostat)\n[![Google Group : Cryostat Development](https://img.shields.io/badge/Google%20Group-Cryostat%20Development-blue.svg)](https://groups.google.com/g/cryostat-development)\n\nA container-native JVM application which acts as a bridge to other containerized JVMs and exposes a secure API for producing, analyzing, and retrieving JDK Flight Recorder data from your cloud workloads.\n\n**This repository is no longer maintained.** See [**cryostat**](https://github.com/cryostatio/cryostat) for the\nsource repository for Cryostat 3.0+ and active development.\n\n## SEE ALSO\n\n* [**cryostat**](https://github.com/cryostatio/cryostat) : the new source repository\n  for Cryostat version 3.0+, where active development is taking place. This\n  repository contains the source for versions up to 2.4.1 and will not be\n  maintained after 3.0 is released.\n\n* [cryostat.io](https://cryostat.io) : upstream documentation website with user\n  guides, tutorials, blog posts, and other user-facing content. Start here if\n  what you've read so far sounds interesting and you want to know more as a\n  **user**, rather than as a _developer_.\n\n* [cryostat-core](https://github.com/cryostatio/cryostat-core) :\nthe core library providing a convenience wrapper and headless stubs for use of\nJFR using JDK Mission Control internals.\n\n* [cryostat-operator](https://github.com/cryostatio/cryostat-operator)\n : an OpenShift Operator deploying Cryostat in your OpenShift\ncluster as well as exposing the Cryostat API as Kubernetes Custom Resources.\n\n* [cryostat-web](https://github.com/cryostatio/cryostat-web) : the React\nfrontend included as a submodule in Cryostat and built into\nCryostat's (non-headless mode) OCI images.\n\n* [JDK Mission Control](https://github.com/openjdk/jmc) for the original JDK\nMission Control, which is the desktop application complement to JFR. Some parts\nof JMC are borrowed and re-used to form the basis of Cryostat. JMC is still\na recommended tool for more full-featured analysis of JFR files beyond what\nCryostat currently implements.\n\n## CONTRIBUTING\n\nWe welcome and appreciate any contributions from our community. Please visit our guide on how you can take part in improving Cryostat.\n\n[See contribution guide →](./CONTRIBUTING.md)\n\n## REQUIREMENTS\nBuild Requirements:\n- Git\n- JDK17+\n- Maven 3+\n- Podman 2.0+\n- `qemu-user-static` to build container images for other archs\n\nRun Requirements:\n- Kubernetes/OpenShift/Minishift, Podman/Docker, or other container platform\n- `systemctl --user enable --now podman.socket` to enable the user podman.socket for podman discovery\n\n## BUILD\n\n### Setup Dependencies\n\n* Clone and install [cryostat-core](https://github.com/cryostatio/cryostat-core) via it's [instructions](https://github.com/cryostatio/cryostat-core/blob/main/README.md)\n* Initialize submodules via:  `git submodule init \u0026\u0026 git submodule update`\n\n### Build project locally\n* `./mvnw compile`\n\n### Build and run project locally in development hot-reload mode\n* `sh devserver.sh` - this will start the Vert.x backend in hot-reload mode, so\nany modifications to files in `src/` will cause a re-compilation and re-deploy.\nThis is only intended for use during development. The `web-client` assets will\nnot be built and will not be included in the application classpath. To set up\nthe `web-client` frontend for hot-reload development, see\n[cryostat-web Development Server](https://github.com/cryostatio/cryostat-web/blob/main/README.md#development-server).\n\n### Build and push to local podman image registry\n* `./mvnw package`\n* Run `./mvnw -Dheadless=true clean package` to exclude web-client assets.\nThe `clean` phase should always be specified here, or else previously-generated\nclient assets will still be included into the built image.\n* For other OCI builders, use the `imageBuilder` Maven property. For example, to\nuse docker, run: `./mvnw -DimageBuilder=$(which docker) clean verify`\n\n## TEST\n\n### Unit tests\n* `./mvnw test`\n\n### Integration tests and analysis tools\n* `./mvnw verify`\n\n### Skipping tests\n* `-DskipUTs=true` to skip unit tests\n* `-DskipITs=true` to skip integration tests\n* `-DskipTests=true` to skip all tests\n\n### Running integration tests without rebuild\n* `bash repeated-integration-tests.bash`.\n* To run selected integration tests without rebuilding, append the name(s) of your itest class(es) as an argument to `repeated-integration-tests.bash`, e.g. `bash repeated-integration-tests.bash AutoRulesIT,RecordingWorkflowIT`. Note that modifying a test file does not require a rebuild.\n\n## RUN\n\n### Run on Kubernetes/Openshift\n* See the [cryostat-operator](https://github.com/cryostatio/cryostat-operator)\n\n### Run on local podman*\n* `run.sh`\n\nNote: If you get a 'No plugin found' error, it is because maven has not downloaded all the necessary plugins. To resolve this error, manually run `./mvnw help:evaluate` to prompt maven to download the missing help plugin.\n\n### Run on local podman with Grafana, jfr-datasource and demo application*\n* `smoketest.sh`\n\nTo run on local podman, [cgroups v2](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html) should be enabled.\nThis allows resource configuration for any rootless containers running on podman. To ensure podman works with cgroups v2, follow these [instructions](https://podman.io/blogs/2019/10/29/podman-crun-f31.html).\n\nNote: If your podman runtime is set to runc v1.0.0-rc91 or later it is not necessary to change it to crun as recommended in the instructions, since this version of runc supports cgroups v2. The article refers to an older version of runc.\n\n## CONFIGURATION\n\nCryostat can be configured via the following environment variables:\n\n#### Configuration for cryostat\n\n* `CRYOSTAT_WEB_HOST`: the hostname used by the cryostat web server. Defaults to reverse-DNS resolving the host machine's hostname.\n* `CRYOSTAT_WEB_PORT`: the internal port used by the cryostat web server. Defaults to 8181.\n* `CRYOSTAT_EXT_WEB_PORT`: the external port used by the cryostat web server. Defaults to be equal to `CRYOSTAT_WEB_PORT`.\n* `CRYOSTAT_CORS_ORIGIN`: the origin for CORS to load a different cryostat-web instance. Defaults to the empty string, which disables CORS.\n* `CRYOSTAT_MAX_WS_CONNECTIONS`: the maximum number of websocket client connections allowed (minimum 1, maximum `Integer.MAX_VALUE`, default `Integer.MAX_VALUE`)\n* `CRYOSTAT_AUTH_MANAGER`: the authentication/authorization manager used for validating user accesses. See the `USER AUTHENTICATION / AUTHORIZATION` section for more details. Set to the fully-qualified class name of the auth manager implementation to use, ex. `io.cryostat.net.BasicAuthManager`. Defaults to an AuthManager corresponding to the selected deployment platform, whether explicit or automatic (see below).\n* `CRYOSTAT_PLATFORM`: the platform clients used for performing platform-specific actions, such as listing available target JVMs. If `CRYOSTAT_AUTH_MANAGER` is not specified then a default auth manager will also be selected corresponding to the highest priority platform, whether those platforms are specified by the user or automatically detected. Set to the fully-qualified names of the platform detection strategy implementations to use, ex. `io.cryostat.platform.internal.KubeApiPlatformStrategy,io.cryostat.platform.internal.PodmanPlatformStrategy`.\n* `CRYOSTAT_ENABLE_JDP_BROADCAST`: enable the Cryostat JVM to broadcast itself via JDP (Java Discovery Protocol). Defaults to `true`.\n* `CRYOSTAT_JDP_ADDRESS`: the JDP multicast address to send discovery packets. Defaults to `224.0.23.178`.\n* `CRYOSTAT_JDP_PORT`: the JDP multicast port to send discovery packets. Defaults to `7095`.\n* `CRYOSTAT_CONFIG_PATH`: the filesystem path for the configuration directory. Defaults to `/opt/cryostat.d/conf.d`.\n* `CRYOSTAT_DISABLE_BUILTIN_DISCOVERY`: set to `true` to disable built-in target discovery mechanisms (see `CRYOSTAT_PLATFORM`). Custom Target \"discovery\" remains available, but discovery via JDP, Kubernetes API, or Podman API is disabled and ignored. This will still allow platform detection to automatically select an `AuthManager`. This is intended for use when Cryostat Discovery Plugins are the only desired mechanism for locating target applications. See #936 and [cryostat-agent](https://github.com/cryostatio/cryostat-agent). Defaults to `false`.\n* `CRYOSTAT_K8S_NAMESPACES`: set to a comma-separated list of Namespaces that Cryostat should query to discover target JVM applications with its built-in discovey mechanism.\n\n#### Configuration for Automated Analysis Reports\n\n* `CRYOSTAT_REPORT_GENERATION_MAX_HEAP`: the maximum heap size used by the container subprocess which forks to perform automated rules analysis report generation. The default is `200`, representing a `200MiB` maximum heap size. Too small of a heap size will lead to report generation failing due to Out-Of-Memory errors. Too large of a heap size may lead to the subprocess being forcibly killed and the parent process failing to detect the reason for the failure, leading to inaccurate failure error messages and API responses.\n\n#### Configuration for JMX Connections and Cache\n\n* `CRYOSTAT_JMX_CONNECTION_TIMEOUT_SECONDS`: the maximum wait time for a JMX\n  connection to open and a single operation to complete. This is only used for\n  specific internally-fired operations that are expected to execute very quickly\n  after the connection opens. Default `3`, minimum `1`.\n* `CRYOSTAT_TARGET_MAX_CONCURRENT_CONNECTIONS`: the maximum number of concurrent\n  JMX connections open. When this number of connections are open any requests\n  requiring further connections will block until a previous connection closes.\n  Defaults to `-1` which indicates an unlimited number of connections.\n* `CRYOSTAT_TARGET_CACHE_TTL`: the time to live (in seconds) for cached JMX\nconnections. Defaults to `10`, minimum `1`. Any values less than `1` will be\noverridden with `1`.\n\n#### Configuration for Logging\n\n* `CRYOSTAT_JUL_CONFIG` : the `java.util.logging.config.file` configuration file for logging via SLF4J Some of Cryostat's dependencies also use java.util.logging for their logging. Cryostat disables [some of these](https://github.com/cryostatio/cryostat-core/tree/main/src/main/resources/config/logging.properties) by default, because they generate unnecessary logs. However, they can be reenabled by overriding the default configuration file and setting the disabled loggers to the desired level.\n\n#### Configuration for Event Templates\n\n* `CRYOSTAT_TEMPLATE_PATH`: the storage path for Cryostat event templates\n\n#### Configuration for Archiving\n\n* `CRYOSTAT_ARCHIVE_PATH`: the storage path for archived recordings\n* `CRYOSTAT_PUSH_MAX_FILES`: the maximum number of archived recordings stored in a FIFO manner per target JVM when pushing JFR files using the RecordingsFromIdPostHandler. Mainly used with the [cryostat-agent](https://github.com/cryostatio/cryostat-agent) as a global default configuration for the maximum number of archived JFR recordings to keep on disk per-agent-attached-target, which can be overridden by the agent itself. Defaults to `Integer.MAX_VALUE`, minimum `1`. Any values less than `1` will be overridden with `1`.\n\n#### Configuration for database\n\n* `CRYOSTAT_JDBC_DRIVER`: driver to use for communicating with the database. Defaults to `org.h2.Driver`. `org.postgresql.Driver` is also supported.\n* `CRYOSTAT_JDBC_URL`: URL for connecting to the database. Defaults to `jdbc:h2:mem:cryostat;INIT=create domain if not exists jsonb as other` for an h2 in-memory database. Also supported: `jdbc:h2:file:/opt/cryostat.d/conf.d/h2;INIT=create domain if not exists jsonb as other`, or a PostgreSQL URL such as `jdbc:postgresql://cryostat:5432/cryostat`.\n* `CRYOSTAT_JDBC_USERNAME`: username for JDBC connection.\n* `CRYOSTAT_JDBC_PASSWORD`: password for JDBC connection.\n* `CRYOSTAT_JMX_CREDENTIALS_DB_PASSWORD`: encryption password for stored JMX\n  credentials.\n* `CRYOSTAT_HIBERNATE_DIALECT`: Defaults to `org.hibernate.dialect.H2Dialect`. Also supported: `org.hibernate.dialect.PostgreSQL95Dialect`.\n* `CRYOSTAT_HBM2DDL`: Control Hibernate schema DDL. Defaults to `create`.\n* `CRYOSTAT_LOG_DB_QUERIES`: Enable verbose logging of database queries. Defaults to `false`.\n\n## MONITORING APPLICATIONS\nIn order for `cryostat` to be able to monitor JVM application targets the\ntargets must have RJMX enabled or have the Cryostat Agent installed and\nconfigured. `cryostat` has several strategies for automatic discovery of\npotential targets.\n\nThe first target discovery mechanism uses the OpenShift/Kubernetes API to list\nservice endpoints and expose all discovered services as potential targets. This\nis runtime dynamic, allowing `cryostat` to discover new services which come\nonline after `cryostat`, or to detect when known services disappear later.\nThis requires the `cryostat` pod to have authorization to list services\nwithin its own namespace. By default this will look for `Endpoints` objects\nwith ports named `jfr-jmx` or numbered `9091`. This behaviour can be overridden\nusing the environment variables `CRYOSTAT_DISCOVERY_K8S_PORT_NAMES` and\n`CRYOSTAT_DISCOVERY_K8S_PORT_NUMBERS` respectively. Both of these accept\ncomma-separated lists as values. Any observed `Endpoints` object with a name\nin the given list or a number in the given list will be taken as a connectable\ntarget application. To set the names list to the empty list use `-`. To set the\nnumbers list to the empty list use `0`.\n\nThe second discovery mechanism is JDP (Java Discovery Protocol). This relies on\ntarget JVMs being configured with the JVM flags to enable JDP and requires the\ntargets to be reachable and in the same subnet as `cryostat`. JDP can be enabled\nby passing the flag `\"-Dcom.sun.management.jmxremote.autodiscovery=true\"` when\nstarting target JVMs; for more configuration options, see\n[this document](https://docs.oracle.com/javase/10/management/java-discovery-protocol.htm)\n. Once the targets are properly configured, `cryostat` will automatically\ndiscover their JMX Service URLs, which includes the RJMX port number for that\nspecific target.\n\nThe third discovery mechanism is the Podman API. If the Podman API socket is\navailable at its default filesystem location then Cryostat will query the\n`libpod/containers` endpoint to determine what target applications may be\navailable. Containers must have the Podman label `io.cryostat.connectUrl`\napplied, and the value should be the remote JMX or Cryostat Agent HTTP\nconnection URL that Cryostat can use to communicate with the target.\n\nTo enable RJMX on port 9091, the following JVM flag should be passed at target\nstartup:\n\n```\n    '-Dcom.sun.management.jmxremote.port=9091'\n```\n\nThe port number 9091 is arbitrary and may be configured to suit individual\ndeployments, so long as the `port` property above matches the desired port\nnumber and the deployment network configuration allows connections on the\nconfigured port.\n\nAdditionally, the following flags are recommended to enable JMX authentication\nand connection encryption:\n\n```\n-Dcom.sun.management.jmxremote.authenticate=true # enable JMX authentication\n-Dcom.sun.management.jmxremote.password.file=/app/resources/jmxremote.password # define users for JMX auth\n-Dcom.sun.management.jmxremote.access.file=/app/resources/jmxremote.access # set permissions for JMX users\n-Dcom.sun.management.jmxremote.ssl=true # enable JMX SSL\n-Dcom.sun.management.jmxremote.registry.ssl=true # enable JMX registry SSL\n-Djavax.net.ssl.keyStore=/app/resources/keystore # set your SSL keystore\n-Djavax.net.ssl.keyStorePassword=somePassword # set your SSL keystore password\n```\n\n### JMX Connectors\n\nCryostat supports end-user target applications using other JMX connectors than\nRMI (for example, WildFly `remote+http`) using \"client library\" configuration.\nThe path pointed to by the environment variable `CRYOSTAT_CLIENTLIB_PATH` is\nappended to Cryostat's classpath. This path should be a directory within a\nvolume mounted to the Cryostat container and containing library JARs (ex.\n`jboss-client.jar`) in a flat structure.\n\nIn the particular case of WildFly `remote+http`, you might do something like\nthe following to add this capability:\n\n```bash\n$ podman cp wildfly:/opt/jboss/wildfly/bin/client/jboss-client.jar clientlib/\n```\n\n## EVENT TEMPLATES\n\nJDK Flight Recorder has event templates, which are preset definition of a set of\nevents, and for each a set of options and option values. A given JVM is likely\nto have some built-in templates ready for use out-of-the-box, but Cryostat\nalso hosts its own small catalog of templates within its own storage. This\ncatalog is stored at the path specified by the environment variable\n`CRYOSTAT_TEMPLATE_PATH`. Templates can be uploaded to Cryostat and\nthen used to create recordings.\n\n## ARCHIVING RECORDINGS\n\n`cryostat` supports a concept of \"archiving\" recordings. This simply means\ntaking the contents of a recording at a point in time and saving these contents\nto a file to the `cryostat` process (as opposed to \"active\"\nrecordings, which exist within the memory of the JVM target and continue to grow\nover time). The default directory used is `/flightrecordings`, but the\nenvironment variable `CRYOSTAT_ARCHIVE_PATH` can be used to specify a\ndifferent path. To enable `cryostat` archive support ensure that the\ndirectory specified by `CRYOSTAT_ARCHIVE_PATH` (or `/flightrecordings` if\nnot set) exists and has appropriate permissions. `cryostat` will detect the\npath and enable related functionality. `run.sh` has an example of a `tmpfs`\nvolume being mounted with the default path and enabling the archive\nfunctionality.\n\n## SECURING COMMUNICATION CHANNELS\n\nTo specify the SSL certificate for HTTPS/WSS and JMX, one can set\n`KEYSTORE_PATH` to point to a `.jks`, `.pfx` or `.p12` certificate file *and*\n`KEYSTORE_PASS` to the plaintext password to such a keystore. Alternatively, one\ncan set `KEY_PATH` to a PEM encoded key file *and* `CERT_PATH` to a PEM encoded\ncertificate file.\n\nIn the absence of these environment variables, `cryostat` will look for a\ncertificate at the following locations, in an orderly fashion:\n\n- `$HOME/cryostat-keystore.jks` (used together with `KEYSTORE_PASS`)\n- `$HOME/cryostat-keystore.pfx` (used together with `KEYSTORE_PASS`)\n- `$HOME/cryostat-keystore.p12` (used together with `KEYSTORE_PASS`)\n- `$HOME/cryostat-key.pem` and `$HOME/cryostat-cert.pem`\n\nIf no certificate can be found, `cryostat` will autogenerate a self-signed\ncertificate and use it to secure HTTPS/WSS and JMX connections.\n\nIf HTTPS/WSS (SSL) and JMX auth credentials must be disabled then the\nenvironment variables `CRYOSTAT_DISABLE_SSL=true` and/or\n`CRYOSTAT_DISABLE_JMX_AUTH=true` can be set.\n\nIn case `cryostat` is deployed behind an SSL proxy, set the environment\nvariable `CRYOSTAT_SSL_PROXIED` to a non-empty value. This informs\n`cryostat` that the URLs it reports pointing back to itself should use\nthe secure variants of protocols, even though it itself does not encrypt the\ntraffic. This is only required if Cryostat's own SSL is disabled as above.\n\nIf the certificate used for SSL-enabled Grafana/jfr-datasource connections is\nself-signed or otherwise untrusted, set the environment variable\n`CRYOSTAT_ALLOW_UNTRUSTED_SSL` to permit uploads of recordings.\n\nTarget JVMs with SSL enabled on JMX connections are also supported. In order to\nallow Cryostat to establish a connection, the target's certificate must be\ncopied into Cryostat's `/truststore` directory before Cryostat's\nstartup. If Cryostat attempts to connect to an SSL-enabled target and no\nmatching trusted certificate is found then the connection attempt will fail.\n\n## USER AUTHENTICATION / AUTHORIZATION\n\nCryostat has multiple authz manager implementations for handling user\nauthentication and authorization against various platforms and mechanisms. This\ncan be controlled using an environment variable (see the `RUN` section above),\nor automatically using platform detection.\n\nIn all scenarios, the presence of an auth manager (other than\nNoopAuthManager) causes Cryostat to expect a token or credentials via an\n`Authorization` header on all potentially sensitive requests, ex. recording\ncreations and downloads, report generations.\n\nThe OpenShiftPlatformClient.OpenShiftAuthManager uses token authentication.\nThese tokens are passed through to the OpenShift API for authz and this result\ndetermines whether Cryostat accepts the request.\n\nThe BasicAuthManager uses basic credential authentication configured with a\nstandard Java properties file at\n`$CRYOSTAT_CONFIG_PATH/cryostat-users.properties`.  The credentials stored in\nthe Java properties file are the user name and a SHA-256 sum hex of the user's\npassword. The property file contents should look like:\n```\nuser1=abc123\nuser2=def987\n```\nWhere `abc123` and `def987` are substituted for the SHA-256 sum hexes of the\ndesired user passwords. These can be obtained by ex.\n`echo -n PASS | sha256sum | cut -d' ' -f1`.\n\nToken-based auth managers expect an HTTP `Authorization: Bearer TOKEN` header\nand a\n`Sec-WebSocket-Protocol: base64url.bearer.authorization.cryostat.${base64(TOKEN)}`\nWebSocket SubProtocol header.\nThe token is never stored in any form, only kept in-memory long enough to\nprocess the external token validation.\n\nBasic credentials-based auth managers expect an HTTP\n`Authorization: Basic ${base64(user:pass)}` header and a\n`Sec-WebSocket-Protocol: basic.authorization.cryostat.${base64(user:pass)}`\nWebSocket SubProtocol header.\n\nIf no appropriate auth manager is configured or can be automatically determined\nthen the fallback is the NoopAuthManager, which does no external validation\ncalls and simply accepts any provided token or credentials.\n\n## INCOMING JMX CONNECTION AUTHENTICATION\n\nJMX connections into `cryostat` are secured using the default username\n`\"cryostat\"` and a randomly generated password.  The environment variables\n`CRYOSTAT_RJMX_USER` and `CRYOSTAT_RJMX_PASS` can be used to override\nthe default username and specify a password.\n\n## API\n\nCryostat exposes an HTTP API that provides the backing for its web interface,\nbut is also intended as an automation or extension point for external clients.\nFor details about this API see [HTTP_API.md](./docs/HTTP_API.md),\n[GRAPHQL.md](./docs/GRAPHQL.md), and\n[DISCOVERY_PLUGINS.md](./docs/DISCOVERY_PLUGINS.md).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryostatio%2Fcryostat-legacy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcryostatio%2Fcryostat-legacy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryostatio%2Fcryostat-legacy/lists"}