- Service configuration structure
- Built-in configuration profiles
The EPL 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
EPL 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
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
Alternatively, the application-specific configuration can be sourced from Kaa Tekton.
See the Tekton configuration section to find out how to configure such integration.
EPL can update metadata keys in the endpoint register on receiving EP connectivity events. The metadata keys to update are controlled with appversion-specific configuration below. If the key is not defined for an appversion, EPL does not update it in the register.
kaa: applications: <application 1 name>: versions: <application 1 version 1 name>: connectivity: metadata-keys: state: <string> # EP metadata key to update with the current EP connectivity state (true for connected / false for disconnected state) state-ts: <string> # EP metadata key to update with the last EP connectivity transition timestamp time-series: name: <string> # Connectivity state time series name that EPL will produce.
kaa: applications: smart_kettle: versions: kettle_v1: # Connectivity state keys are not managed for "kettle_v1" application version kettle_v2: # "kettle_v2" defines EP metadata keys for connectivity state and last transition timestamps connectivity: metadata-keys: state: connected # "connected" tag will be set to true when EP is connected and false otherwise state-ts: connectivity_ts # "connectivity_ts" tag will contain the last transition timestamp time-series: name: ep-online # 'ep-online' time series will be published on EP connect/disconnect kettle_v3: # "kettle_v3" explicitly specifies no connectivity metadata fields connectivity: metadata-keys: null
EPL 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 EPL uses to update endpoint connectivity state to endpoint metadata.
kaa: epl: ep-register: service-instance: name: <service instance name> # Instance name of endpoint register service
Communication service interface
kaa: epl: communication-service: service-instance: name: <service instance name> # Instance name of the communication service
The below parameters configure EPL’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
EPL 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
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”).
EPL 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.
Built-in configuration profiles
For your convenience, EPL comes with a default built-in configuration profile.
Built-in profile is optimized for a Kubernetes-based production deployment. It does not define any Kaa applications—you have to configure those for any specific Kaa-based solution.
server: port: 80 kaa: epl: communication-service: service-instance: name: kpc 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