Story (Required)

As a Platform Security Engineer trying to ensure secure-by-default deployments, I want to remediate critical security risks in Tekton Results configuration so that sensitive data is protected in transit and at rest, and the platform is compliant with security best practices.This will improve the customer’s experience by reducing the risk of data breaches, credential exposure, and non-compliance with organizational and regulatory security standards.

Background (Required)

Recent analysis of the Tekton Results component’s default configuration revealed several critical security risks:

• DB_SSLMODE is set to disable, meaning database connections are unencrypted and credentials/data can be intercepted.

• LOGGING_PLUGIN_TLS_VERIFICATION_DISABLE can be enabled, which would disable TLS certificate verification for log forwarding, exposing the system to man-in-the-middle attacks.

• S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY are stored in plaintext in configuration, risking credential leakage.

These insecure defaults could lead to credential theft, unauthorized data access, and regulatory non-compliance.

Out of scope

• Refactoring of unrelated Tekton components (e.g., Pipelines, Chains, Triggers).

• Migration of existing secrets to a new secret management system.

• Changes to non-critical or medium/low risk configuration parameters.

Approach (Required)

• Update the default value of DB_SSLMODE to true in all relevant places and documentation.

• Enforce that LOGGING_PLUGIN_TLS_VERIFICATION_DISABLE cannot be enabled in production environments; add validation or remove the option if possible.

• Remove plaintext storage of S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY from configuration files. Instead, integrate with Kubernetes Secrets or cloud-native secret management (e.g., AWS IAM roles, GCP Workload Identity).

• Update Helm charts, Operator manifests, and documentation to reflect these changes.

• Add validation logic (where possible) to prevent insecure values from being set.

• Provide migration guidance for existing users.

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met