Installing and deploying Service Registry on OpenShift
Install, deploy, and configure Service Registry 2.4
Abstract
Preface Copy linkLink copied to clipboard!
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. To provide feedback, highlight text in a document and add comments.
Prerequisites
- You are logged in to the Red Hat Customer Portal.
- In the Red Hat Customer Portal, the document is in the Multi-page HTML viewing format.
Procedure
To provide your feedback, perform the following steps:
Click the Feedback button in the top-right corner of the document to see existing feedback.
NoteThe feedback feature is enabled only in the Multi-page HTML format.
- Highlight the section of the document where you want to provide feedback.
Click the Add Feedback pop-up that appears near the highlighted text.
A text box appears in the feedback section on the right side of the page.
Enter your feedback in the text box and click Submit.
A documentation issue is created.
- To view the issue, click the issue link in the feedback view.
Chapter 1. Service Registry Operator quickstart Copy linkLink copied to clipboard!
You can quickly install the Service Registry Operator on the command line by using Custom Resource Definitions (CRDs).
The quickstart example deploys your Service Registry instance with storage in an SQL database:
The recommended installation option for production environments is the OpenShift OperatorHub. The recommended storage option is an SQL database for performance, stability, and data management.
1.1. Quickstart Service Registry Operator installation Copy linkLink copied to clipboard!
You can quickly install and deploy the Service Registry Operator on the command line, without the Operator Lifecycle Manager, by using a downloaded set of installation files and example CRDs.
Prerequisites
- You are logged in to an OpenShift cluster with administrator access.
-
You have the OpenShift
oc
command-line client installed. For more details, see the OpenShift CLI documentation.
Procedure
-
Browse to Red Hat Software Downloads, select the product version, and download the examples in the Service Registry CRDs
.zip
file. -
Extract the downloaded CRDs
.zip
file and change to theapicurio-registry-install-examples
directory. Create an OpenShift project for the Service Registry Operator installation, for example:
export NAMESPACE="apicurio-registry" oc new-project "$NAMESPACE"
export NAMESPACE="apicurio-registry" oc new-project "$NAMESPACE"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following command to apply the example CRD in the
install/install.yaml
file:cat install/install.yaml | sed "s/apicurio-registry-operator-namespace/$NAMESPACE/g" | oc apply -f -
cat install/install.yaml | sed "s/apicurio-registry-operator-namespace/$NAMESPACE/g" | oc apply -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter
oc get deployment
to check the readiness of the Service Registry Operator. For example, the output should be as follows:NAME READY UP-TO-DATE AVAILABLE AGE apicurio-registry-operator 1/1 1 1 XmYs
NAME READY UP-TO-DATE AVAILABLE AGE apicurio-registry-operator 1/1 1 1 XmYs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2. Quickstart Service Registry instance deployment Copy linkLink copied to clipboard!
To create your Service Registry instance deployment, use the SQL database storage option to connect to an existing PostgreSQL database.
Prerequisites
- Ensure that the Service Registry Operator is installed.
- You have a PostgreSQL database that is reachable from your OpenShift cluster.
Procedure
Open the
examples/apicurioregistry_sql_cr.yaml
file in an editor and view theApicurioRegistry
custom resource (CR):Example CR for SQL storage
Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the
dataSource
section, replace the example settings with your database connection details. For example:dataSource: url: "jdbc:postgresql://postgresql.apicurio-registry.svc:5432/registry" userName: "pgadmin" password: "pgpass"
dataSource: url: "jdbc:postgresql://postgresql.apicurio-registry.svc:5432/registry" userName: "pgadmin" password: "pgpass"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following commands to apply the updated
ApicurioRegistry
CR in the namespace with the Service Registry Operator, and wait for the Service Registry instance to deploy:oc project "$NAMESPACE" oc apply -f ./examples/apicurioregistry_sql_cr.yaml
oc project "$NAMESPACE" oc apply -f ./examples/apicurioregistry_sql_cr.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter
oc get deployment
to check the readiness of the Service Registry instance. For example, the output should be as follows:NAME READY UP-TO-DATE AVAILABLE AGE example-apicurioregistry-sql-deployment 1/1 1 1 XmYs
NAME READY UP-TO-DATE AVAILABLE AGE example-apicurioregistry-sql-deployment 1/1 1 1 XmYs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter
oc get routes
to get theHOST/PORT
URL to launch the Service Registry web console in your browser. For example:example-apicurioregistry-sql.apicurio-registry.router-default.apps.mycluster.myorg.mycompany.com
example-apicurioregistry-sql.apicurio-registry.router-default.apps.mycluster.myorg.mycompany.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 2. Installing Service Registry on OpenShift Copy linkLink copied to clipboard!
This chapter explains how to install Service Registry on OpenShift Container Platform:
Prerequisites
- Read the introduction in the Service Registry User Guide
2.1. Installing Service Registry from the OpenShift OperatorHub Copy linkLink copied to clipboard!
You can install the Service Registry Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators. For more details, see Understanding OperatorHub.
You can install more than one instance of Service Registry depending on your environment. The number of instances depends on the number and type of artifacts stored in Service Registry and on your chosen storage option.
Prerequisites
- You must have cluster administrator access to an OpenShift cluster.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
Create a new OpenShift project:
- In the left navigation menu, click Home, Project, and then Create Project.
-
Enter a project name, for example,
my-project
, and click Create.
- In the left navigation menu, click Operators and then OperatorHub.
-
In the Filter by keyword text box, enter
registry
to find the Red Hat Integration - Service Registry Operator. - Read the information about the Operator, and click Install to display the Operator subscription page.
Select your subscription settings, for example:
Update Channel: Select one of the following:
- 2.x: Includes all minor and patch updates, such as 2.3.0 and 2.0.3. For example, an installation on 2.0.x will upgrade to 2.3.x.
- 2.0.x: Includes patch updates only, such as 2.0.1 and 2.0.2. For example, an installation on 2.0.x will ignore 2.3.x.
Installation Mode: Select one of the following:
- All namespaces on the cluster (default)
- A specific namespace on the cluster and then my-project
- Approval Strategy: Select Automatic or Manual
- Click Install, and wait a few moments until the Operator is ready for use.
Chapter 3. Deploying Service Registry storage in AMQ Streams Copy linkLink copied to clipboard!
This chapter explains how to install and configure Service Registry data storage in AMQ Streams.
- Section 3.1, “Installing AMQ Streams from the OpenShift OperatorHub”
- Section 3.2, “Configuring Service Registry with Kafka storage on OpenShift”
- Section 3.3, “Configuring Kafka storage with TLS security”
- Section 3.4, “Configuring Kafka storage with SCRAM security”
- Section 3.5, “Configuring OAuth authentication for Kafka storage”
Prerequisites
3.1. Installing AMQ Streams from the OpenShift OperatorHub Copy linkLink copied to clipboard!
If you do not already have AMQ Streams installed, you can install the AMQ Streams Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators. For more details, see Understanding OperatorHub.
Prerequisites
- You must have cluster administrator access to an OpenShift cluster
- See Deploying and Upgrading AMQ Streams on OpenShift for detailed information on installing AMQ Streams. This section shows a simple example of installing using the OpenShift OperatorHub.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
-
Change to the OpenShift project in which you want to install AMQ Streams. For example, from the Project drop-down, select
my-project
. - In the left navigation menu, click Operators and then OperatorHub.
-
In the Filter by keyword text box, enter
AMQ Streams
to find the Red Hat Integration - AMQ Streams Operator. - Read the information about the Operator, and click Install to display the Operator subscription page.
Select your subscription settings, for example:
- Update Channel and then amq-streams-2.4.x
Installation Mode: Select one of the following:
- All namespaces on the cluster (default)
- A specific namespace on the cluster > my-project
- Approval Strategy: Select Automatic or Manual
- Click Install, and wait a few moments until the Operator is ready for use.
Additional resources
3.2. Configuring Service Registry with Kafka storage on OpenShift Copy linkLink copied to clipboard!
This section explains how to configure Kafka-based storage for Service Registry using AMQ Streams on OpenShift. The kafkasql
storage option uses Kafka storage with an in-memory H2 database for caching. This storage option is suitable for production environments when persistent
storage is configured for the Kafka cluster on OpenShift.
You can install Service Registry in an existing Kafka cluster or create a new Kafka cluster, depending on your environment.
Prerequisites
- You must have an OpenShift cluster with cluster administrator access.
- You must have already installed Service Registry. See Chapter 2, Installing Service Registry on OpenShift.
- You must have already installed AMQ Streams. See Section 3.1, “Installing AMQ Streams from the OpenShift OperatorHub”.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
If you do not already have a Kafka cluster configured, create a new Kafka cluster using AMQ Streams. For example, in the OpenShift OperatorHub:
- Click Installed Operators and then Red Hat Integration - AMQ Streams.
- Under Provided APIs and then Kafka, click Create Instance to create a new Kafka cluster.
Edit the custom resource definition as appropriate, and click Create.
WarningThe default example creates a cluster with 3 Zookeeper nodes and 3 Kafka nodes with
ephemeral
storage. This temporary storage is suitable for development and testing only, and not for production. For more details, see Deploying and Upgrading AMQ Streams on OpenShift.
- After the cluster is ready, click Provided APIs > Kafka > my-cluster > YAML.
In the
status
block, make a copy of thebootstrapServers
value, which you will use later to deploy Service Registry. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Installed Operators > Red Hat Integration - Service Registry > ApicurioRegistry > Create ApicurioRegistry.
Paste in the following custom resource definition, but use your
bootstrapServers
value that you copied earlier:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Create and wait for the Service Registry route to be created on OpenShift.
Click Networking > Route to access the new route for the Service Registry web console. For example:
http://example-apicurioregistry-kafkasql.my-project.my-domain-name.com/
http://example-apicurioregistry-kafkasql.my-project.my-domain-name.com/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To configure the Kafka topic that Service Registry uses to store data, click Installed Operators > Red Hat Integration - AMQ Streams > Provided APIs > Kafka Topic > kafkasql-journal > YAML. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow WarningYou must configure the Kafka topic used by Service Registry (named
kafkasql-journal
by default) with a compaction cleanup policy, otherwise a data loss might occur.
3.3. Configuring Kafka storage with TLS security Copy linkLink copied to clipboard!
You can configure the AMQ Streams Operator and Service Registry Operator to use an encrypted Transport Layer Security (TLS) connection.
Prerequisites
- You have installed the Service Registry Operator using the OperatorHub or command line.
- You have installed the AMQ Streams Operator or have Kafka accessible from your OpenShift cluster.
This section assumes that the AMQ Streams Operator is available, however you can use any Kafka deployment. In that case, you must manually create the Openshift secrets that the Service Registry Operator expects.
Procedure
- In the OpenShift web console, click Installed Operators, select the AMQ Streams Operator details, and then the Kafka tab.
- Click Create Kafka to provision a new Kafka cluster for Service Registry storage.
Configure the
authorization
andtls
fields to use TLS authentication for the Kafka cluster, for example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The default Kafka topic name automatically created by Service Registry to store data is
kafkasql-journal
. You can override this behavior or the default topic name by setting environment variables. The default values are as follows:-
REGISTRY_KAFKASQL_TOPIC_AUTO_CREATE=true
-
REGISTRY_KAFKASQL_TOPIC=kafkasql-journal
If you decide not to create the Kafka topic manually, skip the next step.
-
Click the Kafka Topic tab, and then Create Kafka Topic to create the
kafkasql-journal
topic:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Kafka User resource to configure authentication and authorization for the Service Registry user. You can specify a user name in the
metadata
section or use the defaultmy-user
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThis simple example assumes admin permissions and creates the Kafka topic automatically. You must configure the
authorization
section specifically for the topics and resources that the Service Registry requires.The following example shows the minimum configuration required when the Kafka topic is created manually:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Click Workloads and then Secrets to find two secrets that AMQ Streams creates for Service Registry to connect to the Kafka cluster:
-
my-cluster-cluster-ca-cert
- contains the PKCS12 truststore for the Kafka cluster my-user
- contains the user’s keystoreNoteThe name of the secret can vary based on your cluster or user name.
-
If you create the secrets manually, they must contain the following key-value pairs:
my-cluster-ca-cert
-
ca.p12
- truststore in PKCS12 format -
ca.password
- truststore password
-
my-user
-
user.p12
- keystore in PKCS12 format -
user.password
- keystore password
-
Configure the following example configuration to deploy the Service Registry.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You must use a different bootstrapServers
address than in the plain insecure use case. The address must support TLS connections and is found in the specified Kafka resource under the type: tls
field.
3.4. Configuring Kafka storage with SCRAM security Copy linkLink copied to clipboard!
You can configure the AMQ Streams Operator and Service Registry Operator to use Salted Challenge Response Authentication Mechanism (SCRAM-SHA-512) for the Kafka cluster.
Prerequisites
- You have installed the Service Registry Operator using the OperatorHub or command line.
- You have installed the AMQ Streams Operator or have Kafka accessible from your OpenShift cluster.
This section assumes that AMQ Streams Operator is available, however you can use any Kafka deployment. In that case, you must manually create the Openshift secrets that the Service Registry Operator expects.
Procedure
- In the OpenShift web console, click Installed Operators, select the AMQ Streams Operator details, and then the Kafka tab.
- Click Create Kafka to provision a new Kafka cluster for Service Registry storage.
Configure the
authorization
andtls
fields to use SCRAM-SHA-512 authentication for the Kafka cluster, for example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The default Kafka topic name automatically created by Service Registry to store data is
kafkasql-journal
. You can override this behavior or the default topic name by setting environment variables. The default values are as follows:-
REGISTRY_KAFKASQL_TOPIC_AUTO_CREATE=true
-
REGISTRY_KAFKASQL_TOPIC=kafkasql-journal
If you decide not to create the Kafka topic manually, skip the next step.
-
Click the Kafka Topic tab, and then Create Kafka Topic to create the
kafkasql-journal
topic:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Kafka User resource to configure SCRAM authentication and authorization for the Service Registry user. You can specify a user name in the
metadata
section or use the defaultmy-user
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThis simple example assumes admin permissions and creates the Kafka topic automatically. You must configure the
authorization
section specifically for the topics and resources that the Service Registry requires.The following example shows the minimum configuration required when the Kafka topic is created manually:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Click Workloads and then Secrets to find two secrets that AMQ Streams creates for Service Registry to connect to the Kafka cluster:
-
my-cluster-cluster-ca-cert
- contains the PKCS12 truststore for the Kafka cluster my-user
- contains the user’s keystoreNoteThe name of the secret can vary based on your cluster or user name.
-
If you create the secrets manually, they must contain the following key-value pairs:
my-cluster-ca-cert
-
ca.p12
- the truststore in PKCS12 format -
ca.password
- truststore password
-
my-user
-
password
- user password
-
Configure the following example settings to deploy the Service Registry:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You must use a different bootstrapServers
address than in the plain insecure use case. The address must support TLS connections, and is found in the specified Kafka resource under the type: tls
field.
3.5. Configuring OAuth authentication for Kafka storage Copy linkLink copied to clipboard!
When using Kafka-based storage in AMQ Streams, Service Registry supports accessing a Kafka cluster that requires OAuth authentication. To enable this support, you must to set some environment variables in your Service Registry deployment.
When you set these environment variables, the Kafka producer and consumer applications in Service Registry will use this configuration to authenticate to the Kafka cluster over OAuth.
Prerequisites
- You must have already configured Kafka-based storage of Service Registry data in AMQ Streams. See Section 3.2, “Configuring Service Registry with Kafka storage on OpenShift”.
Procedure
Set the following environment variables in your Service Registry deployment:
Expand Environment variable Description Default value ENABLE_KAFKA_SASL
Enables SASL OAuth authentication for Service Registry storage in Kafka. You must set this variable to
true
for the other variables to have effect.false
CLIENT_ID
The client ID used to authenticate to Kafka.
-
CLIENT_SECRET
The client secret used to authenticate to Kafka.
-
OAUTH_TOKEN_ENDPOINT_URI
The URL of the OAuth identity server.
http://localhost:8090
Additional resources
- For an example of how to set Service Registry environment variables on OpenShift, see Section 6.1, “Configuring Service Registry health checks on OpenShift”
Chapter 4. Deploying Service Registry storage in a PostgreSQL database Copy linkLink copied to clipboard!
This chapter explains how to install, configure, and manage Service Registry data storage in a PostgreSQL database.
Prerequisites
4.1. Installing a PostgreSQL database from the OpenShift OperatorHub Copy linkLink copied to clipboard!
If you do not already have a PostgreSQL database Operator installed, you can install a PostgreSQL Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators. For more details, see Understanding OperatorHub.
Prerequisites
- You must have cluster administrator access to an OpenShift cluster.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
-
Change to the OpenShift project in which you want to install the PostgreSQL Operator. For example, from the Project drop-down, select
my-project
. - In the left navigation menu, click Operators and then OperatorHub.
-
In the Filter by keyword text box, enter
PostgreSQL
to find an Operator suitable for your environment, for example, Crunchy PostgreSQL for OpenShift. - Read the information about the Operator, and click Install to display the Operator subscription page.
Select your subscription settings, for example:
- Update Channel: stable
- Installation Mode: A specific namespace on the cluster and then my-project
- Approval Strategy: Select Automatic or Manual
Click Install, and wait a few moments until the Operator is ready for use.
ImportantYou must read the documentation from your chosen PostgreSQL Operator for details on how to create and manage your database.
Additional resources
4.2. Configuring Service Registry with PostgreSQL database storage on OpenShift Copy linkLink copied to clipboard!
This section explains how to configure storage for Service Registry on OpenShift using a PostgreSQL database Operator. You can install Service Registry in an existing database or create a new database, depending on your environment. This section shows a simple example using the PostgreSQL Operator by Dev4Ddevs.com.
Prerequisites
- You must have an OpenShift cluster with cluster administrator access.
- You must have already installed Service Registry. See Chapter 2, Installing Service Registry on OpenShift.
- You must have already installed a PostgreSQL Operator on OpenShift. For example, see Section 4.1, “Installing a PostgreSQL database from the OpenShift OperatorHub”.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
-
Change to the OpenShift project in which Service Registry and your PostgreSQL Operator are installed. For example, from the Project drop-down, select
my-project
. - Create a PostgreSQL database for your Service Registry storage. For example, click Installed Operators, PostgreSQL Operator by Dev4Ddevs.com, and then Create database.
Click YAML and edit the database settings as follows:
-
name
: Change the value toregistry
-
image
: Change the value tocentos/postgresql-12-centos7
-
Edit any other database settings as needed depending on your environment, for example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Create, and wait until the database is created.
- Click Installed Operators > Red Hat Integration - Service Registry > ApicurioRegistry > Create ApicurioRegistry.
Paste in the following custom resource definition, and edit the values for the database
url
and credentials to match your environment:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Create and wait for the Service Registry route to be created on OpenShift.
Click Networking > Route to access the new route for the Service Registry web console. For example:
http://example-apicurioregistry-sql.my-project.my-domain-name.com/
http://example-apicurioregistry-sql.my-project.my-domain-name.com/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. Backing up Service Registry PostgreSQL storage Copy linkLink copied to clipboard!
When using storage in a PostgreSQL database, you must ensure that the data stored by Service Registry is backed up regularly.
SQL Dump is a simple procedure that works with any PostgreSQL installation. This uses the pg_dump utility to generate a file with SQL commands that you can use to recreate the database in the same state that it was in at the time of the dump.
pg_dump
is a regular PostgreSQL client application, which you can execute from any remote host that has access to the database. Like any other client, the operations that can perform are limited to the user permissions.
Procedure
Use the
pg_dump
command to redirect the output to a file:pg_dump dbname > dumpfile
$ pg_dump dbname > dumpfile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can specify the database server that
pg_dump
connects to using the-h host
and-p port
options.You can reduce large dump files using a compression tool, such as gzip, for example:
pg_dump dbname | gzip > filename.gz
$ pg_dump dbname | gzip > filename.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
- For details on client authentication, see the PostgreSQL documentation.
- For details on importing and exporting registry content, see Managing Service Registry content using the REST API.
4.4. Restoring Service Registry PostgreSQL storage Copy linkLink copied to clipboard!
You can restore SQL Dump files created by pg_dump
using the psql
utility.
Prerequisites
-
You must have already backed up your PostgreSQL datbase using
pg_dump
. See Section 4.3, “Backing up Service Registry PostgreSQL storage”. - All users who own objects or have permissions on objects in the dumped database must already exist.
Procedure
Enter the following command to create the database:
createdb -T template0 dbname
$ createdb -T template0 dbname
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following command to restore the SQL dump
psql dbname < dumpfile
$ psql dbname < dumpfile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Run ANALYZE on each database so the query optimizer has useful statistics.
Chapter 5. Securing Service Registry deployments Copy linkLink copied to clipboard!
This chapter explains how to configure security settings for your Service Registry deployment on OpenShift:
- Section 5.1, “Securing Service Registry using the Red Hat Single Sign-On Operator”
- Section 5.2, “Configuring Service Registry authentication and authorization with Red Hat Single Sign-On”
- Section 5.3, “Service Registry authentication and authorization configuration options”
- Section 5.4, “Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster”
- Section 5.5, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”
Service Registry provides authentication and authorization using Red Hat Single Sign-On based on OpenID Connect (OIDC) or HTTP basic. You can configure the required settings automatically using the Red Hat Single Sign-On Operator, or manually configure them in Red Hat Single Sign-On and Service Registry.
Service Registry provides role-based authentication and authorization for the Service Registry web console and core REST API using Red Hat Single Sign-On. Service Registry also provides content-based authorization at the schema or API level, where only the artifact creator has write access. You can also configure an HTTPS connection to Service Registry from inside or outside an OpenShift cluster.
5.1. Securing Service Registry using the Red Hat Single Sign-On Operator Copy linkLink copied to clipboard!
The following procedure shows how to configure a Service Registry REST API and web console to be protected by Red Hat Single Sign-On.
Service Registry supports the following user roles:
Name | Capabilities |
---|---|
| Full access, no restrictions. |
|
Create artifacts and configure artifact rules. Cannot modify global rules, perform import/export, or use |
|
View and search only. Cannot modify artifacts or rules, perform import/export, or use |
There is a related configuration option in the ApicurioRegistry
CRD that you can use to set the web console to read-only mode. However, this configuration does not affect the REST API.
Prerequisites
- You must have already installed the Service Registry Operator.
- You must install the Red Hat Single Sign-On Operator or have Red Hat Single Sign-On accessible from your OpenShift cluster.
The example configuration in this procedure is intended for development and testing only. To keep the procedure simple, it does not use HTTPS and other defenses recommended for a production environment. For more details, see the Red Hat Single Sign-On documentation.
Procedure
- In the OpenShift web console, click Installed Operators and Red Hat Single Sign-On Operator, and then the Keycloak tab.
Click Create Keycloak to provision a new Red Hat Single Sign-On instance for securing a Service Registry deployment. You can use the default value, for example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Wait until the instance has been created, and click Networking and then Routes to access the new route for the keycloak instance.
- Click the Location URL and copy the displayed URL value for later use when deploying Service Registry.
Click Installed Operators and Red Hat Single Sign-On Operator, and click the Keycloak Realm tab, and then Create Keycloak Realm to create a
registry
example realm:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantYou must customize this
KeycloakRealm
resource with values suitable for your environment if you are deploying to production. You can also create and manage realms using the Red Hat Single Sign-On web console.If your cluster does not have a valid HTTPS certificate configured, you can create the following HTTP
Service
andIngress
resources as a temporary workaround:Click Networking and then Services, and click Create Service using the following example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Click Networking and then Ingresses, and click Create Ingress using the following example::
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Modify the
host
value to create a route accessible for the Service Registry user, and use it instead of the HTTPS route created by Red Hat Single Sign-On Operator.
Click the Service Registry Operator, and on the ApicurioRegistry tab, click Create ApicurioRegistry, using the following example, but replace your values in the
keycloak
section.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Configuring Service Registry authentication and authorization with Red Hat Single Sign-On Copy linkLink copied to clipboard!
This section explains how to manually configure authentication and authorization options for Service Registry using Red Hat Single Sign-On.
Alternatively, for details on how to configure these settings automatically, see Section 5.1, “Securing Service Registry using the Red Hat Single Sign-On Operator”.
You can enable authentication for the Service Registry web console and core REST API using Red Hat Single Sign-On based on OAuth using OpenID Connect (OIDC). The same Red Hat Single Sign-On realm and users are federated across the Service Registry web console and core REST API using OpenID Connect so that you only require one set of credentials.
Service Registry provides role-based authorization for default admin, write, and read-only user roles. Service Registry also provides content-based authorization at the schema or API level, where only the creator of the registry artifact can update or delete it. Service Registry authentication and authorization settings are disabled by default.
Prerequisites
- Red Hat Single Sign-On is installed and running. For more details, see the Red Hat Single Sign-On user documentation.
- Service Registry is installed and running.
Procedure
-
In the Red Hat Single Sign-On Admin Console, create a Red Hat Single Sign-On realm for Service Registry. By default, Service Registry expects a realm name of
registry
. For more details on creating realms, see the Red Hat Single Sign-On user documentation. Create a Red Hat Single Sign-On client for the Service Registry API. By default, Service Registry expects the following settings:
-
Client ID:
registry-api
-
Client Protocol:
openid-connect
Access Type:
bearer-only
You can use the defaults for the other client settings.
NoteIf you are using Red Hat Single Sign-On service accounts, the client Access Type must be
confidential
instead ofbearer-only
.
-
Client ID:
Create a Red Hat Single Sign-On client for the Service Registry web console. By default, Service Registry expects the following settings:
-
Client ID:
apicurio-registry
-
Client Protocol:
openid-connect
-
Access Type:
public
-
Valid Redirect URLs:
http://my-registry-url:8080/*
Web Origins:
+
You can use the defaults for the other client settings.
-
Client ID:
In your Service Registry deployment on OpenShift, set the following Service Registry environment variables to configure authentication using Red Hat Single Sign-On:
Expand Table 5.2. Configuration for Service Registry authentication Environment variable Description Type Default AUTH_ENABLED
If set to
true
, the environment variables that follow are required.String
false
KEYCLOAK_URL
The URL of the Red Hat Single Sign-On authentication server to use.
String
None
KEYCLOAK_REALM
The Red Hat Single Sign-On realm used for authentication.
String
registry
KEYCLOAK_API_CLIENT_ID
The client ID for the Service Registry REST API.
String
registry-api
KEYCLOAK_UI_CLIENT_ID
The client ID for the Service Registry web console.
String
apicurio-registry
TipFor an example of setting environment variables on OpenShift, see Section 6.1, “Configuring Service Registry health checks on OpenShift”.
Set the following option to
true
to enable Service Registry user roles in Red Hat Single Sign-On:Expand Table 5.3. Configuration for Service Registry role-based authorization Environment variable Java system property Type Default value ROLE_BASED_AUTHZ_ENABLED
registry.auth.role-based-authorization
Boolean
false
When Service Registry user roles are enabled, you must assign Service Registry users to at least one of the following default user roles in your Red Hat Single Sign-On realm:
Expand Table 5.4. Default user roles for registry authentication and authorization Role Read artifacts Write artifacts Global rules Summary sr-admin
Yes
Yes
Yes
Full access to all create, read, update, and delete operations.
sr-developer
Yes
Yes
No
Access to create, read, update, and delete operations, except configuring global rules. This role can configure artifact-specific rules.
sr-readonly
Yes
No
No
Access to read and search operations only. This role cannot configure any rules.
Set the following to
true
to enable owner-only authorization for updates to schema and API artifacts in Service Registry:Expand Table 5.5. Configuration for owner-only authorization Environment variable Java system property Type Default value REGISTRY_AUTH_OBAC_ENABLED
registry.auth.owner-only-authorization
Boolean
false
5.3. Service Registry authentication and authorization configuration options Copy linkLink copied to clipboard!
Service Registry provides authentication options for OpenID Connect with Red Hat Single Sign-On or HTTP basic authentication.
Service Registry provides authorization options for role-based and content-based approaches:
- Role-based authorization for default admin, write, and read-only user roles.
- Content-based authorization for schema or API artifacts, where only the owner of the artifacts or artifact group can update or delete artifacts.
Service Registry authentication and authorization options are disabled by default.
This chapter provides details on the following configuration options:
- Service Registry authentication using OpenID Connect with Red Hat Single Sign-On
- Service Registry authentication using HTTP basic
- Service Registry role-based authorization
- Service Registry owner-only authorization
- Service Registry authenticated read access
- Service Registry anonymous read-only access
Service Registry authentication using OpenID Connect with Red Hat Single Sign-On
You can set the following environment variables to configure authentication for the Service Registry web console and API with Red Hat Single Sign-On:
Environment variable | Description | Type | Default |
---|---|---|---|
|
Enables authentication in Service Registry. When set to | String |
|
|
The URL of the Red Hat Single Sign-On authentication server. For example, | String | - |
|
The Red Hat Single Sign-On realm for authentication. For example, | String | - |
| The client ID for the Service Registry REST API. | String |
|
| The client ID for the Service Registry web console. | String |
|
Service Registry authentication using HTTP basic
By default, Service Registry supports authentication using OpenID Connect. Users or API clients must obtain an access token to make authenticated calls to the Service Registry REST API. However, because some tools do not support OpenID Connect, you can also configure Service Registry to support HTTP basic authentication by setting the following configuration option to true
:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
Service Registry HTTP basic client credentials cache expiry
You can also configure the HTTP basic client credentials cache expiry time. By default, when using HTTP basic authentication, Service Registry caches JWT tokens, and does not issue a new token when there is no need. You can configure the cache expiry time for JWT tokens, which is set to 10 mins by default.
When using Red Hat Single Sign-On, it is best to set this configuration to your Red Hat Single Sign-On JWT expiry time minus one minute. For example, if you have the expiry time set to 5
mins in Red Hat Single Sign-On, you should set the following configuration option to 4
mins:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Integer |
|
Service Registry role-based authorization
You can set the following option to true
to enable role-based authorization in Service Registry:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
You can then configure role-based authorization to use roles included in the user’s authentication token (for example, granted when authenticating using Red Hat Single Sign-On), or to use role mappings managed internally by Service Registry.
Use roles assigned in Red Hat Single Sign-On
To enable using roles assigned by Red Hat Single Sign-On, set the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
|
When set to | String |
|
| The name of the role that indicates a user is an admin. | String |
|
| The name of the role that indicates a user is a developer. | String |
|
| The name of the role that indicates a user has read-only access. | String |
|
When Service Registry is configured to use roles from Red Hat Single Sign-On, you must assign Service Registry users to at least one of the following user roles in Red Hat Single Sign-On. However, you can configure different user role names using the environment variables in Table 5.10, “Configuration for Service Registry role-based authorization using Red Hat Single Sign-On”.
Role name | Read artifacts | Write artifacts | Global rules | Description |
---|---|---|---|---|
| Yes | Yes | Yes | Full access to all create, read, update, and delete operations. |
| Yes | Yes | No | Access to create, read, update, and delete operations, except configuring global rules and import/export. This role can configure artifact-specific rules only. |
| Yes | No | No | Access to read and search operations only. This role cannot configure any rules. |
Manage roles directly in Service Registry
To enable using roles managed internally by Service Registry, set the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
|
When set to | String |
|
When using internally managed role mappings, users can be assigned a role using the /admin/roleMappings
endpoint in the Service Registry REST API. For more details, see Apicurio Registry REST API documentation.
Users can be granted exactly one role: ADMIN
, DEVELOPER
, or READ_ONLY
. Only users with admin privileges can grant access to other users.
Service Registry admin-override configuration
Because there are no default admin users in Service Registry, it is usually helpful to configure another way for users to be identified as admins. You can configure this admin-override feature using the following environment variables:
Environment variable | Description | Type | Default |
---|---|---|---|
| Enables the admin-override feature. | String |
|
|
Where to look for admin-override information. Only | String |
|
|
The type of information used to determine if a user is an admin. Values depend on the value of the FROM variable, for example, | String |
|
| The name of the role that indicates a user is an admin. | String |
|
| The name of a JWT token claim to use for determining admin-override. | String |
|
| The value that the JWT token claim indicated by the CLAIM variable must be for the user to be granted admin-override. | String |
|
For example, you can use this admin-override feature to assign the sr-admin
role to a single user in Red Hat Single Sign-On, which grants that user the admin role. That user can then use the /admin/roleMappings
REST API (or associated UI) to grant roles to additional users (including additional admins).
Service Registry owner-only authorization
You can set the following options to true
to enable owner-only authorization for updates to artifacts or artifact groups in Service Registry:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
|
| Boolean |
|
When owner-only authorization is enabled, only the user who created an artifact can modify or delete that artifact.
When owner-only authorization and group owner-only authorization are both enabled, only the user who created an artifact group has write access to that artifact group, for example, to add or remove artifacts in that group.
Service Registry authenticated read access
When the authenticated read access option is enabled, Service Registry grants at least read-only access to requests from any authenticated user in the same organization, regardless of their user role.
To enable authenticated read access, you must first enable role-based authorization, and then set the following option to true
:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
For more details, see the section called “Service Registry role-based authorization”.
Service Registry anonymous read-only access
In addition to the two main types of authorization (role-based and owner-based authorization), Service Registry supports an anonymous read-only access option.
To allow anonymous users, such as REST API calls with no authentication credentials, to make read-only calls to the REST API, set the following option to true
:
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
5.4. Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster Copy linkLink copied to clipboard!
The following procedure shows how to configure Service Registry deployment to expose a port for HTTPS connections from inside the OpenShift cluster.
This kind of connection is not directly available outside of the cluster. Routing is based on hostname, which is encoded in the case of an HTTPS connection. Therefore, edge termination or other configuration is still needed. See Section 5.5, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”.
Prerequisites
- You must have already installed the Service Registry Operator.
Procedure
Generate a
keystore
with a self-signed certificate. You can skip this step if you are using your own certificates.openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout tls.key -out tls.crt
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout tls.key -out tls.crt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new secret to hold the certificate and the private key.
- In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
-
Use the following values:
Name:https-cert-secret
Key 1:tls.key
Value 1: tls.key (uploaded file)
Key 2:tls.crt
Value 2: tls.crt (uploaded file)
or create the secret using the following command:
oc create secret generic https-cert-secret --from-file=tls.key --from-file=tls.crt
oc create secret generic https-cert-secret --from-file=tls.key --from-file=tls.crt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
spec.configuration.security.https
section of theApicurioRegistry
CR for your Service Registry deployment, for example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the connection is working:
Connect into a pod on the cluster using SSH (you can use the Service Registry pod):
oc rsh example-apicurioregistry-deployment-6f788db977-2wzpw
oc rsh example-apicurioregistry-deployment-6f788db977-2wzpw
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Find the cluster IP of the Service Registry pod from the Service resource (see the Location column in the web console). Afterwards, execute a test request (we are using self-signed certificate, so an insecure flag is required):
curl -k https://172.30.230.78:8443/health
curl -k https://172.30.230.78:8443/health
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
In the Kubernetes secret containing the HTTPS certificate and key, the names tls.crt
and tls.key
must be used for the provided values. This is currently not configurable.
Disabling HTTP
If you enabled HTTPS using the procedure in this section, you can also disable the default HTTP connection by setting the spec.security.https.disableHttp
to true
. This removes the HTTP port 8080 from the Service Registry pod container, Service
, and the NetworkPolicy
(if present).
Importantly, Ingress
is also removed because the Service Registry Operator currently does not support configuring HTTPS in Ingress
. Users must create an Ingress
for HTTPS connections manually.
Additional resources
5.5. Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster Copy linkLink copied to clipboard!
The following procedure shows how to configure Service Registry deployment to expose an HTTPS edge-terminated route for connections from outside the OpenShift cluster.
Prerequisites
- You must have already installed the Service Registry Operator.
- Read the OpenShift documentation for creating secured routes.
Procedure
Add a second Route in addition to the HTTP route created by the Service Registry Operator. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteMake sure the
insecureEdgeTerminationPolicy: Redirect
configuration property is set.If you do not specify a certificate, OpenShift will use a default. Alternatively, you can generate a custom self-signed certificate using the following commands:
openssl genrsa 2048 > tls.key && openssl req -new -x509 -nodes -sha256 -days 365 -key tls.key -out tls.crt
openssl genrsa 2048 > tls.key && openssl req -new -x509 -nodes -sha256 -days 365 -key tls.key -out tls.crt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Then create a route using the OpenShift CLI:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 6. Configuring and managing Service Registry deployments Copy linkLink copied to clipboard!
This chapter explains how to configure and manage optional settings for your Service Registry deployment on OpenShift:
- Section 6.1, “Configuring Service Registry health checks on OpenShift”
- Section 6.2, “Environment variables for Service Registry health checks”
- Section 6.3, “Managing Service Registry environment variables”
- Section 6.4, “Configuring Service Registry deployment using PodTemplate”
- Section 6.5, “Configuring the Service Registry web console”
- Section 6.6, “Configuring Service Registry logging”
- Section 6.7, “Configuring Service Registry event sourcing”
6.1. Configuring Service Registry health checks on OpenShift Copy linkLink copied to clipboard!
You can configure optional environment variables for liveness and readiness probes to monitor the health of the Service Registry server on OpenShift:
- Liveness probes test if the application can make progress. If the application cannot make progress, OpenShift automatically restarts the failing Pod.
- Readiness probes test if the application is ready to process requests. If the application is not ready, it can become overwhelmed by requests, and OpenShift stops sending requests for the time that the probe fails. If other Pods are OK, they continue to receive requests.
The default values of the liveness and readiness environment variables are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead.
Prerequisites
- You must have an OpenShift cluster with cluster administrator access.
- You must have already installed Service Registry on OpenShift.
- You must have already installed and configured your chosen Service Registry storage in AMQ Streams or PostgreSQL.
Procedure
- In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges.
- Click Installed Operators > Red Hat Integration - Service Registry Operator.
- On the ApicurioRegistry tab, click the Operator custom resource for your deployment, for example, example-apicurioregistry.
-
In the main overview page, find the Deployment Name section and the corresponding
DeploymentConfig
name for your Service Registry deployment, for example, example-apicurioregistry. -
In the left navigation menu, click Workloads > Deployment Configs, and select your
DeploymentConfig
name. Click the Environment tab, and enter your environment variables in the Single values env section, for example:
-
NAME:
LIVENESS_STATUS_RESET
-
VALUE:
350
-
NAME:
Click Save at the bottom.
Alternatively, you can perform these steps using the OpenShift
oc
command. For more details, see the OpenShift CLI documentation.
6.2. Environment variables for Service Registry health checks Copy linkLink copied to clipboard!
This section describes the available environment variables for Service Registry health checks on OpenShift. These include liveness and readiness probes to monitor the health of the Service Registry server on OpenShift. For an example procedure, see Section 6.1, “Configuring Service Registry health checks on OpenShift”.
The following environment variables are provided for reference only. The default values are designed for most cases and should only be changed if required by your environment. Any changes to the defaults depend on your hardware, network, and amount of data stored. These values should be kept as low as possible to avoid unnecessary overhead.
Liveness environment variables
Name | Description | Type | Default |
---|---|---|---|
| Number of liveness issues or errors that can occur before the liveness probe fails. | Integer |
|
| Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute | Seconds |
|
| Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. | Seconds |
|
| Comma-separated list of ignored liveness exceptions. | String |
|
Because OpenShift automatically restarts a Pod that fails a liveness check, the liveness settings, unlike readiness settings, do not directly affect behavior of Service Registry on OpenShift.
Readiness environment variables
Name | Description | Type | Default |
---|---|---|---|
| Number of readiness issues or errors that can occur before the readiness probe fails. | Integer |
|
| Period in which the threshold number of errors must occur. For example, if this value is 60 and the threshold is 1, the check fails after two errors occur in 1 minute. | Seconds |
|
| Number of seconds that must elapse without any more errors for the liveness probe to reset to OK status. In this case, this means how long the Pod stays not ready, until it returns to normal operation. | Seconds |
|
| Readiness tracks the timeout of two operations:
If these operations take more time than the configured timeout, this is counted as a readiness issue or error. This value controls the timeouts for both operations. | Seconds |
|
6.3. Managing Service Registry environment variables Copy linkLink copied to clipboard!
Service Registry Operator manages most common Service Registry configuration, but there are some options that it does not support yet. If a high-level configuration option is not available in the ApicurioRegistry
CR, you can use an environment variable to adjust it. You can update these by setting an environment variable directly in the ApicurioRegistry
CR, in the spec.configuration.env
field. These are then forwarded to the Deployment
resource of Service Registry.
Procedure
You can manage Service Registry environment variables by using the OpenShift web console or CLI.
- OpenShift web console
- Select the Installed Operators tab, and then Red Hat Integration - Service Registry Operator.
-
On the Apicurio Registry tab, click the
ApicurioRegistry
CR for your Service Registry deployment. Click the YAML tab and then edit the
spec.configuration.env
section as needed. The following example shows how to set default global content rules:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- OpenShift CLI
- Select the project where Service Registry is installed.
-
Run
oc get apicurioregistry
to get the list ofApicurioRegistry
CRs -
Run
oc edit apicurioregistry
on the CR representing the Service Registry instance that you want to configure. Add or modify the environment variable in the
spec.configuration.env
section.The Service Registry Operator might attempt to set an environment variable that is already explicitly specified in the
spec.configuration.env
field. If an environment variable configuration has a conflicting value, the value set by Service Registry Operator takes precedence.You can avoid this conflict by either using the high-level configuration for the feature, or only using the explicitly specified environment variables. The following is an example of a conflicting configuration:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This configuration results in the Service Registry web console being in read-only mode.
6.4. Configuring Service Registry deployment using PodTemplate Copy linkLink copied to clipboard!
This is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production.
These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview.
The ApicurioRegistry
CRD contains the spec.deployment.podTemplateSpecPreview
field, which has the same structure as the field spec.template
in a Kubernetes Deployment
resource (the PodTemplateSpec
struct).
With some restrictions, the Service Registry Operator forwards the data from this field to the corresponding field in the Service Registry deployment. This provides greater configuration flexibility, without the need for the Service Registry Operator to natively support each use case.
The following table contains a list of subfields that are not accepted by the Service Registry Operator, and result in a configuration error:
podTemplateSpecPreview subfield | Status | Details |
---|---|---|
| alternative exists |
|
| alternative exists |
|
| alternative exists |
|
| warning |
To configure the Service Registry container, |
| alternative exists |
|
| reserved | - |
| alternative exists |
|
| alternative exists |
|
If you set a field in podTemplateSpecPreview
, its value must be valid, as if you configured it in the Service Registry Deployment
directly. The Service Registry Operator might still modify the values you provided, but it will not fix an invalid value or make sure a default value is present.
Additional resources
6.5. Configuring the Service Registry web console Copy linkLink copied to clipboard!
You can set optional environment variables to configure the Service Registry web console specifically for your deployment environment or to customize its behavior.
Prerequisites
- You have already installed Service Registry.
Configuring the web console deployment environment
When you access the Service Registry web console in your browser, some initial configuration settings are loaded. The following configuration settings are important:
- URL for core Service Registry server REST API
- URL for Service Registry web console client
Typically, Service Registry automatically detects and generates these settings, but there are some deployment environments where this automatic detection can fail. If this happens, you can configure environment variables to explicitly set these URLs for your environment.
Procedure
Configure the following environment variables to override the default URLs:
-
REGISTRY_UI_CONFIG_APIURL
: Specifies the URL for the core Service Registry server REST API. For example,https://registry.my-domain.com/apis/registry
-
REGISTRY_UI_CONFIG_UIURL
: Specifies the URL for the Service Registry web console client. For example,https://registry.my-domain.com/ui
Configuring the web console in read-only mode
You can configure the Service Registry web console in read-only mode as an optional feature. This mode disables all features in the Service Registry web console that allow users to make changes to registered artifacts. For example, this includes the following:
- Creating an artifact
- Uploading a new artifact version
- Updating artifact metadata
- Deleting an artifact
Procedure
Configure the following environment variable:
-
REGISTRY_UI_FEATURES_READONLY
: Set totrue
to enable read-only mode. Defaults tofalse
.
6.6. Configuring Service Registry logging Copy linkLink copied to clipboard!
You can set Service Registry logging configuration at runtime. Service Registry provides a REST endpoint to set the log level for specific loggers for finer grained logging. This section explains how to view and set Service Registry log levels at runtime using the Service Registry /admin
REST API.
Prerequisites
-
Get the URL to access your Service Registry instance, or get your Service Registry route if you have Service Registry deployed on OpenShift. This simple example uses a URL of
localhost:8080
.
Procedure
Use this
curl
command to obtain the current log level for the loggerio.apicurio.registry.storage
:curl -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
$ curl -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"INFO"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use this
curl
command to change the log level for the loggerio.apicurio.registry.storage
toDEBUG
:curl -X PUT -i -H "Content-Type: application/json" --data '{"level":"DEBUG"}' localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
$ curl -X PUT -i -H "Content-Type: application/json" --data '{"level":"DEBUG"}' localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"DEBUG"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use this
curl
command to revert the log level for the loggerio.apicurio.registry.storage
to its default value:curl -X DELETE -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage
$ curl -X DELETE -i localhost:8080/apis/registry/v2/admin/loggers/io.apicurio.registry.storage HTTP/1.1 200 OK [...] Content-Type: application/json {"name":"io.apicurio.registry.storage","level":"INFO"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.7. Configuring Service Registry event sourcing Copy linkLink copied to clipboard!
You can configure Service Registry to send events when changes are made to the registry. For example, Service Registry can trigger events when schema and API artifacts are created, updated, deleted, and so on. You can configure Service Registry to send events to your applications and to third-party integrations in this way.
There are different protocols available for transporting the events. The currently implemented protocols are HTTP and Apache Kafka. However, regardless of the protocol, the events are sent using the CNCF CloudEvents specification.
All of the event types are defined in io.apicurio.registry.events.dto.RegistryEventType
. For example, the event types include:
-
io.apicurio.registry.artifact-created
-
io.apicurio.registry.artifact-updated
-
io.apicurio.registry.artifact-rule-created
-
io.apicurio.registry.global-rule-created
You can configure cloud events in Service Registry using Java system properties or equivalent environment variables.
Prerequisites
- You must have an application that you want to send Service Registry cloud events to. For example, this can be a custom application or a third-party application.
Configuring Service Registry event sourcing using HTTP
The example in this section shows a custom application running at http://my-app-host:8888/events
.
Procedure
When using the HTTP protocol, set your Service Registry configuration to send events to a your application as follows:
-
registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
-
If required, you can configure multiple event consumers as follows:
-
registry.events.sink.my-custom-consumer=http://my-app-host:8888/events
-
registry.events.sink.other-consumer=http://my-consumer.com/events
-
Configuring Service Registry event sourcing using Apache Kafka
The example in this section shows a Kafka topic named my-registry-events
running on my-kafka-host:9092
.
Procedure
When using the Kafka protocol, set your Kafka topic as follows:
-
registry.events.kafka.topic=my-registry-events
-
You can set the configuration for the Kafka producer using the
KAFKA_BOOTSTRAP_SERVERS
environment variable:KAFKA_BOOTSTRAP_SERVERS=my-kafka-host:9092
Alternatively, you can set the properties for the kafka producer using the
registry.events.kafka.config
prefix, for example:registry.events.kafka.config.bootstrap.servers=my-kafka-host:9092
If required, you can also set the Kafka topic partition to use to produce events:
-
registry.events.kafka.topic-partition=1
-
Chapter 7. Service Registry Operator configuration reference Copy linkLink copied to clipboard!
This chapter provides detailed information on the custom resource used to configure the Service Registry Operator to deploy Service Registry:
7.1. Service Registry Custom Resource Copy linkLink copied to clipboard!
The Service Registry Operator defines an ApicurioRegistry
custom resource (CR) that represents a single deployment of Service Registry on OpenShift.
These resource objects are created and maintained by users to instruct the Service Registry Operator how to deploy and configure Service Registry.
Example ApicurioRegistry CR
The following command displays the ApicurioRegistry
resource:
oc get apicurioregistry oc edit apicurioregistry example-apicurioregistry
oc get apicurioregistry
oc edit apicurioregistry example-apicurioregistry
By default, the Service Registry Operator watches its own project namespace only. Therefore, you must create the ApicurioRegistry
CR in the same namespace, if you are deploying the Operator manually. You can modify this behavior by updating WATCH_NAMESPACE
environment variable in the Operator Deployment
resource.
Additional resources
7.2. Service Registry CR spec Copy linkLink copied to clipboard!
The spec
is the part of the ApicurioRegistry
CR that is used to provide the desired state or configuration for the Operator to achieve.
ApicurioRegistry CR spec contents
The following example block contains the full tree of possible spec
configuration options. Some fields might not be required or should not be defined at the same time.
The following table describes each configuration option:
Configuration option | type | Default value | Description |
---|---|---|---|
| - | - | Section for configuration of Service Registry application |
| string | required |
Storage backend. One of |
| - | - | SQL storage backend configuration |
| - | - | Database connection configuration for SQL storage backend |
| string | required | Database connection URL string |
| string | required | Database connection user |
| string | empty | Database connection password |
| - | - | Kafka storage backend configuration |
| string | required | Kafka bootstrap server URL, for Streams storage backend |
| - | - | Section to configure TLS authentication for Kafka storage backend |
| string | required | Name of a secret containing TLS truststore for Kafka |
| string | required | Name of a secret containing user TLS keystore |
| string | required | Name of a secret containing TLS truststore for Kafka |
| string | required | SCRAM user name |
| string | required | Name of a secret containing SCRAM user password |
| string |
| SASL mechanism |
| - | - | Service Registry web console settings |
| string |
| Set Service Registry web console to read-only mode |
| string |
|
Service Registry log level, for non-Apicurio components and libraries. One of |
| string |
|
Service Registry log level, for Apicurio application components (excludes non-Apicurio components and libraries). One of |
| - | - | Service Registry web console and REST API security settings |
| - | - | Web console and REST API security configuration using Red Hat Single Sign-On |
| string | required | Red Hat Single Sign-On URL |
| string | required | Red Hat Single Sign-On realm |
| string |
| Red Hat Single Sign-On client for REST API |
| string |
| Red Hat Single Sign-On client for web console |
| - | - | Configuration for HTTPS. For more details, see Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster. |
| string | empty |
Name of a Kubernetes Secret that contains the HTTPS certificate and key, which must be named |
| bool |
| Disable HTTP port and Ingress. HTTPS must be enabled as a prerequisite. |
| k8s.io/api/core/v1 []EnvVar | empty | Configure a list of environment variables to be provided to the Service Registry pod. For more details, see Managing Service Registry environment variables. |
| - | - | Section for Service Registry deployment settings |
| positive integer |
| Number of Service Registry pods to deploy |
| string | auto-generated | Host/URL where the Service Registry console and API are available. If possible, Service Registry Operator attempts to determine the correct value based on the settings of your cluster router. The value is auto-generated only once, so user can override it afterwards. |
| k8s.io/api/core/v1 Affinity | empty | Service Registry deployment affinity configuration |
| k8s.io/api/core/v1 []Toleration | empty | Service Registry deployment tolerations configuration |
| k8s.io/api/core/v1 []LocalObjectReference | empty | Configure image pull secrets for Service Registry deployment |
| - | - | Configure a set of labels or annotations for the Service Registry pod. |
| map[string]string | empty | Configure a set of labels for Service Registry pod |
| map[string]string | empty | Configure a set of annotations for Service Registry pod |
| - | - | Section to configure how the Service Registry Operator manages Kubernetes resources. For more details, see Service Registry managed resources. |
| bool |
|
If set, the operator will not create and manage an |
| bool |
|
If set, the operator will not create and manage a |
| bool |
|
If set, the operator will not create and manage an |
| k8s.io/api/core/v1 PodTemplateSpec | empty | Configure parts of the Service Registry deployment resource. For more details, see Configuring Service Registry deployment using PodTemplate. |
If an option is marked as required, it might be conditional on other configuration options being enabled. Empty values might be accepted, but the Operator does not perform the specified action.
7.3. Service Registry CR status Copy linkLink copied to clipboard!
The status
is the section of the CR managed by the Service Registry Operator that contains a description of the current deployment and application state.
ApicurioRegistry CR status contents
The status
section contains the following fields:
Status field | Type | Description |
---|---|---|
| - | Section with information about the deployed Service Registry. |
| string | URL where the Service Registry UI and REST API are accessible. |
| - | List of conditions that report the status of the Service Registry, or the Operator with respect to that deployment. |
| string | Type of the condition. |
| string |
Status of the condition, one of |
| string | A programmatic identifier indicating the reason for the condition’s last transition. |
| string | A human-readable message indicating details about the transition. |
| string | The last time the condition transitioned from one status to another. |
| - | List of OpenShift resources managed by Service Registry Operator |
| string | Resource kind. |
| string | Resource namespace. |
| string | Resource name. |
7.4. Service Registry managed resources Copy linkLink copied to clipboard!
The resources managed by the Service Registry Operator when deploying Service Registry are as follows:
-
Deployment
-
Ingress
(andRoute
) -
NetworkPolicy
-
PodDisruptionBudget
-
Service
You can disable the Service Registry Operator from creating and managing some resources, so they can be configured manually. This provides greater flexibility when using features that the Service Registry Operator does not currently support.
If you disable a resource type, its existing instance is deleted. If you enable a resource, the Service Registry Operator attempts to find a resource using the app
label, for example, app=example-apicurioregistry
, and starts managing it. Otherwise, the Operator creates a new instance.
You can disable the following resource types in this way:
-
Ingress
(andRoute
) -
NetworkPolicy
-
PodDisruptionBudget
For example:
7.5. Service Registry Operator labels Copy linkLink copied to clipboard!
Resources managed by the Service Registry Operator are usually labeled as follows:
Label | Description |
---|---|
|
Name of the Service Registry deployment that the resource belongs to, based on the name of the specified |
|
Type of the deployment: |
|
Name of the deployment: same value as |
| Version of the Service Registry or the Service Registry Operator |
| A set of recommended Kubernetes labels for application deployments. |
| Metering labels for Red Hat products. |
Custom labels and annotations
You can provide custom labels and annotation for the Service Registry pod, using the spec.deployment.metadata.labels
and spec.deployment.metadata.annotations
fields, for example:
Additional resources
Chapter 8. Service Registry configuration reference Copy linkLink copied to clipboard!
This chapter provides reference information on the configuration options that are available for Service Registry.
Additional resources
-
For details on setting configuration options by using the Core Registry API, see the
/admin/config/properties
endpoint in the Apicurio Registry REST API documentation. - For details on client configuration options for Kafka serializers and deserializers, see the Service Registry User Guide.
8.1. Service Registry configuration options Copy linkLink copied to clipboard!
The following Service Registry configuration options are available for each component category:
8.1.1. api Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Include stack trace in errors responses |
|
|
| Disable APIs |
8.1.2. auth Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Auth admin override claim |
|
|
|
| Auth admin override claim value |
|
|
|
| Auth admin override enabled |
|
|
|
| Auth admin override from |
|
|
|
| Auth admin override role |
|
|
|
| Auth admin override type |
|
|
|
| Anonymous read access |
|
|
|
| Prefix used for application audit logging. |
|
|
|
| Authenticated read access |
|
|
|
| Client credentials token expiration time. |
|
|
|
| Enable basic auth client credentials |
|
|
| Client identifier used by the server for authentication. | |
|
|
| Client secret used by the server for authentication. | |
|
|
|
| Enable auth |
|
|
|
| Artifact owner-only authorization |
|
|
|
| Artifact group owner-only authorization |
|
|
|
| Enable role based authorization |
|
|
|
| Auth roles source |
|
|
| Header authorization name | |
|
|
|
| Auth roles admin |
|
|
|
| Auth roles developer |
|
|
|
| Auth roles readonly |
|
|
|
| Auth tenant owner admin enabled |
|
|
| Authentication server url. |
8.1.3. cache Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Registry cache enabled |
8.1.4. ccompat Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Legacy ID mode (compatibility API) |
|
|
|
| Maximum number of Subjects returned (compatibility API) |
|
|
|
| Canonical hash mode (compatibility API) |
8.1.5. download Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Download link expiry |
8.1.6. events Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| Events Kafka sink enabled |
8.1.7. health Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| Ignored liveness errors | |
|
|
|
| Counter reset window duration of persistence liveness check |
|
|
|
| Disable logging of persistence liveness check |
|
|
|
| Error threshold of persistence liveness check |
|
|
|
| Status reset window duration of persistence liveness check |
|
|
|
| Counter reset window duration of persistence readiness check |
|
|
|
| Error threshold of persistence readiness check |
|
|
|
| Status reset window duration of persistence readiness check |
|
|
|
| Timeout of persistence readiness check |
|
|
|
| Counter reset window duration of response liveness check |
|
|
|
| Disable logging of response liveness check |
|
|
|
| Error threshold of response liveness check |
|
|
|
| Status reset window duration of response liveness check |
|
|
|
| Counter reset window duration of response readiness check |
|
|
|
| Error threshold of response readiness check |
|
|
|
| Status reset window duration of response readiness check |
|
|
|
| Timeout of response readiness check |
|
|
|
| Storage metrics cache check period |
8.1.8. import Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| The import URL |
8.1.9. kafka Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| Events Kafka topic | |
|
|
| Events Kafka topic partition |
8.1.10. limits Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Max artifact labels |
|
|
|
| Max artifact properties |
|
|
|
| Max artifacts |
|
|
|
| Max artifact description length |
|
|
|
| Max artifact label size |
|
|
|
| Max artifact name length |
|
|
|
| Max artifact property key size |
|
|
|
| Max artifact property value size |
|
|
|
| Max artifact requests per second |
|
|
|
| Max schema size (bytes) |
|
|
|
| Max total schemas |
|
|
|
| Max versions per artifacts |
|
|
|
| Storage metrics cache max size. |
8.1.11. log Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| Log level |
8.1.12. redirects Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
| Enable redirects | |
|
|
| Registry redirects |
8.1.13. rest Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Enables artifact version deletion |
|
|
|
| Max size of the artifact allowed to be downloaded from URL |
|
|
|
| Skip SSL validation when downloading artifacts from URL |
8.1.14. store Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| Skip artifact versions with DISABLED state when retrieving latest artifact version |
|
|
|
| Datasource Db kind |
|
|
| Datasource jdbc URL | |
|
|
|
| SQL init |
8.1.15. ui Copy linkLink copied to clipboard!
Name | Type | Default | Available from | Description |
---|---|---|---|---|
|
|
|
| UI OIDC tenant enabled |
|
|
| UI APIs URL | |
|
|
|
| UI auth OIDC client ID |
|
|
|
| UI auth OIDC redirect URL |
|
|
|
| UI auth OIDC URL |
|
|
|
| UI auth type |
|
|
|
| UI codegen enabled |
|
|
|
| UI context path |
|
|
|
| UI read-only mode |
|
|
|
| UI features settings |
|
|
| Overrides the UI root context (useful when relocating the UI context using an inbound proxy) |
Appendix A. Using your subscription Copy linkLink copied to clipboard!
Service Registry is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.
Accessing your account
- Go to access.redhat.com.
- If you do not already have an account, create one.
- Log in to your account.
Activating a subscription
- Go to access.redhat.com.
- Navigate to My Subscriptions.
- Navigate to Activate a subscription and enter your 16-digit activation number.
Downloading ZIP and TAR files
To access ZIP or TAR files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required.
- Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
- Locate the Red Hat Integration entries in the Integration and Automation category.
- Select the desired Service Registry product. The Software Downloads page opens.
- Click the Download link for your component.
Revised on 2023-08-09 11:41:56 UTC