Chapter 5. Securing a Service Registry deployment
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
../authURL 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
registryexample realm:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantYou must customize this
KeycloakRealmresource 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
ServiceandIngressresources 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
hostvalue 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
keycloaksection.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-onlyYou 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
confidentialinstead 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_ENABLEDIf set to
true, the environment variables that follow are required.String
falseKEYCLOAK_URLThe URL of the Red Hat Single Sign-On authentication server to use. Must end with
/auth.String
None
KEYCLOAK_REALMThe Red Hat Single Sign-On realm used for authentication.
String
registryKEYCLOAK_API_CLIENT_IDThe client ID for the Service Registry REST API.
String
registry-apiKEYCLOAK_UI_CLIENT_IDThe client ID for the Service Registry web console.
String
apicurio-registryTipFor an example of setting environment variables on OpenShift, see Section 6.1, “Configuring Service Registry health checks on OpenShift”.
Set the following option to
trueto 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_ENABLEDregistry.auth.role-based-authorizationBoolean
falseWhen 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-adminYes
Yes
Yes
Full access to all create, read, update, and delete operations.
sr-developerYes
Yes
No
Access to create, read, update, and delete operations, except configuring global rules. This role can configure artifact rules.
sr-readonlyYes
No
No
Access to read and search operations only. This role cannot configure any rules.
Set the following to
trueto 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_ENABLEDregistry.auth.owner-only-authorizationBoolean
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 using Red Hat Single Sign-On:
| Environment variable | Description | Type | Default |
|---|---|---|---|
|
|
Enables or disables authentication in Service Registry. When set to | String |
|
|
|
The URL of the Red Hat Single Sign-On authentication server to use. Must end with | String | - |
|
| The Red Hat Single Sign-On realm used for authentication. | 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 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.9, “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 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
keystorewith a self-signed certificate. You can skip this step if you are using your own certificates.keytool -genkey -trustcacerts -keyalg RSA -keystore registry-keystore.jks -storepass password
keytool -genkey -trustcacerts -keyalg RSA -keystore registry-keystore.jks -storepass passwordCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new secret to hold the keystore and keystore password.
- In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
Use the following values:
Name:registry-keystore
Key 1:keystore.jks
Value 1: registry-keystore.jks (uploaded file)
Key 2:password
Value 2: passwordNoteIf you encounter a
java.io.IOException: Invalid keystore format, the upload of the binary file did not work properly. As an alternative, encode the file as a base64 string usingcat registry-keystore.jks | base64 -w0 > data.txtand edit the Secret resource as yaml to manually add the encoded file.
Edit the Deployment resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.
Add the keystore secret as a volume:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add a volume mount:
volumeMounts: - name: registry-keystore-secret-volume mountPath: /etc/registry-keystore readOnly: truevolumeMounts: - name: registry-keystore-secret-volume mountPath: /etc/registry-keystore readOnly: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add
JAVA_OPTIONSandKEYSTORE_PASSWORDenvironment variables:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteOrder is important when using string interpolation.
Enable the HTTPS port:
ports: - containerPort: 8080 protocol: TCP - containerPort: 8443 protocol: TCPports: - containerPort: 8080 protocol: TCP - containerPort: 8443 protocol: TCPCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Edit the Service resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.
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 -n default example-apicurioregistry-deployment-vx28s-4-lmtqb
oc rsh -n default example-apicurioregistry-deployment-vx28s-4-lmtqbCopy 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.209.198:8443/health [...]
curl -k https://172.30.209.198:8443/health [...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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. See the following example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteMake sure the
insecureEdgeTerminationPolicy: Redirectconfiguration property is set.If you do not specify a certificate, OpenShift will use a default. You can alternatively generate a custom self-signed certificate using the following commands:
openssl genrsa 2048 > host.key && openssl req -new -x509 -nodes -sha256 -days 365 -key host.key -out host.cert
openssl genrsa 2048 > host.key && openssl req -new -x509 -nodes -sha256 -days 365 -key host.key -out host.certCopy to Clipboard Copied! Toggle word wrap Toggle overflow and then create a route using the OpenShift CLI:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow