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. |
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.
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:
-
bootstrapServersof the Kafka cluster the ACLs are applied to -
principalthe 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:.
|
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:
-
patterndefines the exact pattern for log statements -
rootLoglevelsets the base logging level -
loggerssets a level per logger, overriding the root level for that logger
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
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-passwordandaxual.ssl-truststore-password, for client keystores you supply -
server.ssl.key-store-password,server.ssl.key-passwordandserver.ssl.trust-store-password, for server keystores you supply -
axual.static-configuration.schemaRegistryUrl, whenaxual.avro.basicAuthCredentialsSourceisURLand 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.
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.
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.
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.
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