Redpanda Console Configuration

When you install Redpanda Console, a redpanda-console-config.yaml file is installed on each instance in /etc/redpanda/redpanda-console-config.yaml. This file contains configuration properties for Redpanda Console.

Configuration sources

Redpanda Console loads configuration properties from three sources, in the following order of precedence:

  • Environment variables

  • YAML configuration (recommended)

  • Command-line arguments

Environment variables and YAML configurations can overwrite input that is set on the command line.

YAML configuration

The recommended configuration source is a YAML file. Specify the path to the file by either setting the -config.filepath flag or setting the CONFIG_FILEPATH environment variable. A reference configuration file is provided under Redpanda Console configuration file.

Environment variables

Configuration options can be configured using environment variables. The key for the environment variable is auto-generated by converting the YAML equivalent to uppercase and adding an underscore for each indentation level. For example:

YAML Environment Variable

kafka.rackId

KAFKA_RACKID

kafka.tls.caFilepath

KAFKA_TLS_CAFILEPATH

For configuration properties that expect a list of values, use commas between each value. For example:

KAFKA_BROKERS=redpanda-0:9092,redpanda-1:9092,redpanda-2:9092
You cannot use environment variables to configure object arrays, such as the configuration for Kafka connect clusters. In this case, use a YAML file, and provide secrets using environment variables or command line arguments.

Redpanda Console configuration file

The following redpanda-console-config.yaml file contains a complete list of all Redpanda Console configuration properties and their descriptions. All values are default values.

Provide the filepath to your configuration file by setting either the -config.filepath flag or the CONFIG_FILEPATH environment variable.

  • Where necessary, ensure that values are enclosed in quotes and escaped. For example, put passwords with special characters in single quotes.

  • This configuration file contains both Redpanda Enterprise and Redpanda Community configurations. If you don’t provide an Enterprise license, Redpanda Console ignores configurations for enterprise features.

redpanda-console-config.yaml
#Commented config settings are optional and show the defaults
kafka:
  #Brokers is a list of bootstrap servers with
  #port (for example "localhost:9092").
  brokers:
    - broker-0.mycompany.com:19092
    - broker-1.mycompany.com:19092
    - broker-2.mycompany.com:19092
  # Client ID that the Kafka client can use to identify itself
  #against the target Kafka cluster.
  #clientId: console
  # In multi-zone Kafka clusters, you can reduce traffic costs
  # by consuming messages from replica brokers in the same zone.
  #rackId:
  # SASL configuration for Console to connect to the Kafka API.
  #sasl:
    #enabled: false
    #username:
    # Password can also be set using the --kafka.sasl.password flag.
    #password:
    # Valid mechanisms are: PLAIN, SCRAM-SHA-256,
    # SCRAM-SHA-512, GSSAPI, OAUTHBEARER and AWS_MSK_IAM.
    #mechanism: PLAIN
    # Kerberos implements the GSSAPI protocol. Use the following configurations
    # to connect Redpanda Console to a Kerberos-protected Kafka API.
    #gssapi:
      # AuthType must be either USER_AUTH or KEYTAB_AUTH
      #authType:
      # Filepath to the keytab file that contains the pairs of Kerberos
      # principals and encrypted password keys. AuthType must be set to
      # KEYTAB_AUTH to load the keytab file.
      #keyTabPath:
      # Path to the krb5.conf file that contains Kerberos configuration
      # information, such as the locations of KDCs.
      #kerberosConfigPath:
      #serviceName:
      #username:
      # Password can also be set using the --kafka.sasl.gssapi.password flag.
      #password:
      #realm:
      # Enables FAST, which is a pre-authentication framework
      # for Kerberos.
      #enableFast: true
    #oauth:
      # Token can also be set using the --kafka.sasl.oauth.token flag.
      #token:
    #awsMskIam:
      #accessKey:
      # secretKey can also be set using the --kafka.sasl.aws-msk-iam.secret-key flag.
      #secretKey:
      # sessionToken can also be set using the --kafka.sasl.aws-msk-iam.session-token flag.
      #sessionToken:
      #userAgent:
  #tls:
  # If you connect to a Cluster that uses commonly trusted
  # certificates, enable TLS and do not provide a certificate
  # authority in the caFilepath. In this case,
  # the system's certificate pool is used.
  #  enabled: false
    #caFilepath:
    #certFilepath:
    #keyFilepath:
    # Passphrase also be set using the --kafka.tls.passphrase flag.
    #passphrase:
    #insecureSkipTlsVerify: false
  #schemaRegistry:
    #enabled: false
    # Url with scheme is required, for example ["http://localhost:8081"].
    #urls: []
    # Basic auth username.
    #username:
    # Basic auth password. This can also be set using the --schema.registry.password flag.
    #password:
    # bearerToken can also be set using the --schema.registry.token flag.
    #bearerToken:
    #tls:
    # If you connect to a schema registry that uses commonly trusted
    # certificates, enable TLS and do not provide a certificate
    # authority in the caFilepath. In this case,
    # the system's cert pool is used.
      #enabled: false
      # Path to a custom CA file. If not specified the system/trusted root CA is used.
      #caFilepath:
      #certFilepath:
      # Key should not be encrypted by a passphrase.
      #keyFilepath:
      #insecureSkipTlsVerify: false
  #protobuf:
    #enabled: false
    #mappings: []
      # Map the Proto type names for each of your topics.
      # These Proto types will be used for deserialization.
      #- topicName: xy
       # You can specify the Proto type for the record key
       # and/or value (just one will work too)
       #valueProtoType: fake_model.Order
       #keyProtoType: package.Type
    # SchemaRegistry does not require any mappings to be specified.
    # The schema registry client configured on the Kafka level will be reused.
    #schemaRegistry:
      #enabled: false
      #refreshInterval: 5m
    # Configure the fileSystem if you want Redpanda Console to
    # search the local file system for the Proto files
    #fileSystem:
      #enabled: false
      #paths: []
      #refreshInterval: 5m
    # importPaths is a list of paths from which to import Proto files into Redpanda Console.
    # Paths are relative to the root directory.
    # The `git` configuration must be enabled to use this feature.
    #importPaths: []
    # Git is where the Proto files come from.
    #git:
      #enabled: false
      #repository:
        #url:
        #branch: (defaults to primary/default branch)
        #baseDirectory: (defaults to the root directory of the repo/branch above)
        # How often Redpanda Console pulls the repository to look for new files.
        # Set to 0 to disable periodic pulls.
        #refreshInterval: 5m
      # To use GitHub's personal access tokens, use `token`
      # as username and pass the token as password.
      #basicAuth:
        #enabled: true
        #username: token
        # Password can also be set using the via the --git.basic-auth.password flag.
        #password:
      # You can pass the private key file directly using a flag on the command line, or you can specify it in the
      # yaml configuration file. Another alternative is to provide the filepath to a mounted key
      # file in this configuration block.
      #ssh:
        #enabled: false
        #username:
        # privateKey can also be set using the --git.ssh.private-key flag.
        #privateKey:
        #privateKeyFilepath:
        # Passphrase can also be set using the --git.ssh.passphrase flag.
        #passphrase:
  #messagePack:
    #enabled: false
    # List of topic name regexes, defaults to /.*/
    #topicNames: ["/.*/"]
  # Startup is a configuration block to specify how often and with what delays
  # we should try to connect to the Kafka service. If all attempts have failed the
  # application will exit with code 1.
  #startup:
    #maxRetries: 5
    #retryInterval: 1s
    #maxRetryInterval 60s
    #backoffMultiplier: 2

#redpanda:
  # Redpanda Admin API configuration that enables additional Redpanda-specific features.
  #adminApi:
    #enabled: false
    # HTTP urls (such as http://localhost:9644) that Redpanda Console should send Admin API requests to.
    #urls: []
    #username: ""
    #password: ""
    #tls:
      #enabled: false
      #caFilepath: ""
      #certFilepath: ""
      #keyFilepath: ""

# To mount an Enterprise license, set either license or licenseFilepath.
# This is only required if you want to use an Enterprise feature
# such as SSO or RBAC.
# Filepath to your redpanda.license file
#licenseFilepath: ""
# License string.
#license: ""

# The enterprise block contains configurations for features that
# can only be used with a valid Redpanda Enterprise license.
#enterprise:
  #rbac:
    # Whether or not RBAC is used. This must be enabled
    # if login is enabled. By default, no authenticated user
    # has any permissions.
    #enabled: false
    # Path to YAML file that contains all role bindings
    #roleBindingsFilepath:

#connect:
  #enabled: false
  #The default for clusters is an empty array. To start Redpanda Console,
  #specify at least one cluster as soon as you enable Kafka connect.
  #clusters: []
    #- name: xy
      #url: http://my-cluster:8083
      #tls:
        # Trusted certificates are still allowed if TLS is not enabled.
        #enabled: false
        #caFilepath:
        #certFilepath:
        #keyFilepath:
        #insecureSkipTlsVerify: false
      #username:
      # Password can also be set using the --connect.clusters.i.password flag (i to be replaced with the array index).
      #password:
      # Token can also be set using the --connect.clusters.i.token flag (i to be replaced with the array index).
      #token:
  # Used to test cluster connectivity.
  #connectTimeout: 15s
  # Overall REST timeout.
  #readTimeout: 60s
  # Timeout for REST requests.
  #requestTimeout: 6s

#console:
  # Configuration to use for embedded topic documentation
  #topicDocumentation:
    #enabled: false
    # Configure the git repository that contains the topic documentation.
    # Redpanda Console clones the git repository and periodically pulls for new
    # changes so it can render the markdown files within the topic view.
    #git:
      #enabled: false
      #repository:
        #url:
        #branch: (defaults to primary/default branch)
        #baseDirectory: .
      # How often Console pulls the repository to look for new files.
      # Set to 0 to disable periodic pulls.
      #refreshInterval: 1m
      # To use GitHub's personal access tokens, use `token`
      # for the username and pass the token as password.
      #basicAuth:
        #enabled: true
        #username: token
        #password:
      #ssh:
        #enabled: false
        #username:
        #privateKey:
        #privateKeyFilepath:
        #passphrase:

# Login contains all configurations in order to protect Redpanda Console
# with a login screen. To support SSO, configure one or more of the identity
# providers below.
# This feature requires an Enterprise license.
#login:
  #enabled: false
  # jwtSecret is the secret key you must use to sign and encrypt the JSON
  # web token used to store user sessions. This secret key is
  # critical for the security of Redpanda Console's authentication and
  # authorization system. Use a long, complex key with a combination of
  # numbers, letters, and special characters. While you must use a minimum of
  # 10 characters, Redpanda recommends using more than 32
  # characters. For additional security, use a different secret key for
  # each environment. jwtSecret can be securely generated with the following
  # command: LC_ALL=C tr -dc '[:alnum:]' < /dev/random | head -c32
  #
  # If you update this secret key, any users who are
  # already logged into Redpanda Console will be logged out and will have
  # to log in again.
  #jwtSecret: ""
  # The "useSecureCookies" option controls the storage of session cookies in
  # Console. Enabling this option ensures that session cookies are stored
  # with the secure attribute, allowing them to be sent only over HTTPS.
  # If you are not using SSL in your environment, you must
  # disable this setting. However, it is strongly recommended that you do not disable
  # this option for security reasons. You should only disable this setting for
  # demonstration purposes, such as when using the plain login module.
  #useSecureCookies: true
  # Redpanda Console stores users' session data in cookies with no fixed size.
  # Because some browsers enforce a maximum size limit on cookies,
  # you can enable useCookieChunking to split a single big cookie into multiple
  # smaller ones. When you enable useCookieChunking, cookies are kept below 4KiB,
  # which is a maximum size limit set by most browsers.
  #useCookieChunking: false
  #google:
    #enabled: false
    #clientId: redacted.apps.googleusercontent.com
    #clientSecret: redacted
    # The directory configuration is only required if you use
    # Google groups in your RBAC role bindings.
    #directory:
      # Filepath to the mounted service account key file in JSON format.
      #serviceAccountFilepath: /etc/secrets/google-sa.json
      # targetPrincipal is the user that will be impersonated
      # for the Google Admin API calls.
      #targetPrincipal: admin@mycompany.com
  #keycloak:
      #enabled: true
      #url: https://keycloak.internal.company.com
      #realm:
      #clientId: ""
      #clientSecret: ""
      # The directory configuration is only required if you want to
      # use Keycloak groups in your role bindings.
      #directory:
        #adminUser: ""
        #adminPassword: ""
  #oidc:
    #enabled: false
    #clientId: redacted
    #clientSecret: redacted
    # IssuerUrl is the identity provider's URL; for example, https://accounts.google.com.
    # Redpanda Console will send a GET request to `${issuerUrl}/.well-known/openid-configuration`
    # and the `issuer` returned in the response has to match this issuer url.
    #issuerUrl: https://login.microsoftonline.com/your-uuid/v2.0
    # IssuerTLS is the TLS configuration used by the HTTP client to send requests
	  # to the IssuerURL. If you don't set any certificate paths, the IssuerTLS defaults to
    # the system cert pool.
    #issuerTls:
      #caFilepath:
      #certFilepath:
      #keyFilepath:
    #userIdentifyingClaimKey: sub
  #github:
    #enabled: false
    #clientId: redacted
    #clientSecret: redacted
    # The directory configuration is only required if you use
    # GitHub teams in your RBAC role bindings.
    #directory:
      #personalAccessToken: redacted
  #azureAd:
      #enabled: true
      # ProviderURL must be specified in the following format:
      # https://login.microsoftonline.com/{tenantId}/v2.0 .
      # To get this URL, browse to the registered app in your
      # Azure Portal and click the "Endpoints" tab. A drawer
      # opens with several links. The link below
      # "OpenID Connect metadata document" contains the
      # provider URL; however, you must remove the suffix
      # "/.well-known/openid-configuration" so that it
      # matches the expected format.
      #providerUrl: ""
      #clientId: ""
      #clientSecret: ""
      #  userIdentifyingClaimKey is only needed when you want
      #  to use a different claim key to identify users in the
      #  role binding. By default, Redpanda uses the 'oid' claim key,
      #  which resolves to the unique user ID within the identity
      #  provider. This means that you must provide the oid
      #  identifier in the roleBindings as 'name' as well.
      #  Other common options are:
      #  - upn (unique principal name - you need to add the upn
      #    claim as a claim for id tokens in your Azure AD application)
      #  - email (under certain conditions there's no value for
      #    the email propagated)
      #userIdentifyingClaimKey: "oid"
      # The directory configuration is only required if you want to use
      # Azure AD groups in your role bindings, as described
      # in the next section.
      # directory:
      #   tenantId: ""
  #okta:
    #enabled: false
    #clientId: redacted
    #clientSecret: redacted
    # The directory configuration is only required if you
    # use Okta groups in your RBAC role bindings.
    #directory:
      #apiToken: redacted
  #plain:
    #enabled: false
    #credentials:
      #- username: "jane"
        #password: "some-secret-password"

# Server configures Redpanda Console's HTTP server that serves all resources, including the Frontend application.
#server:
  #listenAddress:
  #listenPort: 8080
  # HTTPSListenPort and HTTPListenPort are separate so that we can listen
  # on both and redirect users to the HTTPS url.
  #httpsListenPort: 8081
  # AdvertisedHTTPSListenPort is the HTTPS port that will be used for
  # redirecting the user in the browser. If your application is serving
	# the TLS port on 8081 but some LoadBalancer between the user and your
  # Go application remaps this to 443 you want to set this port to
  # 443 as well. Otherwise, users will be redirected to your httpsListenPort.
  #advertisedHttpsListenPort:
  #gracefulShutdownTimeout: 30s
  #readTimeout: 30s
  #writeTimeout: 30s
  #idleTimeout: 30s
  #compressionLevel: 4
  # Sub-path under which Console is hosted. See https://docs.redpanda.com/current/manage/console/http-path-rewrites/ for more information
  #basePath:
  # Whether or not to check the 'X-Forwarded-Prefix' header to potentially override 'basePath'
  #setBasePathFromXForwardedPrefix: true
  #stripPrefix: true
  # TLS contains the configuration properties for the HTTP
  # TLS configuration. If enabled, the HTTP server will serve on
  # HTTPS and terminate TLS. Additional to the TLS server Console
  # will start an HTTP server that is in charge of redirecting HTTP
  # requests to the HTTPS version.
  #tls:
    #enabled: false
    #certFilepath:
    #keyFilepath:
  # AllowedOrigins is a list of origins that can send requests from a browser to the Console
  # API. By default, a same-site policy is enforced to prevent CSRF-attacks.
  # Only in specific deployment models you may need to change the secure default.
  #allowedOrigins: []

# Only relevant for developers, who might want to run the frontend separately.
#serveFrontend: true

# Prefix for all exported Prometheus metrics.
#metricsNamespace: console

#logger:
  # Valid values are: debug, info, warn, error, fatal.
  #level: info

# Analytics configures the telemetry service that sends anonymized usage statistics to Redpanda.
# Redpanda uses these statistics to evaluate feature usage.
#analytics:
  #enabled: true