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 the Service Registry API and web console using Red Hat Single Sign-On”
- Section 5.2, “Service Registry authentication and authorization configuration options”
- Section 5.3, “Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster”
- Section 5.4, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”
Service Registry supports authentication for the Service Registry web console and core REST API using Red Hat Single Sign-On, based on Open ID Connect (OIDC). You can enable this by installing the Red Hat Single Sign-On Operator, or using Service Registry configuration options.
Service Registry provides role-based authentication and authorization in 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.
Additional resources
For details on security configuration for Java client applications, see the following:
5.1. Securing the Service Registry API and web console using Red Hat Single Sign-On
The following procedure shows how to configure a Service Registry deployment to be protected by Red Hat Single Sign-On.
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.
Service Registry supports the following user roles:
Table 5.1. Service Registry 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.
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:
apiVersion: keycloak.org/v1alpha1 kind: Keycloak metadata: name: example-keycloak labels: app: sso spec: instances: 1 externalAccess: enabled: True podDisruptionBudget: enabled: True
- 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
../auth
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:apiVersion: keycloak.org/v1alpha1 kind: KeycloakRealm metadata: name: registry-keycloakrealm spec: instanceSelector: matchLabels: app: sso realm: displayName: Registry enabled: true id: registry realm: registry sslRequired: none roles: realm: - name: sr-admin - name: sr-developer - name: sr-readonly clients: - clientId: registry-client-ui implicitFlowEnabled: true redirectUris: - '*' standardFlowEnabled: true webOrigins: - '*' publicClient: true - clientId: registry-client-api implicitFlowEnabled: true redirectUris: - '*' standardFlowEnabled: true webOrigins: - '*' publicClient: true users: - credentials: - temporary: false type: password value: changeme enabled: true realmRoles: - sr-admin username: registry-admin - credentials: - temporary: false type: password value: changeme enabled: true realmRoles: - sr-developer username: registry-developer - credentials: - temporary: false type: password value: changeme enabled: true realmRoles: - sr-readonly username: registry-user
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:
apiVersion: v1 kind: Service metadata: name: keycloak-http labels: app: keycloak spec: ports: - name: keycloak-http protocol: TCP port: 8080 targetPort: 8080 selector: app: keycloak component: keycloak type: ClusterIP sessionAffinity: None status: loadBalancer: {}
Click Networking and then Ingresses, and click Create Ingress using the following example::
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: keycloak-http labels: app: keycloak spec: rules: - host: keycloak-http.local http: paths: - path: / pathType: ImplementationSpecific backend: serviceName: keycloak-http servicePort: 8080
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.apiVersion: registry.apicur.io/v1 kind: ApicurioRegistry metadata: name: example-apicurioregistry-kafkasql-keycloak spec: configuration: security: keycloak: url: "http://keycloak-http-<namespace>.apps.<cluster host>/auth" # ^ Required # Keycloak server URL, must end with `/auth`. # Use an HTTP URL in development. realm: "registry" # apiClientId: "registry-client-api" # ^ Optional (default value) # uiClientId: "registry-client-ui" # ^ Optional (default value) persistence: 'kafkasql' kafkasql: bootstrapServers: '<my-cluster>-kafka-bootstrap.<namespace>.svc:9092'
5.2. Service Registry authentication and authorization configuration options
This section describes the authentication and authorization options for Service Registry using Red Hat Single Sign-On.
You can enable authentication for the Service Registry web console and core REST API using Red Hat Single Sign-On. The same Red Hat Single Sign-On realm and users are federated across the Service Registry web console and core REST API using Open ID Connect (OIDC) 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 options are disabled by default.
Prerequisites
- Red Hat Single Sign-On is installed and running, and configured with a Red Hat Single Sign-On realm and a user. For more details, see Getting Started with Red Hat Single Sign-On.
- Service Registry is installed and running.
Service Registry authentication using 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:
Table 5.2. Configuration for Service Registry authentication options
Environment variable | Description | Type | Default |
---|---|---|---|
|
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 user roles in Red Hat Single Sign-On
When Service Registry authentication is enabled, you must assign Service Registry users to at least one of the following user roles in Red Hat Single Sign-On:
Table 5.3. Service Registry roles for authentication and authorization
Role | 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. |
Service Registry artifact owner-only authorization option
Set the following option to true
to enable owner-only authorization for updates to schema and API artifacts in Service Registry:
Table 5.4. Configuration for owner-only authorization
Environment variable | Java system property | Type | Default value |
---|---|---|---|
|
| Boolean |
|
Additional resources
- For an open source Docker-based example of authentication using Red Hat Single Sign-On, see https://github.com/Apicurio/apicurio-registry/tree/master/distro/docker-compose
- For details on how to use Red Hat Single Sign-On in a production environment, see see Red Hat Single Sign-On documentation
- For details on configuring custom authentication for Service Registry, the see Quarkus Open ID Connect documentation
5.3. Configuring an HTTPS connection to Service Registry from inside the OpenShift cluster
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.4, “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.keytool -genkey -trustcacerts -keyalg RSA -keystore registry-keystore.jks -storepass password
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.txt
and 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:
template: spec: volumes: - name: registry-keystore-secret-volume secret: secretName: registry-keystore
Add a volume mount:
volumeMounts: - name: registry-keystore-secret-volume mountPath: /etc/registry-keystore readOnly: true
Add
JAVA_OPTIONS
andKEYSTORE_PASSWORD
environment variables:- name: KEYSTORE_PASSWORD valueFrom: secretKeyRef: name: registry-keystore key: password - name: JAVA_OPTIONS value: >- -Dquarkus.http.ssl.certificate.key-store-file=/etc/registry-keystore/keystore.jks -Dquarkus.http.ssl.certificate.key-store-file-type=jks -Dquarkus.http.ssl.certificate.key-store-password=$(KEYSTORE_PASSWORD)
NoteOrder is important when using string interpolation.
Enable the HTTPS port:
ports: - containerPort: 8080 protocol: TCP - containerPort: 8443 protocol: TCP
Edit the Service resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.
ports: - name: http protocol: TCP port: 8080 targetPort: 8080 - name: https protocol: TCP port: 8443 targetPort: 8443
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
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 [...]
5.4. Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster
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:
kind: Route apiVersion: route.openshift.io/v1 metadata: [...] labels: app: example-apicurioregistry [...] spec: host: example-apicurioregistry-default.apps.example.com to: kind: Service name: example-apicurioregistry-service-9whd7 weight: 100 port: targetPort: 8080 tls: termination: edge insecureEdgeTerminationPolicy: Redirect wildcardPolicy: None
NoteMake sure the
insecureEdgeTerminationPolicy: Redirect
configuration 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
and then create a route using the OpenShift CLI:
oc create route edge \ --service=example-apicurioregistry-service-9whd7 \ --cert=host.cert --key=host.key \ --hostname=example-apicurioregistry-default.apps.example.com \ --insecure-policy=Redirect \ -n default