v2.1.0

• update to JDK 17
• support multiple FQDNs
• add anti-affinity rule to not schedule multiple replicas on the same node
• allow to modify the Service resource by using kubernetesServicePatches
• Fix: operator not syncing after some time
• Fix: update Ingress resource if kubernetesIngressPatches has changed

v2.0.0

See https://github.com/openanalytics/shinyproxy-operator/tree/v2.0.0#update-to-200

v1.1.0

This release makes the ShinyProxy Operator compatible with Kubernetes 1.22 and later (contributed by @dev-rowbot).

v1.0.3

This release contains a security update of the log4j library. This fixes CVE-2021-45105 see GHSA-p6xc-xr62-6r2g.

Version 1.0.1 of the operator includes log4j 2.15.0, which fixes CVE-2021-44228 and version 1.0.2 of the operator includes log4j 2.16.0 which fixes CVE-2021-45046. This release updates log4j to 2.17.0 in order to fix CVE-2021-45105.
In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.

v1.0.2

This release contains a security update of the log4j library. This fixes CVE-2021-45046, see GHSA-7rjr-3q55-vv33 .

Version 1.0.1 of the operator includes log4j 2.15.0, which fixes CVE-2021-44228, however this fix is incomplete. This release updates log4j to 2.16.0.
In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.

v1.0.1

This release contains a security update of the log4j library. This fixes CVE-2021-44228, see GHSA-jfh8-c2jp-5v3q .

In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.

v1.0.0

First stable release of the ShinyProxy Operator!

After being in development for one year, this release is the first stable version of the operator.
See https://hub.docker.com/r/openanalytics/shinyproxy-operator for the Docker image.