Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 7. Required configuration fields

Red Hat Quay requires a minimal set of configuration fields to operator correctly. These fields define essential aspects of your deployment, such as how the registry is accessed, where image content is stored, how metadata is persisted, and how background services such as logs are managed.

The required configuration fields fall into five main categories:

  • General required configuration fields. Core fields such as the authentication type, URL scheme, server hostname, database secret key, and secret key are covered in this section.
  • Database configuration fields. Red Hat Quay requires a PostgreSQL relational database to store metadata about repositories, users, teams, and tags.
  • Object storage configuration fields. Object storage define the backend where container image blobs and manifests are stored. Your storage backend must be supported by Red Hat Quay, such as Ceph/RadosGW,AWS S3 storage, Google Cloud Storage, Nutanix, and so on.
  • Redis configuration fields. Redis is used as a backend for data such as push logs, user notifications, and other operations.

7.1. General required configuration fields

The following table describes the required configuration fields for a Red Hat Quay deployment:

Table 7.1. General required fields
FieldTypeDescription

AUTHENTICATION_TYPE
(Required)

String

The authentication engine to use for credential authentication.

Values:
One of Database, LDAP, JWT, Keystone, OIDC

Default: Database

PREFERRED_URL_SCHEME
(Required)

String

The URL scheme to use when accessing Red Hat Quay.

Values:
One of http, https

Default: http

SERVER_HOSTNAME
(Required)

String

The URL at which Red Hat Quay is accessible, without the scheme.

Example:
quay-server.example.com

DATABASE_SECRET_KEY
(Required)

String

Key used to encrypt sensitive fields within the database. This value should never be changed once set, otherwise all reliant fields, for example, repository mirror username and password configurations, are invalidated.
This value is set automatically by the Red Hat Quay Operator for Operator-based deployments. For standalone deployments, administrators can provide their own key using Open SSL or a similar tool. Key length should not exceed 63 characters.

SECRET_KEY
(Required)

String

Key used to encrypt the session cookie and the CSRF token needed for correct interpretation of the user session. The value should not be changed when set. Should be persistent across all Red Hat Quay instances. If not persistent across all instances, login failures and other errors related to session persistence might occur.

SETUP_COMPLETE
(Required)

Boolean

This is an artifact left over from earlier versions of the software and currently it must be specified with a value of true.

General required fields example

AUTHENTICATION_TYPE: Database
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: <quay-server.example.com>
SECRET_KEY: <secret_key_value>
DATABASE_SECRET_KEY: <database_secret_key_value>
SETUP_COMPLETE: true
# ...
Copy to Clipboard

7.2. Database configuration fields

This section describes the database configuration fields available for Red Hat Quay deployments.

7.2.1. Database URI

With Red Hat Quay, connection to the database is configured by using the required DB_URI field.

The following table describes the DB_URI configuration field:

Table 7.2. Database URI
FieldTypeDescription

DB_URI
(Required)

String

The URI for accessing the database, including any credentials.

Example DB_URI field:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

Database URI example

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
# ...
Copy to Clipboard

7.2.2. Database connection arguments

Optional connection arguments are configured by the DB_CONNECTION_ARGS parameter. Some of the key-value pairs defined under DB_CONNECTION_ARGS are generic, while others are database specific.

Table 7.3. Database connection arguments
FieldTypeDescription

DB_CONNECTION_ARGS

Object

Optional connection arguments for the database, such as timeouts and SSL/TLS.

.autorollback

Boolean

Whether to use thread-local connections.
Should always be true.

.threadlocals

Boolean

Whether to use auto-rollback connections.
Should always be true.

Database connection arguments example

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
# ...
Copy to Clipboard

7.2.2.1. SSL/TLS connection arguments

With SSL/TLS, configuration depends on the database you are deploying.

The sslmode option determines whether, or with, what priority a secure SSL/TLS TCP/IP connection will be negotiated with the server. There are six modes:

Table 7.4. sslmode options
ModeDescription

sslmode

Determines whether, or with, what priority a secure SSL/TLS or TCP/IP connection is negotiated with the server.

   *: disable

Your configuration only tries non-SSL/TLS connections.

   *: allow

Your configuration first tries a non-SSL/TLS connection. Upon failure, tries an SSL/TLS connection.

   *: prefer
    (Default)

Your configuration first tries an SSL/TLS connection. Upon failure, tries a non-SSL/TLS connection.

   *: require

Your configuration only tries an SSL/TLS connection. If a root CA file is present, it verifies the certificate in the same way as if verify-ca was specified.

   *: verify-ca

Your configuration only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted certificate authority (CA).

   *: verify-full

Only tries an SSL/TLS connection, and verifies that the server certificate is issued by a trusted CA and that the requested server hostname matches that in the certificate.

For more information on the valid arguments for PostgreSQL, see Database Connection Control Functions.

PostgreSQL SSL/TLS configuration

# ...
DB_CONNECTION_ARGS:
  sslmode: <value>
  sslrootcert: path/to/.postgresql/root.crt
# ...
Copy to Clipboard

7.3. Storage object configuration fields

Storage fields define the backend where container image blobs and manifests are stored. The following storage providers are supported by Red Hat Quay:

  • Amazon Web Services (AWS) S3
  • AWS STS S3 (Security Token Service)
  • AWS CloudFront (CloudFront S3Storage)
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • Swift Storage
  • Nutanix Object Storage
  • IBM Cloud Object Storage
  • NetApp ONTAP S3 Object Storage
  • Hitachi Content Platform (HCP) Object Storage
Note

Many of the supported storage providers use the RadosGWStorage driver due to their S3-compatible APIs.

7.3.1. Storage configuration fields

The following table describes the storage configuration fields for Red Hat Quay. These fields are required when configuring backend storage.

Table 7.5. Storage configuration fields
FieldTypeDescription

DISTRIBUTED_STORAGE_CONFIG
(Required)

Object

Configuration for storage engine(s) to use in Red Hat Quay. Each key represents an unique identifier for a storage engine. The value consists of a tuple of (key, value) forming an object describing the storage engine parameters.

Default: []

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS
(Required)

Array of string

The list of storage engine(s) (by ID in DISTRIBUTED_STORAGE_CONFIG) whose images should be fully replicated, by default, to all other storage engines.

DISTRIBUTED_STORAGE_PREFERENCE
(Required)

Array of string

The preferred storage engine(s) (by ID in DISTRIBUTED_STORAGE_CONFIG) to use. A preferred engine means it is first checked for pulling and images are pushed to it.

Default: false

MAXIMUM_LAYER_SIZE
(Optional)

String

Maximum allowed size of an image layer.

Pattern: ^[0-9]+(G|M)$

Example: 100G

Default: 20G

Storage configuration example

DISTRIBUTED_STORAGE_CONFIG:
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
MAXIMUM_LAYER_SIZE: 100G
Copy to Clipboard

7.3.2. Local storage

The following YAML shows an example configuration using local storage.

Important

Only use local storage when deploying a registry for proof of concept purposes. It is not intended for production purposes. When using local storage, you must map the registry to a local directory to the datastorage path in the container when starting the registry. For more information, see Proof of Concept - Deploying Red Hat Quay

Local storage example

DISTRIBUTED_STORAGE_CONFIG:
  default:
    - LocalStorage
    - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
Copy to Clipboard

7.3.3. Red Hat OpenShift Data Foundation

The following YAML shows a sample configuration using an Red Hat OpenShift Data Foundation: 

DISTRIBUTED_STORAGE_CONFIG:
  rhocsStorage:
    - RHOCSStorage
    - access_key: <access_key_here>
      secret_key: <secret_key_here>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100
1 

      server_side_assembly: true
2
Copy to Clipboard
1
Defines the maximum chunk size, in MB, for the final copy. Has no effect if server_side_assembly is set to false.
2
Optional. Whether Red Hat Quay should try and use server side assembly and the final chunked copy instead of client assembly. Defaults to true.

7.3.4. Ceph Object Gateway (RadosGW) storage example

Red Hat Quay supports using Ceph Object Gateway (RadosGW) as an object storage backend. RadosGW is a component of Red Hat Ceph Storage, which is a storage platform engineered for private architecture. Red Hat Ceph Storage provides an S3-compatible REST API for interacting with Ceph.

Note

RadosGW is an on-premise S3-compatible storage solution. It implements the S3 API and requires the same authentication fields, such as access_key, secret_key, and bucket_name. For more information about Ceph Object Gateway and the S3 API, see Ceph Object Gateway.

The following YAML shows an example configuration using RadosGW.

RadosGW with general s3 access example

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage:
1 

    - RadosGWStorage
    - access_key: <access_key_here>
      bucket_name: <bucket_name_here>
      hostname: <hostname_here>
      is_secure: true
      port: '443'
      secret_key: <secret_key_here>
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100
2 

      server_side_assembly: true
3
Copy to Clipboard

1
Used for general s3 access. Note that general s3 access is not strictly limited to Amazon Web Services (AWS) s3, and can be used with RadosGW or other storage services. For an example of general s3 access using the AWS S3 driver, see "AWS S3 storage".
2
Optional. Defines the maximum chunk size in MB for the final copy. Has no effect if server_side_assembly is set to false.
3
Optional. Whether Red Hat Quay should try and use server side assembly and the final chunked copy instead of client assembly. Defaults to true.

7.3.5. Supported AWS storage backends

Red Hat Quay supports multiple Amazon Web Services (AWS) storage backends:

  • S3 storage: Standard support for AWS S3 buckets that uses AWS’s native object storage service.
  • STS S3 storage: Support for AWS Security Token Service (STS) to assume IAM roles, allowing for more secure S3 operations.
  • CloudFront S3 storage: Integrates with AWS CloudFront to enable high-availability distribution of content while still using AWS S3 as the origin.

The following sections provide example YAMLs and additional information about each AWS storage backend.

7.3.5.1. Amazon Web Services S3 storage

Red Hat Quay supports using AWS S3 as an object storage backend. AWS S3 is an object storage service designed for data availability, scalability, security, and performance. The following YAML shows an example configuration using AWS S3.

AWS S3 example

# ...
DISTRIBUTED_STORAGE_CONFIG:
  default:
    - S3Storage
1 

    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      s3_region: <region>
2 

      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...
Copy to Clipboard

1
The S3Storage storage driver should only be used for AWS S3 buckets. Note that this differs from general S3 access, where the RadosGW driver or other storage services can be used. For an example, see "Example B: Using RadosGW with general S3 access".
2
Optional. The Amazon Web Services region. Defaults to us-east-1.

7.3.5.2. Amazon Web Services STS S3 storage

AWS Security Token Service (STS) provides temporary, limited-privilege credentials for accessing AWS resources, improving security by avoiding the need to store long-term access keys. This is useful in environments such as OpenShift Container Platform where credentials can be rotated or managed through IAM roles.

The following YAML shows an example configuration for using AWS STS with Red Hat Quay on OpenShift Container Platform configurations.

AWS STS S3 storage example

# ...
DISTRIBUTED_STORAGE_CONFIG:
   default:
    - STSS3Storage
    - sts_role_arn: <role_arn>
1 

      s3_bucket: <s3_bucket_name>
      storage_path: <storage_path>
      sts_user_access_key: <s3_user_access_key>
2 

      sts_user_secret_key: <s3_user_secret_key>
3 

      s3_region: <region>
4 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...
Copy to Clipboard

1
The unique Amazon Resource Name (ARN).
2
The generated AWS S3 user access key.
3
The generated AWS S3 user secret key.
4
Optional. The Amazon Web Services region. Defaults to us-east-1.

7.3.5.3. AWS CloudFront storage

AWS CloudFront is a content delivery network (CDN) service that caches and distributes content closer to users for improved performance and lower latency. Red Hat Quay supports CloudFront through the CloudFrontedS3Storage driver, which enables secure, signed access to S3 buckets via CloudFront distributions.

Use the following example when configuring AWS CloudFront for your Red Hat Quay deployment.

Note

  • When configuring AWS Cloudfront storage, the following conditions must be met for proper use with Red Hat Quay:

    • You must set an Origin path that is consistent with Red Hat Quay’s storage path as defined in your config.yaml file. Failure to meet this require results in a 403 error when pulling an image. For more information, see Origin path.
    • You must configure a Bucket policy and a Cross-origin resource sharing (CORS) policy.

Cloudfront S3 example YAML

DISTRIBUTED_STORAGE_CONFIG:
    default:
      - CloudFrontedS3Storage
      - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN>
        cloudfront_key_id: <CLOUDFRONT_KEY_ID>
        cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME>
        host: <S3_HOST>
        s3_access_key: <S3_ACCESS_KEY>
        s3_bucket: <S3_BUCKET_NAME>
        s3_secret_key: <S3_SECRET_KEY>
        storage_path: <STORAGE_PATH>
        s3_region: <S3_REGION>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - default
DISTRIBUTED_STORAGE_PREFERENCE:
  - default
Copy to Clipboard

Bucket policy example

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
1
2 

            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*"
3 

        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
4
5 

            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
        }
    ]
}
Copy to Clipboard

1 4
The identifier, or account ID, of the AWS account that owns the CloudFront OAI and S3 bucket.
2 5
The CloudFront Origin Access Identity (OAI) that accesses the S3 bucket.
3
Specifies that CloudFront can access all objects (/*) inside of the S3 bucket.

7.3.6. Google Cloud Storage

Red Hat Quay supports using Google Cloud Storage (GCS) as an object storage backend. When used with Red Hat Quay, it provides a cloud-native solution for storing container images and artifacts.

The following YAML shows a sample configuration using Google Cloud Storage.

Google Cloud Storage example

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
          boto_timeout: 120
1 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage
Copy to Clipboard

1
Optional. The time, in seconds, until a timeout exception is thrown when attempting to read from a connection. The default is 60 seconds. Also encompasses the time, in seconds, until a timeout exception is thrown when attempting to make a connection. The default is 60 seconds.

7.3.7. Microsoft Azure Blob Storage

Red Hat Quay supports using Microsoft Azure Blob Storage as an object storage backend. Azure Blob Storage can be used to persist container images, metadata, and other artifacts in a secure and cloud-native manner.

The following YAML shows a sample configuration using Azure Storage.

Microsoft Azure Blob Storage example

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: <azure_account_name>
      azure_container: <azure_container_name>
      storage_path: /datastorage/registry
      azure_account_key: <azure_account_key>
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net
1 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
Copy to Clipboard

1
The endpoint_url parameter for Azure storage is optional and can be used with Microsoft Azure Government (MAG) endpoints. If left blank, the endpoint_url will connect to the normal Azure region.

As of Red Hat Quay 3.7, you must use the Primary endpoint of your MAG Blob service. Using the Secondary endpoint of your MAG Blob service will result in the following error: AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary.

7.3.8. Swift object storage

Red Hat Quay supports using Red Hat OpenStack Platform (RHOSP) Object Storage service, or Swift, as an object storage backend. Swift offers S3-like functionality with its own API and authentication mechanisms.

The following YAML shows a sample configuration using Swift storage.

Swift object storage example

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: <swift_username>
      swift_password: <swift_password>
      swift_container: <swift_container>
      auth_url: https://example.org/swift/v1/quay
      auth_version: 3
      os_options:
        tenant_id: <osp_tenant_id>
        user_domain_name: <osp_domain_name>
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage
Copy to Clipboard

7.3.9. Nutanix Objects Storage

Red Hat Quay supports Nutanix Objects Storage as an object storage backend. Nutanix Object Storage is suitable for organizations running private cloud infrastructure using Nutanix.

The following YAML shows a sample configuration using Nutanix Object Storage.

Nutanix Objects Storage example

DISTRIBUTED_STORAGE_CONFIG:
  nutanixStorage: # storage config name
    - RadosGWStorage # actual driver
    - access_key: <access_key>
      secret_key: <secret_key>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: # must contain name of the storage config
    - nutanixStorage
Copy to Clipboard

7.3.10. IBM Cloud Object Storage

Red Hat Quay supports IBM Cloud Object Storage as an object storage backend. IBM Cloud Object Storage is suitable for cloud-native applications requiring scalable and secure storage on IBM Cloud.

The following YAML shows a sample configuration using IBM Cloud Object Storage.

IBM Cloud Object Storage

DISTRIBUTED_STORAGE_CONFIG:
  default:
  - IBMCloudStorage # actual driver
  - access_key: <access_key> # parameters
    secret_key: <secret_key>
    bucket_name: <bucket_name>
    hostname: <hostname>
    is_secure: 'true'
    port: '443'
    storage_path: /datastorage/registry
    maximum_chunk_size_mb: 100mb
1 

    minimum_chunk_size_mb: 5mb
2 

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- default
DISTRIBUTED_STORAGE_PREFERENCE:
- default
Copy to Clipboard

1
Optional. Recommended to be set to 100mb.
2
Optional. Defaults to 5mb. Do not adjust this field without consulting Red  Support, because it can have unintended consequences.

7.3.11. NetApp ONTAP S3 object storage

Red Hat Quay supports using NetApp ONTAP S3 as an object storage backend.

The following YAML shows a sample configuration using NetApp ONTAP S3.

Netapp ONTAP S3 example

DISTRIBUTED_STORAGE_CONFIG:
  local_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <host_url_address>
    is_secure: true
    port: <port>
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- local_us
DISTRIBUTED_STORAGE_PREFERENCE:
- local_us
Copy to Clipboard

7.3.12. Hitachi Content Platform object storage

Red Hat Quay supports using Hitachi Content Platform (HCP) as an object storage backend.

The following YAML shows a sample configuration using HCP for object storage.

HCP storage configuration example

DISTRIBUTED_STORAGE_CONFIG:
  hcp_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <hitachi_hostname_example>
    is_secure: true
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- hcp_us
DISTRIBUTED_STORAGE_PREFERENCE:
- hcp_us
Copy to Clipboard

7.4. Redis configuration fields

Redis is used by Red Hat Quay to support backend tasks and services, such as build triggers and notifications. There are configuration types related to Redis: build logs and user events. The following sections detail the configuration fields available for each type.

7.4.1. Build logs

Build logs are generated during the image build process and provide insights for debugging and auditing. Red Hat Quay uses Redis to temporarily store these logs before they are accessed through the user interface or API.

The following build logs configuration fields are available for Redis deployments.

Table 7.6. Build logs configuration fields
FieldTypeDescription

BUILDLOGS_REDIS
(Required)

Object

Redis connection details for build logs caching.

.host
(Required)

String

The hostname at which Redis is accessible.
Example:
quay-server.example.com

.port
(Required)

Number

The port at which Redis is accessible.
Example:
6379

.password

String

The password to connect to the Redis instance.
Example:
strongpassword

.ssl
(Optional)

Boolean

Whether to enable TLS communication between Redis and Quay. Defaults to false.

Build logs configuration example

# ...
BUILDLOGS_REDIS:
  host: <quay-server.example.com>
  password: <example_password>
  port: 6379
1 

  ssl: true
2 

# ...
Copy to Clipboard

1 2
If your deployment uses Azure Cache for Redis and ssl is set to true, the port defaults to 6380.

7.4.2. User events

User events track activity across Red Hat Quay, such as repository pushes, tag creations, deletions, and permission changes. These events are recorded in Redis as part of the activity stream and can be accessed through the API or web interface.

The following user event fields are available for Redis deployments.

Table 7.7. User events config
FieldTypeDescription

USER_EVENTS_REDIS
(Required)

Object

Redis connection details for user event handling.

.host
(Required)

String

The hostname at which Redis is accessible.
Example:
quay-server.example.com

.port
(Required)

Number

The port at which Redis is accessible.
Example:
6379

.password

String

The password to connect to the Redis instance.
Example:
strongpassword

.ssl

Boolean

Whether to enable TLS communication between Redis and Quay. Defaults to false.

.ssl_keyfile
(Optional)

String

The name of the key database file, which houses the client certificate to be used.
Example:
ssl_keyfile: /path/to/server/privatekey.pem

.ssl_certfile
(Optional)

String

Used for specifying the file path of the SSL certificate.
Example:
ssl_certfile: /path/to/server/certificate.pem

.ssl_cert_reqs
(Optional)

String

Used to specify the level of certificate validation to be performed during the SSL/TLS handshake.
Example:
ssl_cert_reqs: CERT_REQUIRED

.ssl_ca_certs
(Optional)

String

Used to specify the path to a file containing a list of trusted Certificate Authority (CA) certificates.
Example:
ssl_ca_certs: /path/to/ca_certs.pem

.ssl_ca_data
(Optional)

String

Used to specify a string containing the trusted CA certificates in PEM format.
Example:
ssl_ca_data: <certificate>

.ssl_check_hostname
(Optional)

Boolean

Used when setting up an SSL/TLS connection to a server. It specifies whether the client should check that the hostname in the server’s SSL/TLS certificate matches the hostname of the server it is connecting to.
Example:
ssl_check_hostname: true

Redis user events example

# ...
USER_EVENTS_REDIS:
  host: <quay-redis.example.com>
  port: 6379
  password: <example_password>
  ssl: true
  ssl_keyfile: /etc/ssl/private/redis-client.key
  ssl_certfile: /etc/ssl/certs/redis-client.crt
  ssl_cert_reqs: <required_certificate>
  ssl_ca_certs: /etc/ssl/certs/ca-bundle.crt
  ssl_check_hostname: true
# ...
Copy to Clipboard

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat