Rest Proxy Chart Values Reference

This reference lists the Rest Proxy values the Axual Streaming Helm chart exposes: the image and pull secrets, the Kafka init container, logging, TLS, and the Spring Boot application configuration for the server and the Kafka clients.

Type

Reference

Goal

Look up a Rest Proxy chart value while writing the Axual Streaming values file.

Audience

Platform Operator deploying the Rest Proxy as part of the Axual Streaming layer.

When to use

While configuring the Rest Proxy, alongside the procedure that installs Axual Streaming.

Contents

The sections below cover each area in this reference:

About Rest Proxy

What the Rest Proxy does and which endpoints it serves is described in Rest Proxy.

Rest Proxy Configuration

The values below are the ones an Axual Streaming installation normally sets, with an example you can build your own values.yaml from. The chart’s full value list is in Rest Proxy Helm Readme.

Basic Rest Proxy Configuration

The Axual Streaming chart configures and deploys the Rest Proxy. The example below contains every required field.

Click to open rest-proxy-values.yaml
global:
  rest-proxy:
    enabled: true

rest-proxy:
  image:
  #  tag: "1.5.4" #override
    registry: "registry.axual.io"
  keystoreProvider:
    image:
      registry: "registry.axual.io"
  # Enable podDisruptionBudget
  podDisruptionBudget:
    enabled: true
  # Enable Reloader
  # -- Optional: deployment-specific annotations.
  # These are not required for the Axual Platform itself,
  # but can be useful depending on your cluster setup.
  podAnnotations:
    # Enables automatic pod reload when ConfigMaps/Secrets change (Stakater Reloader)
    "reloader.stakater.com/auto": "true"
    # Specifies Fluent Bit parser for structured log collection
    fluentbit.io/parser: json

  config:
    # REST Proxy component is installed for a specific tenant, specific instance, specific cluster. If it is needed to add REST Proxy to other instance then a separate chart can be used to install it
    axual:
      tenant: "<tenant-short-name>" # The target tenant
      instance: "<instance-short-name>" # The shortname of the target instance
      configMode: "static"
      static-configuration:
        tenant: "<tenant-short-name>" # The target tenant
        instance: "<instance-short-name>" # The shortname of the target instance
        cluster: "<cluster-name>" # The name of the target cluster
        # If REST Proxy is running in the same Kubernetes cluster we can just use the internal service url as well.
        bootstrapServers: "bootstrap-kafka.<domain>:443"
        schemaRegistryUrl: "https://apicurio.<domain>"
        enable.value.headers: "false"
        groupIdResolver: "io.axual.common.resolver.GroupPatternResolver"
        groupIdPattern: "{tenant}-{instance}-{environment}-{group}" # This should be the same with the group pattern which is used in cluster configuration
        topicResolver: "io.axual.common.resolver.TopicPatternResolver"
        topicPattern: "{tenant}-{instance}-{environment}-{topic}" # This should be the same with the group pattern which is used in topic configuration
        transactionalIdResolver: "io.axual.common.resolver.TransactionalIdPatternResolver"
        transactionalIdPattern: "{tenant}-{instance}-{environment}-{app.id}-{transactional.id}" # This should be the same with the group pattern which is used in transaction configuration
        # We use AdvancedAclPrincipalBuilder as we have chained principals. In case of principal without chain, use BasicAclPrincipalBuilder
        principalBuilderClass: io.axual.security.principal.AdvancedAclPrincipalBuilder
    spring:
      security:
        oauth2:
          resourceserver:
            jwt:
              issuer-uri: https://sts.windows.net/dcbcc3be-2c54-4328-86ee-2589d4da46de/  #iss of the token
      application:
        name: axual-rest-proxy
  logbackConfig: |
    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
      <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
      </appender>

      <root level="INFO">
        <appender-ref ref="console" />
      </root>
    </configuration>
  tls:
    clientEnabled: true
    serverEnabled: true
    clientAuth: need
    automatedKeystores: true
    createServerKeypairSecret: false
    serverKeypairSecretName: server-cert-secret
    createClientKeypairSecret: false
    clientKeypairSecretName: rest-proxy-cert-secret
    createTruststoreCaSecret: false
    truststoreCaSecretName: my-external-ca
  service:
    type: ClusterIP
  ingress:
    enabled: true
    # -- The name of the IngressClass cluster resource.
    # NOTE: "nginx" refers to the community ingress-nginx controller, deprecated March 2026.
    # Axual has migrated to a supported enterprise-grade ingress controller.
    # Update className and annotations to match the ingress controller in your cluster.
    className: nginx
    # -- Annotations to add to the Ingress resource.
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
      nginx.ingress.kubernetes.io/ssl-passthrough: "true"
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      external-dns.alpha.kubernetes.io/hostname: "restproxy.<domain>"
      axual.com/service.class: "aks-np-ams"
      external-dns.alpha.kubernetes.io/ttl: "60"
    hosts:
      - # -- The fully qualified domain name of a network host.
        host: restproxy.<domain>
        paths:
          - # -- Matched against the path of an incoming request.
            path: /
            # -- Determines the interpretation of the Path matching.
            # Can be one of the following values: `Exact`, `Prefix`, `ImplementationSpecific`.
            pathType: ImplementationSpecific
    # -- TLS configuration for this Ingress.
    tls:
      # Use secretName to update the certificates of the ingress
      - secretName: server-cert-secret
        hosts:
          - restproxy.<domain>

  kafkaInitContainer:
    # -- Kafka bootstrap servers to initialize
    # If REST Proxy is running in the same Kubernetes cluster we can just use the internal service url as well.
    bootstrapServers: "SSL://bootstrap-kafka.<domain>:443"
    # -- Principal common name to give access to (should match tls.clientKeypairSecretName)
    # principal: "[0] CN=Axual Root CA 2018, [1] CN=Axual Intermediate CA 2018 1, [2] CN=REST Proxy Client, O=Axual B.V.,L=Utrecht,ST=Utrecht,C=NL"
    # Check in Kafka logs if there is a certificate related error and check the CN there.
    # In this example, we dont have chained certificates so the value here should be just "REST Proxy Client"
    principal: "CN=REST Proxy Client"
    # Those two should be set based on the topic and group pattern, in this example the should be just {instance}
    # -- Group prefix to give access to (usually {tenant}-{instance})
    groupPattern: "<instance-short-name>"
    # -- Topic prefix to give access to (usually {tenant}-{instance})
    topicPattern: "<instance-short-name>"
    tls:
      # -- Existing Keypair secret name
      keypairSecretName: "server-cert-secret"
      # -- Existing Keypair key name
      keypairSecretKeyName: "tls.key"
      # -- Existing Keypair certificate name
      keypairSecretCertName: "tls.crt"
      # -- Existing Truststore secret name
      truststoreCaSecretName: "my-external-ca"
      # -- Existing Truststore certificate name
      truststoreCaSecretCertName: "ca.crt"
  serviceMonitor:
    enabled: true
The Rest Proxy must use a client certificate whose identity matches the DNS name in the server certificate.
Confirm that restproxy.<domain> presents the correct CA in its certificate with openssl s_client -showcerts -verify 5 -connect 192.168.99.120:443 -servername restproxy.<domain> < /dev/null.

The script below produces a message to Kafka through the Rest Proxy, which tests the deployment end to end.

Create the topic and the application in Self-Service before using them for this test.
Click to open rest-proxy-message.sh
#!/bin/bash
# https://<rest-proxy-ingress>
REST_HOST="https://restproxy.<domain>"
# Short name of the target environment
ENVIRONMENT=""
# Name of the target topic
STREAM=""
# The uuid of the target application. Can be found in URL of the application details in UI
UUID=""
# The id of the target application
APP_ID=""
JSON_HEADER="Content-Type: application/json"
PRODUCE_RECORD='{
   "keyMessage":{
      "type":"STRING",
      "message":"Random key: '$RANDOM'"
   },
   "valueMessage":{
      "type":"STRING",
      "message":"Random value: '$RANDOM'"
   }
}'
echo "Sending"
curl -vk --request POST \
  --url "${REST_HOST}/stream/${ENVIRONMENT}/${STREAM}" \
  --header "axual-application-id: $APP_ID" \
  --header 'axual-application-version: 1.0' \
  --header "axual-producer-uuid: $UUID" \
  --header "$JSON_HEADER" \
  --key <path-to-certificate-key> \
  --cert <path-to-certificate-crt> \
  --data "$PRODUCE_RECORD" \

The subsections below describe each area of that example in more detail.

Rest Proxy Repository

Start by saying where the Rest Proxy image is pulled from.

values.yaml
rest-proxy:

  image:
    registry: "registry.axual.io"
    tag: "1.12.0"
  imagePullSecrets:
    - name: docker-credentials

Kafka Init Container

The Rest Proxy runs an init container from a Kafka image to create its Access Control Lists (ACLs) in the Kafka cluster. That container needs the following values:

  • bootstrapServers of the Kafka cluster the ACLs are applied to

  • principal the ACLs are granted to. Depending on how Kafka is configured, this is either the SSL chain or the common name.

  • groupPattern, the group prefix to grant access to, typically {tenant}-{instance}- depending on the cluster group pattern

  • topicPattern, the topic prefix to grant access to, typically {tenant}-{instance}- depending on the cluster topic pattern

  • tls, the Secrets needed to connect to the Kafka cluster

If Kafka validates ACLs over the full principal chain, give the whole chain, as in [0] CN=Root CA, [1] CN=Intermediate CA, [3] CN=schema-registry. Otherwise give the common name prefixed with CN:.
values.yaml
rest-proxy:
  kafkaInitContainer:
    bootstrapServers: ""
    principal: ""
    groupPattern: ""
    topicPattern: ""
    tls:
      keypairSecretName: ""
      keypairSecretKeyName: ""
      keypairSecretCertName: ""
      truststoreCaSecretName: ""
      truststoreCaSecretCertName: ""

Logback Configuration

The logging block becomes a ConfigMap holding the logback configuration the Rest Proxy application reads. It takes three settings:

  • pattern defines the exact pattern for log statements

  • rootLoglevel sets the base logging level

  • loggers sets a level per logger, overriding the root level for that logger

values.yaml
rest-proxy:

  logging:
    pattern: '%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}'
    rootLoglevel: debug
    loggers:
      io.axual: info
      io.axual.proxy.rest: debug
      org.apache.kafka.clients.admin.AdminClientConfig: info
      org.apache.kafka.clients.producer.ProducerConfig: info
      org.apache.kafka.clients.consumer.ConsumerConfig: info
      org.springframework.boot.web: debug

TLS Configuration

You can point the Rest Proxy at Secrets holding the PEM certificates it generates its keystores from:

  • Server keypair

  • Client keypair

  • Truststore

values.yaml
rest-proxy:

  tls:
    # -- Creates server keypair from PEM
    createServerKeypairSecret: true
    # -- PEM used to generate the server keypair if `createServerKeypairSecret` is true
    serverCertificatePem: <server-certificate>
    # -- PEM used to generate the server keypair if `createServerKeypairSecret` is true
    serverKeyPem: <server-key>

    # -- Creates client keypair from PEM
    createClientKeypairSecret: true
    # -- PEM used to generate the client keypair if `createClientKeypairSecret` is true
    clientCertificatePem: <client-certificate>
    # -- PEM used to generate the client keypair if `createClientKeypairSecret` is true
    clientKeyPem: <client-key>

    # -- Creates truststore from PEMs
    createTruststoreCaSecret: true
    # -- Set of PEMs used to generate the truststore if `createTruststoreCaSecret` is true
    caCerts:
      ca_one.crt:  <first-cert>
      ca_two.crt: <second-cert>

Each of those Secrets must have the shape described in Secret formats.

Credentials Secret: secrets and existingSecretName

Rest Proxy reads a second configuration file, secrets.yml, from a Kubernetes Secret. It takes the same structure as config, is loaded after it, and overrides any key the two share. existingSecretName names an existing Secret holding a secrets.yml key. When it is "", the chart creates the Secret from secrets. For the procedure, see How to Store Component Credentials in a Kubernetes Secret.

When the chart generates the keystores, as in TLS Configuration, it also sets their passwords, so they stay out of config. The credential keys that belong in secrets.yml, when you set them yourself, are:

  • axual.ssl-keystore-password, axual.ssl-key-password and axual.ssl-truststore-password, for client keystores you supply

  • server.ssl.key-store-password, server.ssl.key-password and server.ssl.trust-store-password, for server keystores you supply

  • axual.static-configuration.schemaRegistryUrl, when axual.avro.basicAuthCredentialsSource is URL and the URL carries the registry username and password

Application Configuration

The Rest Proxy is a Spring Boot application, so it reads its settings from an application.yml file. Whatever you put under config is injected into a ConfigMap and mounted as that file.

values.yaml
rest-proxy:
  config:

The subsections below cover the config entries that matter most.

Logback and Server Configuration

logging.config points at the logback.xml built from the loggers block above. The server block sets the port, the SSL ciphers the server accepts, and the Tomcat access log, which is disabled by default.

values.yaml
rest-proxy:
  config:
    logging.config: /logging/logback.xml

    server:
      port: 18111
      ssl.ciphers: 'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA'
      tomcat:
        accesslog:
          #  defaults to disabled
          enabled: false
          pattern: '{"host": "%h", "timestamp":"%{yyyy-MM-dd HH:mm:ss.SSS}t", "thread": "%I", "request_line": "%r", "response_status_code":"%s", "bytes_sent":  "%b", "request_process_time":"%D","user_agent": "%{user-agent}i"}'
          directory: "/dev"
          prefix: "stdout"
          buffered: false
          suffix: ""
          fileDateFormat: ""
Rest Proxy Client Configuration

The axual block configures the Kafka clients the Rest Proxy instantiates, including the producer, the consumer and the Avro serialisation.

values.yaml
rest-proxy:

  # -- Configuration passed to the container.
  # Contents get injected to a ConfigMap, which gets mounted as an `application.yml` file.
  config:

    axual:
      tenant: axual
      instance: local
      applicationId: rest-proxy
      applicationVersion: 1.12.0

      sslProtocol: "SSL"
      sslEnableHostnameVerification: false
      acl:
        cacheTtlMs: 30000
        retrySleep: 100
        useCache: false
      producer:
        config:
          # Overrides kafka producer configuration
          metadata-max-age-ms: 180000
          connections-max-idle-ms: 180000
          request-timeout-ms: 120000
          retries: 3
          max-block-ms: 60000
          acks: all
          batch-size: 10
          linger-ms: 1
          max-in-flight-requests-per-connection: 5
          send-buffer-bytes: 10000
          receive-buffer-bytes: 10000
      consumer:
        numberOfThreads: 10
        config:
          # Overrides kafka consumer configuration
          metadata-max-age-ms: 180000
          connections-max-idle-ms: 180000
      avro:
        maxSchemasPerSubject: 100
        basicAuthCredentialsSource: ""
Rest Proxy Static Configuration

The static-configuration block holds the settings the Rest Proxy needs to connect to the Kafka cluster and to resolve group IDs and topic names.

values.yaml
rest-proxy:
  config:
    axual:
      static-configuration:
        tenant: "axual"
        instance: "test"
        cluster: "ams01"
        bootstrapServers: "bootstrap.ams01.cloud.axual.com:9094"
        schemaRegistryUrl: "schema-registry-slave.cloud.axual.com"
        groupIdResolver: "io.axual.common.resolver.GroupPatternResolver"
        groupIdPattern: "{tenant}-{instance}-{environment}-{group}"
        topicResolver: "io.axual.common.resolver.TopicPatternResolver"
        topicPattern: "{tenant}-{instance}-{environment}-{topic}"
        transactionalIdResolver: "io.axual.common.resolver.TransactionalIdPatternResolver"
        transactionalIdPattern: "{tenant}-{instance}-{environment}-{transactional.id}"
        principalBuilderClass: io.axual.security.principal.AdvancedAclPrincipalBuilder