Configuration

The EPR loads configuration data from a file (typically backed by a Kubernetes config map). If the service is unable to retrieve the configuration data, it will not start. Refer to the configuration for details.

Service configuration structure

The recommended configuration format is YAML. The below sections describe the officially supported configuration options that influence various aspects of the service functionality. The service may support options other than the ones listed below, but those are not a part of the public API and may be changed or deleted at any time.

General service configuration

EPR uses a standard Spring Boot server.port property to configure the port to expose the REST API at.

server:
  port: <unsigned short integer>  # Server port used to expose the REST API at

Kaa applications

Many Kaa services can be configured for different behavior depending on the application version of the endpoint the processed data relates to. This is called application-specific behavior and is handled in service configurations under kaa.applications. Alternatively, the application-specific configuration can be sourced from Kaa Tekton. See the Tekton configuration section to find out how to configure such integration.

kaa:
  applications:
    <application 1 name>:
      versions:
        <application 1 version 1 name>:
        <application 1 version 2 name>:  # Multiple application versions can be configured under the "versions" key
          ...
    <application 2 name>:                # Multiple applications can be configured under the "applications" key
      ...

For example:

kaa:
  applications:
    smart_kettle:
      versions:
        kettle_v1:
        kettle_v2:
        kettle_v3:

Due to the various compatibility reasons the application and application version names must be limited to lowercase Latin letters (a-z), digits (0-9), dashes (-) and underscores (_).

Metadata inheritance

Endpoints can inherit other endpoints’ metadata depending on their established relationship. Currently, such inheritance is only possible for an endpoint that is contained by another endpoint. Taking the example from the real world use-case, if there are two endpoints - one represents the vehicle, another represents the GPS tracker, and the vehicle endpoint contains the GPS tracker endpoint then the GPS tracker can inherit the vehicle’s metadata.

The below configuration allows controlling if metadata inheritance is enabled and setting up metadata inheritance mapping.

kaa:
  applications:
    <application name>: # Application name of the endpoint that is contained. In the above use case, this is the GPS tracker's application name.
      relations:
        - appName: <application name> # Application name of the endpoint that contains. In the above use case, this is the vehicle's application name.
          metadata:
            inheritance:
              <related endpoint's metadata key>: <inheritance prefix>
              # <related endpoint's metadata key> - related endpoint's metadata key. '*' - means all metadata keys of the related endpoint are inherited.
              # <inheritance prefix> - the prefix that is appended to the metadata key defined in <related endpoint's metadata key>. Empty value or null means metadata key is inherited as is.

Continuing the use case with the vehicle and GPS tracker, if you want the GPS tracker to inherit all metadata from the vehicle that contains it, use the * sign as a <related endpoint's metadata key>.

kaa:
  applications:
    gps-tracker-app:
      relations:
        - appName: vehicle-app
          metadata:
            inheritance:
              '*': vehicle_

As a result, the GPS tracker will inherit its vehicle’s metadata prefixing each vehicle’s metadata key with the ‘vehicle_’ prefix.

If you want the GPS tracker to inherit only the vehicle’s VIN and manufacturer, you would have the next configuration.

kaa:
  applications:
    gps-tracker-app:
      relations:
        - appName: vehicle-app
          metadata:
            inheritance:
              vin: vehicle_
              manufacturer: vehicle_

Tekton

EPR supports integration with Kaa Tekton for centralized application configuration management. The below configuration options set up the integration interface.

kaa:
  tekton:
    enabled: <boolean>    # Enables Tekton integration. False by default. Also can be set with the KAA_TEKTON_ENABLED environment variable.
    url: <string>         # URL of the Tekton service. "http://tekton" by default. Also can be set with the KAA_TEKTON_URL environment variable.
  scmp.consumer:
    provider.service-instance.name: <string>  # Service instance name of the Tekton service. "tekton" by default. Also can be set with the KAA_SCMP_CONSUMER_PROVIDER_SERVICE_INSTANCE_NAME environment variable. 

Data persistence interface

EPR uses Spring Data MongoDB configuration. Refer to the corresponding documentation for the list of supported configuration options.

NOTE For security reasons, username and password must be sourced from the environment variables.

NATS

The below parameters configure EPR’s connection to NATS.

NOTE For security, reasons NATS username and password are sourced from the environment variables.

nats:
  urls: <comma separated list of URL>                  # NATS connection URLs
  request-timeout: <unsigned integer>                  # How long to wait for a response message (in msec). Default is 10000.
  concurrency:
    max-threads: <unsigned integer>                    # The maximum number of threads to read and process incoming messages. Default is 50.
    core-pool-size: <unsigned integer>                 # The number of threads to keep in the pool, even if they are idle. Default is 3.
    keep-alive-time-millis: <unsigned integer>         # When the number of threads is greater than the core, this is the maximum time that excess idle threads will wait for new tasks before terminating. Default is 10000.

Communication service interface

kaa:
  epr:
    communication-service:
      service-instance:
        name: <service instance name>  # Instance name of the communication service

Authentication, authorization, and multi-tenancy

EPR supports two integrations for security:

  • OAuth2 protocol with a UMA profile. Enabled when kaa.security.enabled is true and kaa.security.iamcore.enabled is false.
  • iamcore. Enabled when both kaa.security.enabled and kaa.security.iamcore.enabled are true.

OAuth2 with UMA profile

Authentication and authorization is handled within the scope of a given Kaa tenant. Each tenant has a separate OAuth 2.0 issuer, managed by the Kaa Tenant Manager. When multi-tenancy is disabled, all authentication and authorization is conducted in the default system tenant (“kaa”).

EPR OAuth2 with UMA profile security is controlled with the following configuration options (for security reasons it is advised to set these via environment variables).

kaa:
  security:
    enabled: <boolean>      # Enables authentication and authorization. False by default.
    issuer:
      public-url: <string>  # OAuth 2.0 issuer public URL for the system tenant ("kaa").
      private-url: <string> # OAuth 2.0 issuer private URL for the system tenant ("kaa").
    client-id: <string>     # Client ID for making requests in the system tenant scope.
    client-secret: <string> # Client secret for making requests in the system tenant scope.
    multitenancy:
      enabled: <boolean>    # Enables multitenancy via integration with the Kaa Tenant Manager. Only effective when kaa.security.enabled is set to true. False by default.
      tenant-manager:
        url: <string>       # URL of the Kaa Tenant Manager that provides security configurations for tenants. "http://tenant-manager" by default.

iamcore

Authentication and authorization is handled by iamcore.

EPR iamcore security is controlled with the following configuration options (for security reasons it is advised to set these via environment variables).

kaa:
  security:
    enabled: <boolean>      # Enables authentication and authorization. False by default.
    iamcore:
      enabled: <boolean>    # Enables iamcore integration. False by default.
      api-key: <string>     # iamcore API KEY
      url: <string>         # iamcore server URL. "https://cloud.iamcore.io" by default.
      application: <string> # iamcore application. "kaa" by default
      accountId: <string> # iamcore account.

Authorization disabling

It is possible to disable authorization on EPR’s REST API endpoints. In such a case only authentication will be applied.

The below parameter disables authorization.

kaa:
  security:  
    authz:
      disabled: <boolean>  # Disables authorization.

NOTE Authorization disabling may significantly improve EPR’s REST API response time depending on the particular REST API endpoint since it disables the permission evaluation on the resource server.

Management

EPR monitoring and management implementation is based on the Spring Boot Actuator. Refer to the corresponding documentation for the list of supported configuration options.

Logging

By default, EPR uses Spring Boot logging configuration with logback for logging. Refer to the corresponding documentation for the list of supported configuration options.

Built-in configuration profiles

For your convenience, EPR comes with a default built-in configuration profile.

Built-in profiles are optimized for a Kubernetes-based production deployment. They do not define any Kaa applications—you have to configure them for a specific Kaa-based solution.

Default

server:
  port: 80
  compression:
    enabled: true
    mime-types: application/json

nats:
  urls: nats://nats:4222
  request-timeout: 10000
  concurrency:
    max-threads: 50
    core-pool-size: 3
    keep-alive-time-millis: 10000

kaa:
  epr:
    cm:
      base-url: http://cm
    communication-service:
      service-instance:
        name: kpc

spring.data.mongodb:
  database: epr
  uri: mongodb://mongodb:27017/epr
  threads-allowed-to-block-for-connection-multiplier: 5
  connections-per-host: 100
  max-wait-time: 120000
  connection-timeout: 5000
  socket-timeout: 0

management:
  server:
    port: 8080
  endpoint:
    health:
      enabled: true
      show-details: always
      status:
        http-mapping:
          UNKNOWN: SERVICE_UNAVAILABLE
    shutdown:
      enabled: true
    metrics:
      enabled: false
    prometheus:
      enabled: false
  metrics:
    export:
      prometheus:
        enabled: false
  endpoints:
    web:
      base-path: /
      exposure:
        include: info,health,metrics