This document describes how to configure the database required for Tekton Results.
Currently, we only support connecting to external databases. This is because:
Version:
Database Setup:
Create Database Command:
Tekton Results supports using external PostgreSQL databases. The configuration is divided into two parts:
Field | Description | Default Value | Required |
---|---|---|---|
is_external_db | Whether to use external database | false | Yes (set to true for external DB) |
db_host | Database host address | localhost | Yes |
db_port | Database port | 5432 | Yes |
db_name | Database name | tekton-results | Yes |
db_sslmode | SSL connection mode | disable | No |
db_sslrootcert | SSL root certificate path | Empty | No (required when using SSL) |
db_secret_name | Secret name for database credentials | Empty | Yes |
The valid options for
db_sslmode
are explained here https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-PROTECTION.
For a basic external database setup without SSL, follow these steps:
Required Fields in Secret:
Field | Description | Example Value |
---|---|---|
POSTGRES_USER | Database username | result |
POSTGRES_PASSWORD | Database password | your_secure_password |
Create Secret Command:
Secret YAML Example:
This Quick Start covers basic configuration only. For production environments with SSL, advanced security, or custom CA certificates, see the Advanced Configuration section below.
When secure database connections are required, you can configure SSL-related parameters:
SSL Mode Selection Guide:
Environment | Recommended Mode | Security Level | Description |
---|---|---|---|
Development | disable | None | No encryption |
Testing | require | Basic | Encrypted connection |
Production | verify-full | Maximum | Encrypted + certificate validation |
SSL Mode Descriptions
sslmode | Eavesdropping protection | MITM protection | Statement |
---|---|---|---|
disable | No | No | I don't care about security, and I don't want to pay the overhead of encryption. |
allow | Maybe | No | I don't care about security, but I will pay the overhead of encryption if the server insists on it. |
prefer | Maybe | No | I don't care about encryption, but I wish to pay the overhead of encryption if the server supports it. |
require | Yes | No | I want my data to be encrypted, and I accept the overhead. I trust that the network will make sure I always connect to the server I want. |
verify-ca | Yes | Depends on CA policy | I want my data encrypted, and I accept the overhead. I want to be sure that I connect to a server that I trust. |
verify-full | Yes | Yes | I want my data encrypted, and I accept the overhead. I want to be sure that I connect to a server I trust, and that it's the one I specify. |
The difference between verify-ca and verify-full depends on the policy of the root CA. If a public CA is used, verify-ca allows connections to a server that somebody else may have registered with the CA. In this case, verify-full should always be used. If a local CA is used, or even a self-signed certificate, using verify-ca often provides enough protection.
Important: When using SSL modes require
, verify-ca
, or verify-full
, you must provide the CA certificate that signed the database server certificate. Without proper CA certificate configuration, the Tekton Results components will fail to start. See the Configuring Custom CA Certificates section below for detailed configuration steps.
When using SSL modes that require certificate validation (require
, verify-ca
, verify-full
), you need to provide the CA certificate that signed the database server certificate. The most common approach is to store the CA certificate in a ConfigMap and mount it to the Tekton Results pods.
If you have a CA certificate file named root.crt
, create a ConfigMap:
To make the CA certificate available in the containers, you need to configure the TektonResult resource with additional options
to mount the ConfigMap:
With this configuration:
/etc/tls/db/ca.crt
db_sslrootcert
to /etc/tls/db/ca.crt
to match the mounted pathAfter modifying the database configuration, you need to restart the Tekton Results components for the changes to take effect.
Option 1: Restart specific deployments
Option 2: Recreate the TektonResult resource
Verify the changes:
Connection refused:
Authentication failed:
SSL certificate errors:
Data Services
supports deploying PostgreSQL instances that can be used for Tekton Results. When creating a PostgreSQL instance, please consider the following important requirements:
When creating a PostgreSQL instance, a Secret containing connection information is automatically generated. This Secret resource can be filtered using the label middleware.instance/type: PostgreSQL
.
This Secret contains host
, port
, username
, password
information. You need to supplement database
and sslmode
(set to allow
or prefer
) information based on this Secret, and create a new secret in the namespace where the Tekton Results instance is located.
For more PostgreSQL deployment parameters and requirements, please refer to .