Chapter 5. Securing Apicurio Registry deployments Apicurio Registry provides authentication and authorization by using Red Hat Single Sign-On based on OpenID Connect (OIDC) and 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 Apicurio Registry. Apicurio Registry also provides authentcation and authorization by using Microsoft Azure Active Directory based on OpenID Connect (OIDC) and the OAuth Authorization Code Flow. You can configure the required settings manually in Azure AD and Apicurio Registry. In addition to role-based authorization options with Red Hat Single Sign-On or Azure AD, Apicurio 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 Apicurio Registry from inside or outside an OpenShift cluster. This chapter explains how to configure the following security options for your Apicurio Registry deployment on OpenShift: Section 5.1, "Securing Apicurio Registry using the Red Hat Single Sign-On Operator" Section 5.2, "Configuring Apicurio Registry authentication and authorization with Red Hat Single Sign-On" Section 5.3, "Configuring Apicurio Registry authentication and authorization with Microsoft Azure Active Directory" Section 5.4, "Apicurio Registry authentication and authorization configuration options" Section 5.5, "Configuring an HTTPS connection to Apicurio Registry from inside the OpenShift cluster" Section 5.6, "Configuring an HTTPS connection to Apicurio Registry from outside the OpenShift cluster" Additional resources For details on security configuration for Java client applications, see the following: Apicurio Registry Java client configuration Apicurio Registry serializer/deserializer configuration 5.1. Securing Apicurio Registry using the Red Hat Single Sign-On Operator The following procedure shows how to configure a Apicurio Registry REST API and web console to be protected by Red Hat Single Sign-On. Apicurio Registry supports the following user roles: Table 5.1. Apicurio Registry user roles Name Capabilities sr-admin Full access, no restrictions. sr-developer Create artifacts and configure artifact rules. Cannot modify global rules, perform import/export, or use /admin REST API endpoint. sr-readonly View and search only. Cannot modify artifacts or rules, perform import/export, or use /admin REST API endpoint. Note 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 Apicurio Registry Operator. You must install the Red Hat Single Sign-On Operator or have Red Hat Single Sign-On accessible from your OpenShift cluster. Important 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 Apicurio 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 URL value for later use when deploying Apicurio 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 labels: app: sso 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 Important You 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 and Ingress 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:: Modify the host value to create a route accessible for the Apicurio Registry user, and use it instead of the HTTPS route created by Red Hat Single Sign-On Operator. Click the Apicurio 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>" # ^ Required # 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.<my-namespace>.svc:9092' 5.2. Configuring Apicurio Registry authentication and authorization with Red Hat Single Sign-On This section explains how to manually configure authentication and authorization options for Apicurio Registry and Red Hat Single Sign-On. Note Alternatively, for details on how to configure these settings automatically, see Section 5.1, "Securing Apicurio Registry using the Red Hat Single Sign-On Operator" . The Apicurio Registry web console and core REST API support authentication in Red Hat Single Sign-On based on OAuth and OpenID Connect (OIDC). The same Red Hat Single Sign-On realm and users are federated across the Apicurio Registry web console and core REST API using OpenID Connect so that you only require one set of credentials. Apicurio Registry provides role-based authorization for default admin, write, and read-only user roles. Apicurio Registry provides content-based authorization at the schema or API level, where only the creator of the registry artifact can update or delete it. Apicurio 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 . Apicurio Registry is installed and running. Procedure In the Red Hat Single Sign-On Admin Console, create a Red Hat Single Sign-On realm for Apicurio Registry. By default, Apicurio Registry expects a realm name of registry . For details on creating realms, see the the Red Hat Single Sign-On user documentation . Create a Red Hat Single Sign-On client for the Apicurio Registry API. By default, Apicurio 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. Note If you are using Red Hat Single Sign-On service accounts, the client Access Type must be confidential instead of bearer-only . Create a Red Hat Single Sign-On client for the Apicurio Registry web console. By default, Apicurio 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. In your Apicurio Registry deployment on OpenShift, set the following Apicurio Registry environment variables to configure authentication using Red Hat Single Sign-On: Table 5.2. Configuration for Apicurio Registry authentication with Red Hat Single Sign-On Environment variable Description Type Default AUTH_ENABLED Enables authentication for Apicurio Registry. When set to true , the environment variables that follow are required for authentication using Red Hat Single Sign-On. String false KEYCLOAK_URL The URL of the Red Hat Single Sign-On authentication server. For example, http://localhost:8080 . String - KEYCLOAK_REALM The Red Hat Single Sign-On realm for authentication. For example, registry. String - KEYCLOAK_API_CLIENT_ID The client ID for the Apicurio Registry REST API. String registry-api KEYCLOAK_UI_CLIENT_ID The client ID for the Apicurio Registry web console. String apicurio-registry Tip For an example of setting environment variables on OpenShift, see Section 6.1, "Configuring Apicurio Registry health checks on OpenShift" . Set the following option to true to enable Apicurio Registry user roles in Red Hat Single Sign-On: Table 5.3. Configuration for Apicurio Registry role-based authorization Environment variable Java system property Type Default value ROLE_BASED_AUTHZ_ENABLED registry.auth.role-based-authorization Boolean false When Apicurio Registry user roles are enabled, you must assign Apicurio Registry users to at least one of the following default user roles in your Red Hat Single Sign-On realm: 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 Apicurio Registry: 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 Additional resources For details on configuring non-default user role names, see Section 5.4, "Apicurio Registry authentication and authorization configuration options" . For an open source example application and Keycloak realm, see Docker Compose example of Apicurio Registry with Keycloak . For details on how to use Red Hat Single Sign-On in a production environment, see the Red Hat Single Sign-On documentation . 5.3. Configuring Apicurio Registry authentication and authorization with Microsoft Azure Active Directory This section explains how to manually configure authentication and authorization options for Apicurio Registry and Microsoft Azure Active Directory (Azure AD). The Apicurio Registry web console and core REST API support authentication in Azure AD based on OpenID Connect (OIDC) and the OAuth Authorization Code Flow. Apicurio Registry provides role-based authorization for default admin, write, and read-only user roles. Apicurio Registry authentication and authorization settings are disabled by default. To secure Apicurio Registry with Azure AD, you require a valid directory in Azure AD with specific configuration. This involves registering the Apicurio Registry application in the Azure AD portal with recommended settings and configuring environment variables in Apicurio Registry. Prerequisites Azure AD is installed and running. For more details, see the Microsoft Azure AD user documentation . Apicurio Registry is installed and running. Procedure Log in to the Azure AD portal using your email address or GitHub account. In the navigation menu, select Manage > App registrations > New registration , and complete the following settings: Name : Enter your application name. For example: apicurio-registry-example Supported account types : Click Accounts in any organizational directory . Redirect URI : Select application from the list, and enter your Apicurio Registry web console application host. For example: https://test-registry.com/ui/ Important You must register your Apicurio Registry application host as a Redirect URI . When logging in, users are redirected from Apicurio Registry to Azure AD for authentication, and you want to send them back to your application afterwards. Azure AD does not allow any redirect URLs that are not registered. Click Register . You can view your app registration details by selecting Manage > App registrations > apicurio-registry-example . Select Manage > Authentication and ensure that the application is configured with your redirect URLs and tokens as follows: Redirect URIs : For example: https://test-registry.com/ui/ Implicit grant and hybrid flows : Click ID tokens (used for implicit and hybrid flows) Select Azure AD > Admin > App registrations > Your app > Application (client) ID . For example: 123456a7-b8c9-012d-e3f4-5fg67h8i901 Select Azure AD > Admin > App registrations > Your app > Directory (tenant) ID . For example: https://login.microsoftonline.com/1a2bc34d-567e-89f1-g0hi-1j2kl3m4no56/v2.0 In Apicurio Registry, configure the following environment variables with your Azure AD settings: Table 5.6. Configuration for Azure AD settings in Apicurio Registry Environment variable Description Setting KEYCLOAK_API_CLIENT_ID The client application ID for the Apicurio Registry REST API Your Azure AD Application (client) ID obtained in step 5. For example: 123456a7-b8c9-012d-e3f4-5fg67h8i901 REGISTRY_OIDC_UI_CLIENT_ID The client application ID for the Apicurio Registry web console. Your Azure AD Application (client) ID obtained in step 5. For example: 123456a7-b8c9-012d-e3f4-5fg67h8i901 REGISTRY_AUTH_URL_CONFIGURED The URL for authentication in Azure AD. Your Azure AD Application (tenant) ID obtained in step 6. For example: https://login.microsoftonline.com/1a2bc34d-567e-89f1-g0hi-1j2kl3m4no56/v2.0 . In Apicurio Registry, configure the following environment variables for Apicurio Registry-specific settings: Table 5.7. Configuration for Apicurio Registry-specific settings Environment variable Description Setting REGISTRY_AUTH_ENABLED Enables authentication for Apicurio Registry. true REGISTRY_UI_AUTH_TYPE The Apicurio Registry authentication type. oidc CORS_ALLOWED_ORIGINS The host for your Apicurio Registry deployment for cross-origin resource sharing (CORS). For example: https://test-registry.com REGISTRY_OIDC_UI_REDIRECT_URL The host for your Apicurio Registry web console. For example: https://test-registry.com/ui ROLE_BASED_AUTHZ_ENABLED Enables role-based authorization in Apicurio Registry. true QUARKUS_OIDC_ROLES_ROLE_CLAIM_PATH The name of the claim in which Azure AD stores roles. roles Note When you enable roles in Apicurio Registry, you must also create the same roles in Azure AD as application roles. The default roles expected by Apicurio Registry are sr-admin , sr-developer , and sr-readonly . Additional resources For details on configuring non-default user role names, see Section 5.4, "Apicurio Registry authentication and authorization configuration options" . For more details on using Azure AD, see the Microsoft Azure AD user documentation . 5.4. Apicurio Registry authentication and authorization configuration options Apicurio Registry provides authentication options for OpenID Connect with Red Hat Single Sign-On and HTTP basic authentication. Apicurio 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. Important All authentication and authorization options in Apicurio Registry are disabled by default. Before enabling any of these options, you must first set the AUTH_ENABLED option to true . This chapter provides details on the following configuration options: Apicurio Registry authentication by using OpenID Connect with Red Hat Single Sign-On Apicurio Registry authentication by using HTTP basic Apicurio Registry role-based authorization Apicurio Registry owner-only authorization Apicurio Registry authenticated read access Apicurio Registry anonymous read-only access Apicurio Registry authentication by using OpenID Connect with Red Hat Single Sign-On You can set the following environment variables to configure authentication for the Apicurio Registry web console and API with Red Hat Single Sign-On: Table 5.8. Configuration for Apicurio Registry authentication with Red Hat Single Sign-On Environment variable Description Type Default AUTH_ENABLED Enables authentication for Apicurio Registry. When set to true , the environment variables that follow are required for authentication using Red Hat Single Sign-On. String false KEYCLOAK_URL The URL of the Red Hat Single Sign-On authentication server. For example, http://localhost:8080 . String - KEYCLOAK_REALM The Red Hat Single Sign-On realm for authentication. For example, registry. String - KEYCLOAK_API_CLIENT_ID The client ID for the Apicurio Registry REST API. String registry-api KEYCLOAK_UI_CLIENT_ID The client ID for the Apicurio Registry web console. String apicurio-registry Apicurio Registry authentication by using HTTP basic By default, Apicurio Registry supports authentication by using OpenID Connect. Users or API clients must obtain an access token to make authenticated calls to the Apicurio Registry REST API. However, because some tools do not support OpenID Connect, you can also configure Apicurio Registry to support HTTP basic authentication by setting the following configuration options to true : Table 5.9. Configuration for Apicurio Registry HTTP basic authentication Environment variable Java system property Type Default value AUTH_ENABLED registry.auth.enabled Boolean false CLIENT_CREDENTIALS_BASIC_AUTH_ENABLED registry.auth.basic-auth-client-credentials.enabled Boolean false Apicurio 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, Apicurio 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: Table 5.10. Configuration for HTTP basic client credentials cache expiry Environment variable Java system property Type Default value CLIENT_CREDENTIALS_BASIC_CACHE_EXPIRATION registry.auth.basic-auth-client-credentials.cache-expiration Integer 10 Apicurio Registry role-based authorization You can set the following options to true to enable role-based authorization in Apicurio Registry: Table 5.11. Configuration for Apicurio Registry role-based authorization Environment variable Java system property Type Default value AUTH_ENABLED registry.auth.enabled Boolean false ROLE_BASED_AUTHZ_ENABLED registry.auth.role-based-authorization Boolean false You can then configure role-based authorization to use roles included in the user's authentication token (for example, granted when authenticating by using Red Hat Single Sign-On), or to use role mappings managed internally by Apicurio 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: Table 5.12. Configuration for Apicurio Registry role-based authorization by using Red Hat Single Sign-On Environment variable Description Type Default ROLE_BASED_AUTHZ_SOURCE When set to token , user roles are taken from the authentication token. String token REGISTRY_AUTH_ROLES_ADMIN The name of the role that indicates a user is an admin. String sr-admin REGISTRY_AUTH_ROLES_DEVELOPER The name of the role that indicates a user is a developer. String sr-developer REGISTRY_AUTH_ROLES_READONLY The name of the role that indicates a user has read-only access. String sr-readonly When Apicurio Registry is configured to use roles from Red Hat Single Sign-On, you must assign Apicurio 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 by using the environment variables in Table 5.12, "Configuration for Apicurio Registry role-based authorization by using Red Hat Single Sign-On" . Table 5.13. Apicurio Registry roles for authentication and authorization Role name Read artifacts Write artifacts Global rules Description 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 and import/export. This role can configure artifact-specific rules only. sr-readonly Yes No No Access to read and search operations only. This role cannot configure any rules. Manage roles directly in Apicurio Registry To enable using roles managed internally by Apicurio Registry, set the following environment variable: Table 5.14. Configuration for Apicurio Registry role-based authorization by using internal role mappings Environment variable Description Type Default ROLE_BASED_AUTHZ_SOURCE When set to application , user roles are managed internally by Apicurio Registry. String token When using internally managed role mappings, users can be assigned a role by using the /admin/roleMappings endpoint in the Apicurio 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. Apicurio Registry admin-override configuration Because there are no default admin users in Apicurio Registry, it is usually helpful to configure another way for users to be identified as admins. You can configure this admin-override feature by using the following environment variables: Table 5.15. Configuration for Apicurio Registry admin-override Environment variable Description Type Default REGISTRY_AUTH_ADMIN_OVERRIDE_ENABLED Enables the admin-override feature. String false REGISTRY_AUTH_ADMIN_OVERRIDE_FROM Where to look for admin-override information. Only token is currently supported. String token REGISTRY_AUTH_ADMIN_OVERRIDE_TYPE The type of information used to determine if a user is an admin. Values depend on the value of the FROM variable, for example, role or claim when FROM is token . String role REGISTRY_AUTH_ADMIN_OVERRIDE_ROLE The name of the role that indicates a user is an admin. String sr-admin REGISTRY_AUTH_ADMIN_OVERRIDE_CLAIM The name of a JWT token claim to use for determining admin-override. String org-admin REGISTRY_AUTH_ADMIN_OVERRIDE_CLAIM_VALUE The value that the JWT token claim indicated by the CLAIM variable must be for the user to be granted admin-override. String true 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). Apicurio 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 Apicurio Registry: Table 5.16. Configuration for owner-only authorization Environment variable Java system property Type Default value AUTH_ENABLED registry.auth.enabled Boolean false REGISTRY_AUTH_OBAC_ENABLED registry.auth.owner-only-authorization Boolean false REGISTRY_AUTH_OBAC_LIMIT_GROUP_ACCESS registry.auth.owner-only-authorization.limit-group-access Boolean false 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. Apicurio Registry authenticated read access When the authenticated read access option is enabled, Apicurio 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 ensure that the following options are set to true : Table 5.17. Configuration for authenticated read access Environment variable Java system property Type Default value AUTH_ENABLED registry.auth.enabled Boolean false REGISTRY_AUTH_AUTHENTICATED_READS_ENABLED registry.auth.authenticated-read-access.enabled Boolean false For more details, see the section called "Apicurio Registry role-based authorization" . Apicurio Registry anonymous read-only access In addition to the two main types of authorization (role-based and owner-based authorization), Apicurio 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 options to true : Table 5.18. Configuration for anonymous read-only access Environment variable Java system property Type Default value AUTH_ENABLED registry.auth.enabled Boolean false REGISTRY_AUTH_ANONYMOUS_READ_ACCESS_ENABLED registry.auth.anonymous-read-access.enabled Boolean false Additional resources For an example of how to set environment variables in your Apicurio Registry deployment on OpenShift, see Section 6.3, "Managing Apicurio Registry environment variables" For details on configuring custom authentication for Apicurio Registry, the see Quarkus Open ID Connect documentation 5.5. Configuring an HTTPS connection to Apicurio Registry from inside the OpenShift cluster The following procedure shows how to configure Apicurio Registry deployment to expose a port for HTTPS connections from inside the OpenShift cluster. Warning 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.6, "Configuring an HTTPS connection to Apicurio Registry from outside the OpenShift cluster" . Prerequisites You must have already installed the Apicurio 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 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 Edit the spec.configuration.security.https section of the ApicurioRegistry CR for your Apicurio Registry deployment, for example: apiVersion: registry.apicur.io/v1 kind: ApicurioRegistry metadata: name: example-apicurioregistry spec: configuration: # ... security: https: secretName: https-cert-secret Verify that the connection is working: Connect into a pod on the cluster using SSH (you can use the Apicurio Registry pod): oc rsh example-apicurioregistry-deployment-6f788db977-2wzpw Find the cluster IP of the Apicurio 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 Note 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 Apicurio Registry pod container, Service , and the NetworkPolicy (if present). Importantly, Ingress is also removed because the Apicurio Registry Operator currently does not support configuring HTTPS in Ingress . Users must create an Ingress for HTTPS connections manually. Additional resources How to enable HTTPS and SSL termination in a Quarkus app 5.6. Configuring an HTTPS connection to Apicurio Registry from outside the OpenShift cluster The following procedure shows how to configure Apicurio Registry deployment to expose an HTTPS edge-terminated route for connections from outside the OpenShift cluster. Prerequisites You must have already installed the Apicurio Registry Operator. Read the OpenShift documentation for creating secured routes . Procedure Add a second Route in addition to the HTTP route created by the Apicurio Registry Operator. For 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 Note Make 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 Then create a route using the OpenShift CLI: oc create route edge \ --service=example-apicurioregistry-service-9whd7 \ --cert=tls.crt --key=tls.key \ --hostname=example-apicurioregistry-default.apps.example.com \ --insecure-policy=Redirect \ -n default

Commands:
apiVersion: keycloak.org/v1alpha1 kind: Keycloak metadata: name: example-keycloak labels: app: sso spec: instances: 1 externalAccess: enabled: True podDisruptionBudget: enabled: True
apiVersion: keycloak.org/v1alpha1 kind: KeycloakRealm metadata: name: registry-keycloakrealm labels: app: sso 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
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: {}
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: keycloak-http labels: app: keycloak spec: rules: - host: KEYCLOAK_HTTP_HOST http: paths: - path: / pathType: ImplementationSpecific backend: service: name: keycloak-http port: number: 8080
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>" # ^ Required # 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.<my-namespace>.svc:9092'
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout tls.key -out tls.crt
create secret generic https-cert-secret --from-file=tls.key --from-file=tls.crt
apiVersion: registry.apicur.io/v1 kind: ApicurioRegistry metadata: name: example-apicurioregistry spec: configuration: # security: https: secretName: https-cert-secret
rsh example-apicurioregistry-deployment-6f788db977-2wzpw
curl -k https://172.30.230.78:8443/health
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
openssl genrsa 2048 > tls.key && openssl req -new -x509 -nodes -sha256 -days 365 -key tls.key -out tls.crt
create route edge --service=example-apicurioregistry-service-9whd7 --cert=tls.crt --key=tls.key --hostname=example-apicurioregistry-default.apps.example.com --insecure-policy=Redirect -n default