Configuration

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

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 appversion-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>:
          # List of metadata keys that are allowed for endpoint to read. Optional. When not specified, all metadata keys
          # are allowed for both reading and writing.
          metadata-keys:
            <metadata-key-name-1>:      # Name of the metadata key
              write-enabled: <boolean>  # Indicates whether writing is allowed for endpoint. Defaults to true.
            <metadata-key-name-2>:
            ...

For example:

kaa:
  applications:
    smart_kettle:
      versions:
        kettle_v1:                  # "kettle_v1" application version is configured with no key filtering
        kettle_v2:                  # "kettle_v2" allows only "location" and "owner" metadata fields
          metadata-keys:
            location:               # "location" field is write-enabled
            owner:
              write-enabled: false  # "owner" field is read-only
        kettle_v3:                  # "kettle_v3" explicitly specifies no filtering
          metadata-keys: null

Tekton

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

Endpoint register interface

Use the below parameters to configure the NATS-based endpoint register interface EPMX uses to retrieve and manage endpoint metadata.

kaa:
  epmx:
    ep-register:
      service-instance:
        name: <service instance name>  # Instance name of endpoint register service

NATS

The below parameters configure EPMX’s connection to NATS. Note that for security reasons NATS username and password are sourced from the environment variables.

nats:
  urls: <comma separated list of URL>  # NATS connection URLs

Management

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

Authentication, authorization, and multi-tenancy

EPMX’s REST API security is implemented according to OAuth2 protocol with a 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][Tenant Manager]. When multi-tenancy is disabled, all authentication and authorization is conducted in the default system tenant (“kaa”).

EPMX 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: <string>         # OAuth 2.0 issuer 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.

Logging

By default, EPMX 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, EPMX 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

kaa:
  epmx:
    ep-register:
      service-instance:
        name: epr

nats:
  urls: nats://nats:4222

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