Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 6. Service Registry release notes
Service Registry 2.3 is provided as a General Availability release. Service Registry is a datastore for standard event schemas and API designs, and is based on the Apicurio Registry open source community project.
You can use Service Registry to manage and share the structure of your data using a web console, REST API, Maven plug-in, or Java client. For example, client applications can dynamically push or pull the latest schema updates to or from Service Registry without needing to redeploy. You can also create optional rules to govern how Service Registry content evolves over time. These rules include content validation and backwards or forwards compatibility of schema or API versions.
6.1. Service Registry installation options
You can install Service Registry on OpenShift with either of the following data storage options:
- PostgreSQL database
- Red Hat AMQ Streams
For more details, see Installing and deploying Service Registry on OpenShift.
6.2. Service Registry supported platforms
Service Registry 2.3 supports the following platform component versions:
- Red Hat OpenShift Container Platform 4.8 - 4.12
- Red Hat OpenShift Service on AWS
- Microsoft Azure Red Hat OpenShift
- PostgreSQL 12 - 15
- Red Hat AMQ Streams 2.1 - 2.3
- Red Hat Single Sign-On (RH-SSO) 7.6
- OpenJDK 11
6.3. Service Registry new features
Service Registry 2.3 includes the following new features:
- Service Registry authentication and authorization
- Expanded role-based authorization - you can now configure role-based authorization in Service Registry, as well as in RH-SSO as previously. If role-based authorization is enabled in the Service Registry application, you can use the web console or REST API to control access.
- Expanded owner-based authorization - you can now enable the owner-based authorization option at the artifact-group level, as well as at the artifact level as previously.
- Anonymous read access - when the anonymous read access option is enabled, unauthenticated (anonymous) users have read-only access to all artifacts.
- Authenticated read access - when the authenticated read access option is enabled, any authenticated user has read-only access to all artifacts, even if the user has not been granted any Service Registry roles.
- HTTP basic authentication - when this option is enabled, users or client applications can use HTTP basic authentication to access Service Registry.
- Custom TLS certificate for Kafka storage - when using Kafka for storage, users can now securely connect to Kafka using a custom TLS certificate.
- Change artifact owner - administrators or artifact owners can change the owner of a specific schema or API artifact by using the REST API or web console.
- Operational and monitoring improvements
- Audit logging - any changes to Service Registry data result in an audit log entry.
- Prometheus metrics - metrics are exposed in Prometheus format for use in monitoring.
- Sentry integration - optional integration with Sentry 1.x.
- Operator improvements
-
Custom environment variables - you can now set arbitrary environment variables in the
ApicurioRegistrycustom resource. These variables are applied to Service Registry using theDeploymentresource. - Support for PodDisruptionBudget - This resource is automatically created to ensure that at most one replica is unavailable.
- Support for NetworkPolicy - the Service Registry Operator creates an ingress network policy for port 8080.
-
Custom environment variables - you can now set arbitrary environment variables in the
- Artifact references
- Artifacts can now reference other artifacts in Service Registry. Many supported artifact types allow references from one file to another. For example, an OpenAPI file might have a data type with a property that references a JSON schema defined in another file. Typically, these references have a syntax specific to the artifact type. You can now use the REST API to create mappings so that type-specific references can be resolved to artifacts registered in Service Registry.
- Dynamic global configuration of Service Registry instances
- Service Registry has many global configuration options that are typically set at deployment time. A subset of these options are now also configurable at runtime for a Service Registry instance. You can manage these options at runtime by using the REST API or web console. For example, these options include owner-based authorization, anonymous read access, and authenticated read access.
- Upload artifact from URL
- You can now upload a schema or API artifact from a URL, in addition to the already supported upload from a file. You can upload by using the Service Registry web console or the REST API.
- Web console improvements
-
Import and export of Service Registry data - admin users can now use the web console to export all Service Registry data in a
.zipfile, as well as using the REST API as previously. They can then import this.zipfile into a different Service Registry deployment. - Full support for artifact properties - artifacts in Service Registry can have user-defined and editable metadata such as name, description, labels (simple keyword list), and properties (name/value pairs). The web console has been enhanced to support displaying and editing properties, in addition to using the REST API as previously.
- Documentation generation for AsyncAPI artifacts - AsyncAPI artifacts now support the Documentation tab on the artifact details page. This tab displays human-readable documentation generated from the AsyncAPI content. This feature was previously available only for OpenAPI artifacts.
- Option to display JSON as YAML - for artifact types that are JSON formatted, the Content tab on the artifact details page now supports switching between JSON and YAML formats.
-
Import and export of Service Registry data - admin users can now use the web console to export all Service Registry data in a
- REST API improvements
-
Improved /users/me endpoint - the Service Registry core REST API has a
/users/meendpoint that returns information about the current authenticated user. You can use this endpoint to inspect a user’s assigned role and determine their capabilities. - Updated support for Confluent Compatibility API - Service Registry now supports the Confluent Schema Registry API version 6.
-
Improved /users/me endpoint - the Service Registry core REST API has a
Service Registry user documentation and examples
The documentation library has been updated with the new features available in version 2.3:
The open source demonstration applications have also been updated:
6.4. Service Registry deprecated features
- Service Registry version 1.x
- Service Registry version 1.x was deprecated in version 2.0 and is no longer fully supported. For more details, see the Red Hat Application Services Product Update and Support Policy.
6.5. Upgrading and migrating Service Registry deployments
You can upgrade automatically from Service Registry 2.0 to Service Registry 2.3 on OpenShift. There is no automatic upgrade from Service Registry 1.x to Service Registry 2.x, and a migration process is required.
6.5.1. Upgrading a Service Registry 2.0 deployment on OpenShift
You can upgrade from Service Registry 2.0.3 on OpenShift 4.9 to Service Registry 2.3.x on OpenShift 4.11 or later. You must upgrade both your Service Registry and your OpenShift versions, and upgrade OpenShift one minor version at a time.
Prerequisites
- You already have Service Registry 2.0.3 installed on OpenShift 4.9.
Procedure
- In the OpenShift Container Platform web console, click Administration and then Cluster Settings.
-
Click the pencil icon next to the Channel field, and select the next minor
candidateversion (for example, change fromstable-4.9tocandidate-4.10). - Click Save and then Update, and wait until the upgrade is complete.
-
If the OpenShift version is less than 4.11, repeat steps 2 and 3, and select
candidate-4.11or later. - Click Operators > Installed Operators > Red Hat Integration - Service Registry.
-
Ensure that the Update channel is set to
2.x. -
If the Update approval is set to Automatic, the upgrade should be approved and installed immediately after the
2.xchannel is set. - If the Update approval is set to Manual, click Install.
- Wait until the Operator is deployed and the Service Registry pod is deployed.
- Verify that your Service Registry system is up and running.
Additional resources
- For more details on how to set the Operator update channel in the OpenShift Container Platform web console, see Changing the update channel for an Operator.
6.5.2. Migrating a Service Registry 1.1 deployment on OpenShift
For details on migrating a Service Registry 1.1 deployment to Service Registry 2.x, see Migrating Service Registry deployments.
6.6. Service Registry resolved issues
| Issue | Description |
|---|---|
| REST API endpoint for core v1 compatibility not properly protected by authentication. | |
| Web console incorrectly redirects to HTTP instead of HTTPS. | |
|
Service Registry throws | |
| Confluent compatibility layer not working with JSON Schema artifacts. | |
|
| |
| Confluent compatibility layer’s schema DTO is not fully compatible. | |
| Web console does not properly obey the disable roles feature. | |
| Confluent compatibility API v6 does not return artifact. | |
|
Passing | |
|
Web console displays inconsistent | |
|
Global compatibility rule execution broken for | |
| Transitive compatibility rules might give false positives. |
| Issue | Description |
|---|---|
|
Avro compatibility check does not work correctly for | |
| Add option to minify Avro with Service Registry Maven plug-in. | |
| Make max subjects configurable in Confluent compatibility API. | |
| Throw exception when an empty schema is provided in the Confluent compatibility API. | |
| Fix handling of default JSON value in the Confluent compatibility API. | |
|
On slow machines, | |
| Fix version ordering in Service Registry compatibility rules. | |
|
Support | |
| Configuring Service Registry event sourcing gives HTTP error. | |
|
Protobuf schema version upload failing with |
6.7. Service Registry resolved CVEs
| Issue | Description |
|---|---|
| CVE-2022-25858 terser: Insecure use of regular expressions leads to ReDoS. | |
| CVE-2022-37734 graphql-java: DoS by malicious query. | |
| CVE-2022-25857 snakeyaml: DoS due to missing nested depth limitation for collections. | |
| CVE-2022-31129 moment: Inefficient parsing algorithm resulting in DoS. | |
| CVE-2022-25647 com.google.code.gson-gson: Deserialization of untrusted data. | |
|
CVE-2022-24773 node-forge: Signature verification leniency in checking | |
| CVE-2022-24772 node-forge: Signature verification failing to check tailing garbage bytes can lead to signature forgery. | |
|
CVE-2022-24771 node-forge: Signature verification leniency in checking | |
| CVE-2022-26520 jdbc-postgresql: Arbitrary file write vulnerability. | |
|
CVE-2022-0536 follow-redirects: Exposure of sensitive information by | |
| CVE-2022-0235 node-fetch: Exposure of sensitive information to an unauthorized actor. | |
| CVE-2022-23647 prismjs: Improperly escaped output allows an XSS vulnerability. | |
| CVE-2022-0981 quarkus: Privilege escalation vulnerability with RestEasy Reactive scope leakage in Quarkus. | |
| CVE-2022-21724 quarkus-jdbc-postgresql-deployment: Unchecked class instantiation when providing plug-in classes. | |
| CVE-2021-22569 protobuf-java: Potential DoS in the parsing procedure for binary data. | |
| CVE-2021-41269 cron-utils: Template injection leading to unauthenticated Remote Code Execution vulnerability. | |
|
CVE-2021-37136 netty-codec: | |
|
CVE-2021-37137 netty-codec: |
6.8. Service Registry known issues
The following known issues apply in Service Registry 2.3.3:
Service Registry core known issues
IPT-814 - Service Registry logout feature incompatible with RH-SSO 7.6
In RH-SSO 7.6, the redirect_uri parameter used with the logout endpoint is deprecated. For more details, see the RH-SSO 7.6 Upgrading Guide. Because of this deprecation, when Service Registry is secured by using the RH-SSO Operator, clicking the Logout button displays the Invalid parameter: redirect_uri error.
For a workaround, see https://access.redhat.com/solutions/6980926.
IPT-701 - CVE-2022-23221 H2 allows loading custom classes from remote servers through JNDI
When Service Registry data is stored in AMQ Streams, the H2 database console allows remote attackers to execute arbitrary code by using the JDBC URL. Service Registry is not vulnerable by default and a malicious configuration change is required.
Service Registry Operator known issues
Operator-42 - Autogeneration of OpenShift route might use wrong base host value
If multiple routerCanonicalHostname values are specified, autogeneration of the Service Registry OpenShift route might use a wrong base host value.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}