Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 5. Securing Service Registry deployments


This chapter explains how to configure security settings for your Service Registry deployment on OpenShift:

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.

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:

Expand
Table 5.1. Service Registry user roles
NameCapabilities

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 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.
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

  1. In the OpenShift web console, click Installed Operators and Red Hat Single Sign-On Operator, and then the Keycloak tab.
  2. 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
    Copy to Clipboard Toggle word wrap
  3. Wait until the instance has been created, and click Networking and then Routes to access the new route for the keycloak instance.
  4. Click the Location URL and copy the displayed URL value for later use when deploying Service Registry.
  5. 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: registry
    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
    Copy to Clipboard Toggle word wrap
    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.

  6. 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:

    1. 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: {}
      Copy to Clipboard Toggle word wrap
    2. Click Networking and then Ingresses, and click Create Ingress using the following example::

      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
      Copy to Clipboard Toggle word wrap

      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.

  7. 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>"
            # ^ 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'
    Copy to Clipboard Toggle word wrap

This section explains how to manually configure authentication and authorization options for Service Registry using Red Hat Single Sign-On.

Note

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

Procedure

  1. 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 details on creating realms, see the the Red Hat Single Sign-On user documentation.
  2. 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.

      Note

      If you are using Red Hat Single Sign-On service accounts, the client Access Type must be confidential instead of bearer-only.

  3. 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.

  4. 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 variableDescriptionTypeDefault

    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.

    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

    Tip

    For an example of setting environment variables on OpenShift, see Section 6.1, “Configuring Service Registry health checks on OpenShift”.

  5. 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 variableJava system propertyTypeDefault value

    ROLE_BASED_AUTHZ_ENABLED

    registry.auth.role-based-authorization

    Boolean

    false

  6. 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
    RoleRead artifactsWrite artifactsGlobal rulesSummary

    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.

  7. 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 variableJava system propertyTypeDefault value

    REGISTRY_AUTH_OBAC_ENABLED

    registry.auth.owner-only-authorization

    Boolean

    false

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.
Important

All authentication and authorization options in Service 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:

Service Registry authentication by 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:

Expand
Table 5.6. Configuration for Service Registry authentication with Red Hat Single Sign-On
Environment variableDescriptionTypeDefault

AUTH_ENABLED

Enables authentication in Service Registry. When set to true, the environment variables that follow are required for authentication in 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 Service Registry REST API.

String

registry-api

KEYCLOAK_UI_CLIENT_ID

The client ID for the Service Registry web console.

String

apicurio-registry

Service Registry authentication by using HTTP basic

By default, Service Registry supports authentication by 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 options to true:

Expand
Table 5.7. Configuration for Service Registry HTTP basic authentication
Environment variableJava system propertyTypeDefault value

AUTH_ENABLED

registry.auth.enabled

Boolean

false

CLIENT_CREDENTIALS_BASIC_AUTH_ENABLED

registry.auth.basic-auth-client-credentials.enabled

Boolean

false

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:

Expand
Table 5.8. Configuration for HTTP basic client credentials cache expiry
Environment variableJava system propertyTypeDefault value

CLIENT_CREDENTIALS_BASIC_CACHE_EXPIRATION

registry.auth.basic-auth-client-credentials.cache-expiration

Integer

10

Service Registry role-based authorization

You can set the following options to true to enable role-based authorization in Service Registry:

Expand
Table 5.9. Configuration for Service Registry role-based authorization
Environment variableJava system propertyTypeDefault 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 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:

Expand
Table 5.10. Configuration for Service Registry role-based authorization by using Red Hat Single Sign-On
Environment variableDescriptionTypeDefault

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 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 by using the environment variables in Table 5.10, “Configuration for Service Registry role-based authorization by using Red Hat Single Sign-On”.

Expand
Table 5.11. Service Registry roles for authentication and authorization
Role nameRead artifactsWrite artifactsGlobal rulesDescription

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 Service Registry

To enable using roles managed internally by Service Registry, set the following environment variable:

Expand
Table 5.12. Configuration for Service Registry role-based authorization by using internal role mappings
Environment variableDescriptionTypeDefault

ROLE_BASED_AUTHZ_SOURCE

When set to application, user roles are managed internally by Service Registry.

String

token

When using internally managed role mappings, users can be assigned a role by 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 by using the following environment variables:

Expand
Table 5.13. Configuration for Service Registry admin-override
Environment variableDescriptionTypeDefault

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).

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:

Expand
Table 5.14. Configuration for owner-only authorization
Environment variableJava system propertyTypeDefault 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.

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 ensure that the following options are set to true:

Expand
Table 5.15. Configuration for authenticated read access
Environment variableJava system propertyTypeDefault 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 “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 options to true:

Expand
Table 5.16. Configuration for anonymous read-only access
Environment variableJava system propertyTypeDefault value

AUTH_ENABLED

registry.auth.enabled

Boolean

false

REGISTRY_AUTH_ANONYMOUS_READ_ACCESS_ENABLED

registry.auth.anonymous-read-access.enabled

Boolean

false

The following procedure shows how to configure Service 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.5, “Configuring an HTTPS connection to Service Registry from outside the OpenShift cluster”.

Prerequisites

  • You must have already installed the Service Registry Operator.

Procedure

  1. 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
    Copy to Clipboard Toggle word wrap
  2. Create a new secret to hold the certificate and the private key.

    1. In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
    2. 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
    Copy to Clipboard Toggle word wrap
  3. Edit the spec.configuration.security.https section of the ApicurioRegistry CR for your Service Registry deployment, for example:

    apiVersion: registry.apicur.io/v1
    kind: ApicurioRegistry
    metadata:
      name: example-apicurioregistry
    spec:
      configuration:
        # ...
        security:
          https:
            secretName: https-cert-secret
    Copy to Clipboard Toggle word wrap
  4. Verify that the connection is working:

    1. Connect into a pod on the cluster using SSH (you can use the Service Registry pod):

      oc rsh example-apicurioregistry-deployment-6f788db977-2wzpw
      Copy to Clipboard Toggle word wrap
    2. 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
      Copy to Clipboard Toggle word wrap
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 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.

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

Procedure

  1. Add a second Route in addition to the HTTP route created by the Service 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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat