Back to Guides

Management interface reference

By default, Quarkus exposes the management endpoints under /q on the main HTTP server. The same HTTP server provides the application endpoints and the management endpoints.

This document presents how you can use a separate HTTP server (bound to a different network interface and port) for the management endpoints. It avoids exposing these endpoints on the main server and, therefore, prevents undesired accesses.

1. Enabling the management interface

To enable the management interface, use the following build-time property:

quarkus.management.enabled=true

By default, management endpoints will be exposed on: http://0.0.0.0:9000/q. For example, http://0.0.0.0:9000/q/health/ready for the readiness probe.

SmallRye Health Checks, SmallRye Metrics, Micrometer and Info endpoints will be declared as management endpoints when the management interface is enabled.

2. Configure the host, port and scheme

By default, the management interface is exposed on the interface: 0.0.0.0 (all interfaces) and on the port 9000 (9001 in test mode). It does not use TLS (https) by default.

You can configure the host, ports, and TLS certificates using the following properties:

  • quarkus.management.host - the interface / host

  • quarkus.management.port - the port

  • quarkus.management.test-port - the port to use in test mode

  • quarkus.management.ssl - the TLS configuration, same as for the main HTTP server.

Here is a configuration example exposing the management interface on https://localhost:9002:

quarkus.management.enabled=true
quarkus.management.host=localhost
quarkus.management.port=9002
quarkus.management.ssl.certificate.key-store-file=server-keystore.jks
quarkus.management.ssl.certificate.key-store-password=secret
Unlike the main HTTP server, the management interface does not handle http and https at the same time. If https is configured, plain HTTP requests will be rejected.

3. Configure the root path

Management endpoints are configured differently than standard HTTP endpoints. They use a unique root path, which is /q by default. This management root path can be configured using the quarkus.management.root-path property. For example, if you want to expose the management endpoints under /management use:

quarkus.management.enabled=true
quarkus.management.root-path=/management

The mounting rules of the management endpoints slightly differ from the ones used when using the main HTTP server:

  • Management endpoints configured using a relative path (not starting with /) will be served from the configured root path. For example, if the endpoint path is health and the root path is management, the resulting path is /management/health

  • Management endpoints configured using an absolute path (starting with /) will be served from the root. For example, if the endpoint path is /health, the resulting path is /health, regardless of the root path

  • The management interface does not use the HTTP root path from the main HTTP server.

The quarkus.http.root-path property is only applied to the main HTTP server and not to the management interface. In addition, the quarkus.http.non-application-root-path property is not used for endpoint exposed on the management interface.

4. Create a management endpoint in an extension

To expose an endpoint on the management interface from the code of an application, refer to the application section.

SmallRye Health Checks, SmallRye Metrics, and Micrometer endpoints will be declared as management endpoints when the management interface is enabled.

if you do not enable the management interface, these endpoints will be served using the main HTTP server (under /q by default).

Extensions can create a management endpoint by defining a non application route and calling management() method:

@BuildStep
void createManagementRoute(BuildProducer<RouteBuildItem> routes,
        NonApplicationRootPathBuildItem nonApplicationRootPathBuildItem,
        MyRecorder recorder) {

    routes.produce(nonApplicationRootPathBuildItem.routeBuilder()
        .management() // Must be called BEFORE the routeFunction method
        .routeFunction("my-path", recorder.route())
        .handler(recorder.getHandler())
        .blockingRoute()
        .build());
    //...
}

If the management interface is enabled, the endpoint will be exposed on: http://0.0.0.0:9000/q/my-path. Otherwise, it will be exposed on: http://localhost:8080/q/my-path.

Management endpoints can only be declared by extensions and not from the application code.

5. Exposing an endpoint on the management interface (as an application)

You can expose endpoints on the management interface by registering routes on the management router. To access the router use the following code:

public void registerManagementRoutes(@Observes ManagementInterface mi) {
       mi.router().get("/admin").handler(rc ->
            rc.response().end("admin it is")
       );
}

The io.quarkus.vertx.http.ManagementInterface event is fired when the management interface is initialized. So, if the management interface is not enabled, the method won’t be called.

The router() method returns a io.vertx.ext.web.Router object which can be used to register routes. The paths are relative to /. For example, the previous snippet registers a route on /admin. This route is accessible on http://0.0.0.0:9000/admin, if you use the default host and port.

More details about the Router API can be found on the Vert.x Web documentation.

6. Management Interface Configuration

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.management.enabled

Enables / Disables the usage of a separate interface/port to expose the management endpoints. If sets to true, the management endpoints will be exposed to a different HTTP server. This avoids exposing the management endpoints on a publicly available server.

Environment variable: QUARKUS_MANAGEMENT_ENABLED

boolean

false

quarkus.management.auth.basic

If basic auth should be enabled.

Environment variable: QUARKUS_MANAGEMENT_AUTH_BASIC

boolean

quarkus.management.auth.proactive

If this is true and credentials are present then a user will always be authenticated before the request progresses. If this is false then an attempt will only be made to authenticate the user if a permission check is performed or the current user is required for some other reason.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PROACTIVE

boolean

true

quarkus.management.ssl.client-auth

Configures the engine to require/request client authentication. NONE, REQUEST, REQUIRED

Environment variable: QUARKUS_MANAGEMENT_SSL_CLIENT_AUTH

none, request, required

none

quarkus.management.root-path

A common root path for management endpoints. Various extension-provided management endpoints such as metrics and health are deployed under this path by default.

Environment variable: QUARKUS_MANAGEMENT_ROOT_PATH

string

/q

quarkus.management.enable-compression

If responses should be compressed. Note that this will attempt to compress all responses, to avoid compressing already compressed content (such as images) you need to set the following header: Content-Encoding: identity Which will tell vert.x not to compress the response.

Environment variable: QUARKUS_MANAGEMENT_ENABLE_COMPRESSION

boolean

false

quarkus.management.enable-decompression

When enabled, vert.x will decompress the request’s body if it’s compressed. Note that the compression format (e.g., gzip) must be specified in the Content-Encoding header in the request.

Environment variable: QUARKUS_MANAGEMENT_ENABLE_DECOMPRESSION

boolean

false

quarkus.management.compression-level

The compression level used when compression support is enabled.

Environment variable: QUARKUS_MANAGEMENT_COMPRESSION_LEVEL

int

quarkus.management.auth.permission."permissions".enabled

Determines whether the entire permission set is enabled, or not. By default, if the permission set is defined, it is enabled.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PERMISSION__PERMISSIONS__ENABLED

boolean

quarkus.management.auth.permission."permissions".policy

The HTTP policy that this permission set is linked to. There are 3 built in policies: permit, deny and authenticated. Role based policies can be defined, and extensions can add their own policies.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PERMISSION__PERMISSIONS__POLICY

string

required

quarkus.management.auth.permission."permissions".methods

The methods that this permission set applies to. If this is not set then they apply to all methods. Note that if a request matches any path from any permission set, but does not match the constraint due to the method not being listed then the request will be denied. Method specific permissions take precedence over matches that do not have any methods set. This means that for example if Quarkus is configured to allow GET and POST requests to /admin to and no other permissions are configured PUT requests to /admin will be denied.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PERMISSION__PERMISSIONS__METHODS

list of string

quarkus.management.auth.permission."permissions".paths

The paths that this permission check applies to. If the path ends in /* then this is treated as a path prefix, otherwise it is treated as an exact match. Matches are done on a length basis, so the most specific path match takes precedence. If multiple permission sets match the same path then explicit methods matches take precedence over matches without methods set, otherwise the most restrictive permissions are applied.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PERMISSION__PERMISSIONS__PATHS

list of string

quarkus.management.auth.permission."permissions".auth-mechanism

Path specific authentication mechanism which must be used to authenticate a user. It needs to match HttpCredentialTransport authentication scheme such as 'basic', 'bearer', 'form', etc.

Environment variable: QUARKUS_MANAGEMENT_AUTH_PERMISSION__PERMISSIONS__AUTH_MECHANISM

string

quarkus.management.auth.policy."role-policy".roles-allowed

The roles that are allowed to access resources protected by this policy. By default, access is allowed to any authenticated user.

Environment variable: QUARKUS_MANAGEMENT_AUTH_POLICY__ROLE_POLICY__ROLES_ALLOWED

list of string

**

quarkus.management.auth.policy."role-policy".permissions

Permissions granted to the SecurityIdentity if this policy is applied successfully (the policy allows request to proceed) and the authenticated request has required role. For example, you can map permission perm1 with actions action1 and action2 to role admin by setting quarkus.http.auth.policy.role-policy1.permissions.admin=perm1:action1,perm1:action2 configuration property. Granted permissions are used for authorization with the @PermissionsAllowed annotation.

Environment variable: QUARKUS_MANAGEMENT_AUTH_POLICY__ROLE_POLICY__PERMISSIONS

Map<String,List<String>>

quarkus.management.auth.policy."role-policy".permission-class

Permissions granted by this policy will be created with a java.security.Permission implementation specified by this configuration property. The permission class must declare exactly one constructor that accepts permission name (String) or permission name and actions (String, String[]).

Environment variable: QUARKUS_MANAGEMENT_AUTH_POLICY__ROLE_POLICY__PERMISSION_CLASS

string

io.quarkus.security.StringPermission

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

quarkus.management.port

The HTTP port

Environment variable: QUARKUS_MANAGEMENT_PORT

int

9000

quarkus.management.test-port

The HTTP port

Environment variable: QUARKUS_MANAGEMENT_TEST_PORT

int

9001

quarkus.management.host

The HTTP host Defaults to 0.0.0.0 Defaulting to 0.0.0.0 makes it easier to deploy Quarkus to container, however it is not suitable for dev/test mode as other people on the network can connect to your development machine.

Environment variable: QUARKUS_MANAGEMENT_HOST

string

quarkus.management.host-enabled

Enable listening to host:port

Environment variable: QUARKUS_MANAGEMENT_HOST_ENABLED

boolean

true

quarkus.management.ssl.certificate.credentials-provider

The CredentialsProvider. If this property is configured then a matching 'CredentialsProvider' will be used to get the keystore, keystore key and truststore passwords unless these passwords have already been configured. Please note that using MicroProfile ConfigSource which is directly supported by Quarkus Configuration should be preferred unless using CredentialsProvider provides for some additional security and dynamism.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_CREDENTIALS_PROVIDER

string

quarkus.management.ssl.certificate.credentials-provider-name

The credentials provider bean name. It is the &#64;Named value of the credentials provider bean. It is used to discriminate if multiple CredentialsProvider beans are available. It is recommended to set this property even if there is only one credentials provider currently available to ensure the same provider is always found in deployments where more than one provider may be available.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_CREDENTIALS_PROVIDER_NAME

string

quarkus.management.ssl.certificate.files

The list of path to server certificates using the PEM format. Specifying multiple files require SNI to be enabled.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_FILES

list of path

quarkus.management.ssl.certificate.key-files

The list of path to server certificates private key file using the PEM format. Specifying multiple files require SNI to be enabled. The order of the key files must match the order of the certificates.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_FILES

list of path

quarkus.management.ssl.certificate.key-store-file

An optional key store which holds the certificate information instead of specifying separate files.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_FILE

path

quarkus.management.ssl.certificate.key-store-file-type

An optional parameter to specify type of the key store file. If not given, the type is automatically detected based on the file name.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_FILE_TYPE

string

quarkus.management.ssl.certificate.key-store-provider

An optional parameter to specify a provider of the key store file. If not given, the provider is automatically detected based on the key store file type.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_PROVIDER

string

quarkus.management.ssl.certificate.key-store-password

A parameter to specify the password of the key store file. If not given, and if it can not be retrieved from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_PASSWORD

string

password

quarkus.management.ssl.certificate.key-store-password-key

A parameter to specify a CredentialsProvider property key which can be used to get the password of the key store file from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_PASSWORD_KEY

string

quarkus.management.ssl.certificate.key-store-key-alias

An optional parameter to select a specific key in the key store. When SNI is disabled, if the key store contains multiple keys and no alias is specified, the behavior is undefined.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_KEY_ALIAS

string

quarkus.management.ssl.certificate.key-store-key-password

An optional parameter to define the password for the key, in case it’s different from key-store-password If not given then it may be retrieved from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_KEY_PASSWORD

string

quarkus.management.ssl.certificate.key-store-key-password-key

A parameter to specify a CredentialsProvider property key which can be used to get the password for the key from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_KEY_STORE_KEY_PASSWORD_KEY

string

quarkus.management.ssl.certificate.trust-store-file

An optional trust store which holds the certificate information of the certificates to trust.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_FILE

path

quarkus.management.ssl.certificate.trust-store-file-type

An optional parameter to specify type of the trust store file. If not given, the type is automatically detected based on the file name.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_FILE_TYPE

string

quarkus.management.ssl.certificate.trust-store-provider

An optional parameter to specify a provider of the trust store file. If not given, the provider is automatically detected based on the trust store file type.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_PROVIDER

string

quarkus.management.ssl.certificate.trust-store-password

A parameter to specify the password of the trust store file. If not given then it may be retrieved from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_PASSWORD

string

quarkus.management.ssl.certificate.trust-store-password-key

A parameter to specify a CredentialsProvider property key which can be used to get the password of the trust store file from CredentialsProvider.

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_PASSWORD_KEY

string

quarkus.management.ssl.certificate.trust-store-cert-alias

An optional parameter to trust only one specific certificate in the trust store (instead of trusting all certificates in the store).

Environment variable: QUARKUS_MANAGEMENT_SSL_CERTIFICATE_TRUST_STORE_CERT_ALIAS

string

quarkus.management.ssl.cipher-suites

The cipher suites to use. If none is given, a reasonable default is selected.

Environment variable: QUARKUS_MANAGEMENT_SSL_CIPHER_SUITES

list of string

quarkus.management.ssl.protocols

The list of protocols to explicitly enable.

Environment variable: QUARKUS_MANAGEMENT_SSL_PROTOCOLS

list of string

TLSv1.3,TLSv1.2

quarkus.management.ssl.sni

Enables Server Name Indication (SNI), an TLS extension allowing the server to use multiple certificates. The client indicate the server name during the TLS handshake, allowing the server to select the right certificate.

Environment variable: QUARKUS_MANAGEMENT_SSL_SNI

boolean

false

quarkus.management.handle-100-continue-automatically

When set to true, the HTTP server automatically sends 100 CONTINUE response when the request expects it (with the Expect: 100-Continue header).

Environment variable: QUARKUS_MANAGEMENT_HANDLE_100_CONTINUE_AUTOMATICALLY

boolean

false

quarkus.management.limits.max-header-size

The maximum length of all headers.

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_HEADER_SIZE

MemorySize

20K

quarkus.management.limits.max-body-size

The maximum size of a request body.

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_BODY_SIZE

MemorySize

10240K

quarkus.management.limits.max-chunk-size

The max HTTP chunk size

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_CHUNK_SIZE

MemorySize

8192

quarkus.management.limits.max-initial-line-length

The maximum length of the initial line (e.g. "GET / HTTP/1.0").

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_INITIAL_LINE_LENGTH

int

4096

quarkus.management.limits.max-form-attribute-size

The maximum length of a form attribute.

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_FORM_ATTRIBUTE_SIZE

MemorySize

2048

quarkus.management.limits.max-connections

The maximum number of connections that are allowed at any one time. If this is set it is recommended to set a short idle timeout.

Environment variable: QUARKUS_MANAGEMENT_LIMITS_MAX_CONNECTIONS

int

quarkus.management.idle-timeout

Http connection idle timeout

Environment variable: QUARKUS_MANAGEMENT_IDLE_TIMEOUT

Duration

30M

quarkus.management.body.handle-file-uploads

Whether the files sent using multipart/form-data will be stored locally. If true, they will be stored in quarkus.http.body-handler.uploads-directory and will be made available via io.vertx.ext.web.RoutingContext.fileUploads(). Otherwise, the files sent using multipart/form-data will not be stored locally, and io.vertx.ext.web.RoutingContext.fileUploads() will always return an empty collection. Note that even with this option being set to false, the multipart/form-data requests will be accepted.

Environment variable: QUARKUS_MANAGEMENT_BODY_HANDLE_FILE_UPLOADS

boolean

true

quarkus.management.body.uploads-directory

The directory where the files sent using multipart/form-data should be stored. Either an absolute path or a path relative to the current directory of the application process.

Environment variable: QUARKUS_MANAGEMENT_BODY_UPLOADS_DIRECTORY

string

${java.io.tmpdir}/uploads

quarkus.management.body.merge-form-attributes

Whether the form attributes should be added to the request parameters. If true, the form attributes will be added to the request parameters; otherwise the form parameters will not be added to the request parameters

Environment variable: QUARKUS_MANAGEMENT_BODY_MERGE_FORM_ATTRIBUTES

boolean

true

quarkus.management.body.delete-uploaded-files-on-end

Whether the uploaded files should be removed after serving the request. If true the uploaded files stored in quarkus.http.body-handler.uploads-directory will be removed after handling the request. Otherwise, the files will be left there forever.

Environment variable: QUARKUS_MANAGEMENT_BODY_DELETE_UPLOADED_FILES_ON_END

boolean

true

quarkus.management.body.preallocate-body-buffer

Whether the body buffer should pre-allocated based on the Content-Length header value. If true the body buffer is pre-allocated according to the size read from the Content-Length header. Otherwise, the body buffer is pre-allocated to 1KB, and is resized dynamically

Environment variable: QUARKUS_MANAGEMENT_BODY_PREALLOCATE_BODY_BUFFER

boolean

false

quarkus.management.body.multipart.file-content-types

A comma-separated list of ContentType to indicate whether a given multipart field should be handled as a file part. You can use this setting to force HTTP-based extensions to parse a message part as a file based on its content type. For now, this setting only works when using RESTEasy Reactive.

Environment variable: QUARKUS_MANAGEMENT_BODY_MULTIPART_FILE_CONTENT_TYPES

list of string

quarkus.management.accept-backlog

The accept backlog, this is how many connections can be waiting to be accepted before connections start being rejected

Environment variable: QUARKUS_MANAGEMENT_ACCEPT_BACKLOG

int

-1

quarkus.management.domain-socket

Path to a unix domain socket

Environment variable: QUARKUS_MANAGEMENT_DOMAIN_SOCKET

string

/var/run/io.quarkus.management.socket

quarkus.management.domain-socket-enabled

Enable listening to host:port

Environment variable: QUARKUS_MANAGEMENT_DOMAIN_SOCKET_ENABLED

boolean

false

quarkus.management.proxy.proxy-address-forwarding

If this is true then the address, scheme etc. will be set from headers forwarded by the proxy server, such as X-Forwarded-For. This should only be set if you are behind a proxy that sets these headers.

Environment variable: QUARKUS_MANAGEMENT_PROXY_PROXY_ADDRESS_FORWARDING

boolean

false

quarkus.management.proxy.allow-forwarded

If this is true and proxy address forwarding is enabled then the standard Forwarded header will be used. In case the not standard X-Forwarded-For header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-x-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.

Environment variable: QUARKUS_MANAGEMENT_PROXY_ALLOW_FORWARDED

boolean

false

quarkus.management.proxy.allow-x-forwarded

If either this or allow-forwarded are true and proxy address forwarding is enabled then the not standard Forwarded header will be used. In case the standard Forwarded header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.

Environment variable: QUARKUS_MANAGEMENT_PROXY_ALLOW_X_FORWARDED

boolean

quarkus.management.proxy.enable-forwarded-host

Enable override the received request’s host through a forwarded host header.

Environment variable: QUARKUS_MANAGEMENT_PROXY_ENABLE_FORWARDED_HOST

boolean

false

quarkus.management.proxy.forwarded-host-header

Configure the forwarded host header to be used if override enabled.

Environment variable: QUARKUS_MANAGEMENT_PROXY_FORWARDED_HOST_HEADER

string

X-Forwarded-Host

quarkus.management.proxy.enable-forwarded-prefix

Enable prefix the received request’s path with a forwarded prefix header.

Environment variable: QUARKUS_MANAGEMENT_PROXY_ENABLE_FORWARDED_PREFIX

boolean

false

quarkus.management.proxy.forwarded-prefix-header

Configure the forwarded prefix header to be used if prefixing enabled.

Environment variable: QUARKUS_MANAGEMENT_PROXY_FORWARDED_PREFIX_HEADER

string

X-Forwarded-Prefix

quarkus.management.proxy.trusted-proxies

Configure the list of trusted proxy addresses. Received Forwarded, X-Forwarded or X-Forwarded-* headers from any other proxy address will be ignored. The trusted proxy address should be specified as the IP address (IPv4 or IPv6), hostname or Classless Inter-Domain Routing (CIDR) notation. Please note that Quarkus needs to perform DNS lookup for all hostnames during the request. For that reason, using hostnames is not recommended. Examples of a socket address in the form of host or host:port: - 127.0.0.1:8084 - [0:0:0:0:0:0:0:1] - [0:0:0:0:0:0:0:1]:8084 - [::] - localhost - localhost:8084 Examples of a CIDR notation: - ::/128 - ::/0 - 127.0.0.0/8 Please bear in mind that IPv4 CIDR won’t match request sent from the IPv6 address and the other way around.

Environment variable: QUARKUS_MANAGEMENT_PROXY_TRUSTED_PROXIES

list of TrustedProxyCheckPart

All proxy addresses are trusted

quarkus.management.header."header".path

The path this header should be applied

Environment variable: QUARKUS_MANAGEMENT_HEADER__HEADER__PATH

string

/*

quarkus.management.header."header".value

The value for this header configuration

Environment variable: QUARKUS_MANAGEMENT_HEADER__HEADER__VALUE

string

required

quarkus.management.header."header".methods

The HTTP methods for this header configuration

Environment variable: QUARKUS_MANAGEMENT_HEADER__HEADER__METHODS

list of string

quarkus.management.filter."filter".matches

A regular expression for the paths matching this configuration

Environment variable: QUARKUS_MANAGEMENT_FILTER__FILTER__MATCHES

string

required

quarkus.management.filter."filter".header

Additional HTTP Headers always sent in the response

Environment variable: QUARKUS_MANAGEMENT_FILTER__FILTER__HEADER

Map<String,String>

quarkus.management.filter."filter".methods

The HTTP methods for this path configuration

Environment variable: QUARKUS_MANAGEMENT_FILTER__FILTER__METHODS

list of string

quarkus.management.filter."filter".order

Environment variable: QUARKUS_MANAGEMENT_FILTER__FILTER__ORDER

int
About the Duration format

The format for durations uses the standard java.time.Duration format. You can learn more about it in the Duration#parse() javadoc.

You can also provide duration values starting with a number. In this case, if the value consists only of a number, the converter treats the value as seconds. Otherwise, PT is implicitly prepended to the value to obtain a standard java.time.Duration format.
About the MemorySize format

A size configuration option recognises string in this format (shown as a regular expression): [0-9]+[KkMmGgTtPpEeZzYy]?. If no suffix is given, assume bytes.

7. Running behind a reverse proxy

Quarkus can be accessed through proxies that generate headers (e.g. X-Forwarded-Host) to preserve information about the original request. Quarkus can be configured to automatically update information like protocol, host, port and URI to use the values from those headers.

Activating this feature can expose the server to security issues like information spoofing. Activate it only when running behind a reverse proxy.

To set up this feature for the management interface, include the following lines in src/main/resources/application.properties:

quarkus.management.proxy.proxy-address-forwarding=true

To constrain this behavior to the standard Forwarded header (and ignore X-Forwarded variants) by setting quarkus.management.proxy.allow-forwarded in src/main/resources/application.properties:

quarkus.management.proxy.allow-forwarded=true

Alternatively, you can prefer X-Forwarded-* headers using the following configuration in src/main/resources/application.properties (note allow-x-forwarded instead of allow-forwarded):

quarkus.management.proxy.proxy-address-forwarding=true
quarkus.management.proxy.allow-x-forwarded=true
quarkus.management.proxy.enable-forwarded-host=true
quarkus.management.proxy.enable-forwarded-prefix=true

Supported forwarding address headers are:

  • Forwarded

  • X-Forwarded-Proto

  • X-Forwarded-Host

  • X-Forwarded-Port

  • X-Forwarded-Ssl

  • X-Forwarded-Prefix

If both header variants (Forwarded and X-Forwarded-*) are enabled, the Forwarded header will have precedence.

Using both Forwarded and X-Forwarded headers can have security implications as it may allow clients to forge requests with a header that is not overwritten by the proxy.

Ensure that your proxy is configured to strip unexpected Forwarded or X-Forwarded-* headers from the client request.

8. Kubernetes

When Quarkus generates the Kubernetes metadata, it checks if the management interface is enabled and configures the probes accordingly. The resulting descriptor defines the main HTTP port (named http) and the management port (named management). Health probes (using HTTP actions) and Prometheus scrape URLs are configured using the management port.

KNative

Until KNative#8471 is resolved, you cannot use the management interface, as KNative does not support containers will multiple exposed ports.

9. Security

You can enable basic authentication using the following properties:

quarkus.management.enabled=true
# Enable basic authentication
quarkus.management.auth.basic=true
# Require all access to /q/* to be authenticated
quarkus.management.auth.permission.all.policy=authenticated
quarkus.management.auth.permission.all.paths=/q/*

You can also use different permissions for different paths or use role bindings:

quarkus.management.enabled=true
# Enable basic authentication
quarkus.management.auth.basic=true
# Configure a management policy if needed, here the policy `management-policy` requires users to have the role `management`.
quarkus.management.auth.policy.management-policy.roles-allowed=management

# For each endpoint you can configure the permissions
# Health used the management-policy (so requires authentication + the `management` role)
quarkus.management.auth.permission.health.paths=/q/health/*
quarkus.management.auth.permission.health.policy=management-policy

# Metrics just requires authentication
quarkus.management.auth.permission.metrics.paths=/q/metrics/*
quarkus.management.auth.permission.metrics.policy=authenticated

More details about Basic authentication in Quarkus can be found in the Basic authentication guide.

Quarkus is open. All dependencies of this project are available under the Apache Software License 2.0 or compatible license.

This website was built with Jekyll, is hosted on GitHub Pages and is completely open source. If you want to make it better, fork the website and show us what you’ve got.

Navigation
Follow Us
Get Help
Languages
Quarkus is made of community projects
CC by 3.0 | Privacy Policy Sponsored by