此内容没有您所选择的语言版本。

Chapter 5. Securing a Service Registry deployment


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.

Additional resources

5.1. Securing Service Registry using the Red Hat Single Sign-On Operator

The following procedure shows how to configure a Service Registry REST API and web console to be protected by Red Hat Single Sign-On. The Red Hat Single Sign-On Operator is available as a Technology Preview feature.

Important

Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend implementing any Technology Preview features in production environments.

This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope.

Service Registry supports the following user roles:

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

  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: {}
    2. 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.

  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>/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.<my-namespace>.svc:9092'

5.2. Configuring Service Registry authentication and authorization with Red Hat Single Sign-On

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 more details on creating realms, see 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:

    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. Must end with /auth.

    String

    None

    KEYCLOAK_REALM

    The Red Hat Single Sign-On realm used for authentication.

    String

    registry

    KEYCLOAK_API_CLIENT_ID

    The client ID for the Service Registry REST API.

    String

    registry-api

    KEYCLOAK_UI_CLIENT_ID

    The client ID for the Service Registry web console.

    String

    apicurio-registry

    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:

    Table 5.3. Configuration for Service Registry user roles
    Environment variableJava system propertyTypeDefault value

    ROLES_ENABLED

    registry.auth.roles.enabled

    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:

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

    Table 5.5. Configuration for owner-only authorization
    Environment variableJava system propertyTypeDefault value

    REGISTRY_AUTH_OWNER_ONLY_AUTHORIZATION

    registry.auth.owner-only-authorization

    Boolean

    false

Additional resources

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.

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.4, “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.

    keytool -genkey -trustcacerts -keyalg RSA -keystore registry-keystore.jks -storepass password
  2. Create a new secret to hold the keystore and keystore password.

    1. In the left navigation menu of the OpenShift web console, click Workloads > Secrets > Create Key/Value Secret.
    2. Use the following values:
      Name: registry-keystore
      Key 1: keystore.jks
      Value 1: registry-keystore.jks (uploaded file)
      Key 2: password
      Value 2: password

      Note

      If 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 using cat registry-keystore.jks | base64 -w0 > data.txt and edit the Secret resource as yaml to manually add the encoded file.

  3. Edit the Deployment resource of the Service Registry instance. You can find the correct name in a status field of the Service Registry Operator.

    1. Add the keystore secret as a volume:

      template:
        spec:
          volumes:
          - name: registry-keystore-secret-volume
            secret:
            secretName: registry-keystore
    2. Add a volume mount:

      volumeMounts:
        - name: registry-keystore-secret-volume
          mountPath: /etc/registry-keystore
          readOnly: true
    3. Add JAVA_OPTIONS and KEYSTORE_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)
      Note

      Order is important when using string interpolation.

    4. Enable the HTTPS port:

      ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8443
          protocol: TCP
  4. 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
  5. 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 -n default example-apicurioregistry-deployment-vx28s-4-lmtqb
    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.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

Procedure

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

    Make 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
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.