Runtime Service Configuration

About Runtime Service Configuration

The PlainID PDP (Runtime service) has a large configuration file that enables fine-tuning and control over various service parameters. While service parameter default values typically suffice, certain scenarios may require adjustments to optimize the PDP's behavior for your organization's specific needs.

Although you can directly edit the JSON configuration file in a Standalone PAA deployment or inject a full configuration map in a Kubernetes (K8s) PAA deployment, maintaining updated keys is simpler using Environment Variables. The Runtime service supports a naming convention for ENV_VARs that allows you to adjust any configuration key as needed in the Runtime extraEnv section in the values.yaml. Ensure that you add the values you want to adjust in the values-custom.yaml.

Environment Variables following the naming convention outlined below automatically load and override the default values of configuration keys.

Environment Variables Convention

Environment Variable Prefix

All Runtime configuration keys begin with the predefined prefix RTCONF_

Hierarchy Naming Syntax

After the prefix, the Environment Variable name reflects the hierarchical structure of the configuration file, using a double underscore (__) as a separator between hierarchy levels.
This same double underscore (__) is also used to denote array indices for configuration keys that are defined as arrays.

Note: A single underscore(_) is used as a word separator within the ENV_VAR name.

Examples

The following table demonstrates the naming convention and hierarchical structure for ENV_VARs.

Note: Ensure that the serviceMgmtPort is set to 80 (default)

Logging

Loading Environment Variables and overriding configuration keys are logged in the Runtime service logs to facilitate troubleshooting.
Any configuration key replaced by a value defined with an Environment Variable according to this hierarchical structure is logged at the Info level with message in this structure: config.json key <key-name> was overridden by <env-var-name> environment variable.
Additional logging may also be present in cases of error handling and validation of the Environment Variables naming syntax.

List of Runtime Configuration Keys

The table below highlights common Runtime service configuration keys that are relevant for fine-tuning. For additional guidance on configuration, consult the PlainID Professional Services team.

Enabling SSL for PDP

To enforce SSL for the PDP Runtime service, an SSL certificate is required as a prerequisite, along with updated service configurations. The steps below outline the process when working with the default Kubernetes deployment pattern using PlainID Helm files.

Note: If your deployment pattern is different, consult your administrator and adjust the steps accordingly. For additional assistance, contact PlainID Professional Services.

SSL Certificate Setup

1. Prepare your private key and server certificate, and store them as a Kubernetes secret. This can be done as part of the Helm chart using extraManifests (see example below).
2. Configure Environment Variables for accessing your Java Keystore: KEY_STORE_PATH and PASSWORD.

runtime:
  extraEnv: 
    RTCONF_SSL__KEYSTORE_PATH: "/usr/lib/jvm/default-jvm/lib/security/cacerts" 
  extraEnvSecrets: 
    RTCONF_SSL__KEYSTORE_PASSWORD: "changeit"

3. Mount the certificates from the secret created above:

runtime: 
  extraVolumes: 
    - name: runtime-ssl-certificate 
      secret: 
        secretName: runtime-ssl-certificate 
  extraVolumeMounts: 
    - mountPath: "/app/ssl" 
      name: runtime-ssl-certificate 
      readOnly: true

4. Modify the Runtime service pod command to import the certificate into the Java keystore before starting the application:

runtime: 
  command: 
    - /bin/sh 
    - -ec 
    - | 
       openssl pkcs12 -export -out /tmp/placceholder.p12 -inkey /app/ssl/server.key -in /app/ssl/server.crt -password pass:${RTCONF_SSL__KEYSTORE_PASSWORD} keytool -importkeystore -deststorepass ${RTCONF_SSL__KEYSTORE_PASSWORD} -destkeystore ${RTCONF_SSL__KEYSTORE_PATH} -srckeystore /tmp/placceholder.p12 -srcstoretype PKCS12 -srcstorepass ${RTCONF_SSL__KEYSTORE_PASSWORD} java ${JVM_OPTS} --add-exports java.base/sun.security.util=ALL-UNNAMED -Dconf.file=${RUNTIME_CONFIG_PATH} -Dconf.format=json -Dlog4j.configurationFile=${RUNTIME_LOG4J_PATH} -Djava.net.preferIPv4Stack=true -jar theruntime.jar

In the example above, we assume that server.crt and server.key are injected from the secret.

Configure SSL for the PDP

Enable SSL in the Runtime service configuration:

runtime: 
  ssl: 
    enabled: true

Health Check and SSL

Even when SSL is enabled, health checks performed by Kubernetes will not attempt to validate the SSL certificate, even when using the HTTPS scheme. Refer to the Kubernetes documentation for more information.

Note: If you are accessing the Runtime health check endpoint externally, your client must either include SSL validation keys or be configured to ignore validation gracefully.

Port Definition and Separation

The SSL configuration applies to all service ports. However, if needed, you can separate the Application service port from the Health status port using the following optional configuration:

• Configure a custom port for the health check API endpoint (optional):

runtime: 
  extraEnv: 
    RUNTIME_STATUS_PORT: "3000"

You may also override the default application port with the following optional configuration:

runtime: 
  service: 
    port: 443

Note: If you configure a custom port and override the default setup, you must restart the service pods.

Full Configuration Example

Full configuration example that includes all the required changes:

runtime: 
  service: 
    port: 443 
  ssl: 
    enabled: true 
  extraEnv: 
    RTCONF_SSL__KEYSTORE_PATH: "/usr/lib/jvm/default-jvm/lib/security/cacerts"
  extraEnvSecrets: 
    RTCONF_SSL__KEYSTORE_PASSWORD: "changeit" 
  command: - /bin/sh - -ec - | openssl pkcs12 -export -out /tmp/placceholder.p12 -inkey /app/ssl/server.key -in /app/ssl/server.crt -password pass:${RTCONF_SSL__KEYSTORE_PASSWORD} keytool -importkeystore -deststorepass ${RTCONF_SSL__KEYSTORE_PASSWORD} -destkeystore ${RTCONF_SSL__KEYSTORE_PATH} -srckeystore /tmp/placceholder.p12 -srcstoretype PKCS12 -srcstorepass ${RTCONF_SSL__KEYSTORE_PASSWORD} java ${JVM_OPTS} --add-exports java.base/sun.security.util=ALL-UNNAMED -Dconf.file=${RUNTIME_CONFIG_PATH} -Dconf.format=json -Dlog4j.configurationFile=${RUNTIME_LOG4J_PATH} -Djava.net.preferIPv4Stack=true -jar theruntime.jar 
  
  extraVolumes: 
    - name: runtime-ssl-certificate 
      secret: 
        secretName: runtime-ssl-certificate 
  
  extraVolumeMounts: 
    - mountPath: "/app/ssl" 
      name: runtime-ssl-certificate 
      readOnly: true 
  
  extraManifests: 
    - apiVersion: v1 
      kind: Secret 
      metadata: 
        name: runtime-ssl-certificate 
        namespace: manual-test 
      type: Opaque 
      stringData: 
        server.key: | 
          -----BEGIN PRIVATE KEY----- 
          ...
          -----END PRIVATE KEY----- 
        server.crt: | 
          -----BEGIN CERTIFICATE----- 
          ...
          -----END CERTIFICATE-----

Optimizing PDP Redis Utilization

The PDP (Runtime Service) uses Redis as a cache storage for managing the Identity Cache, Scope Authorization Requests, and Response Cache. Redis also stores deployed metadata such as Policies, Templates, Scopes, and other data required for Authorization calculations. To reduce connection load, network traffic, and data fetch overhead, the Runtime service retrieves metadata from Redis and maintains it in its own internal service cache.

You can configure specific Environment Variables to fine-tune the Runtime Service Cache behavior by controlling the dependency on Redis during Authorization Requests:

PDP Logging

The PlainID PDP includes built-in logging to support observability, diagnostics, and performance monitoring. Logging captures key events such as Environment Variable overrides, configuration loading, request durations, and system behavior during policy evaluations. These logs help administrators validate configuration changes, trace issues, and optimize Runtime performance.
The logs also include Runtime entries for each Authorization requests like:

• Initiation of the request
• Request ID and context details
• Step-by-step calculation flow (logged at lower log levels)
• Completion of the request, including the total duration