Story (Required)

As a cluster administrator managing OpenShift Pipelines,
I want to separately control the creation of trusted CA configmaps and RBAC resources,
so that I can manage certificate injection and RBAC permissions independently and avoid unnecessary resource creation or duplication in namespaces, improving cluster scalability and resource efficiency.

Background (Required)

Currently, the createRbacResource flag in the TektonConfig disables the creation of both RBAC resources and trusted CA configmaps together. This tight coupling causes challenges for large clusters where many namespaces are managed, leading to inflated etcd size and resource overhead due to certificates being copied across all namespaces. Decoupling these two would allow operators to disable only configmap creation or only RBAC resources, tailoring resource management to their needs.

Out of scope

<Defines what is not included in this story>

Approach (Required)

• Introduce a new independent configuration flag (e.g., createTrustedCABundleConfigMap in TektonConfig CRD to control the creation of trusted CA configmaps.

• Refactor the reconciliation logic to conditionally create RBAC and configmaps based on separate flags.

• Maintain backward compatibility by defaulting the new flag to the current behavior (true if createRbacResource is true).

• Update CRD schema and documentation to reflect the new configuration option.

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