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 Naming 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 Runtime

This configuration is meant for Kubernetes deployments. Standalone deployment configurations are marked explicitly below.
To enforce SSL for the Runtime component:

1. Create an SSL Certificate Secret. 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 (refer to the full example at the bottom).

• Kubernetes: Store the certificate and key as a Kubernetes Secret. This can be configured using extraManifests in your Helm chart (see the example at the bottom of this page).

• Standalone: Specify the file system path to the certificate and private key directly in your configuration.

2. Configure Java Keystore Environment Variables. Modify the required environment variables for configuring the Java keystore:

   • runtime.extraEnv.RTCONF_SSL__KEYSTORE_PATH - Path inside the container for the Java keystore
   • runtime.extraEnvSecrets.RTCONF_SSL__KEYSTORE_PASSWORD - Password for the Java keystore
     • For Standalone deployments, users will have to manually create and populate this keystore.

3. Enable SSL in Application

• Configure the application to enable SSL:

runtime:
  extraEnv:
    RTCONF_SSL__IS_HTTPS: "true"

4. Configure Custom Health Check Port (Optional)
   Set a custom port for the health check API endpoint:

runtime:
  extraEnv:
    RTCONF_SERVICE_MGMT_PORT: "3000"

5. Change health check probes to use the HTTPS scheme when SSL is enabled.

• In Standalone deployments, make sure your health check client supports HTTPS and targets the correct port and certificate configuration.

Note: Kubernetes will not attempt to validate the certificate. Refer to the Kubernetes documentation for more details.

runtime:
  livenessProbe:
    scheme: "HTTPS"
  readinessProbe:
    scheme: "HTTPS"

6. Mount SSL Certificates
   Mount the certificates from the secret created in Step 1:

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

7. Configure Runtime Command
   Modify the runtime pod command to import the certificate to 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

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

Complete Configuration Example

runtime:
  livenessProbe:
    scheme: "HTTPS"
  readinessProbe:
    scheme: "HTTPS"
  extraEnv:
    RTCONF_SSL__IS_HTTPS: "true"
    RTCONF_SSL__KEYSTORE_PATH: "/usr/lib/jvm/default-jvm/lib/security/cacerts"
    RTCONF_SERVICE_MGMT_PORT: "3000"
  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