Skip to content

fix(EC-1977): migrate tenant-release SA to konflux-bot-0#3385

Open
robnester-rh wants to merge 1 commit into
conforma:mainfrom
robnester-rh:EC-1977
Open

fix(EC-1977): migrate tenant-release SA to konflux-bot-0#3385
robnester-rh wants to merge 1 commit into
conforma:mainfrom
robnester-rh:EC-1977

Conversation

@robnester-rh

Copy link
Copy Markdown
Contributor

Summary

Migrate the tenant-release ServiceAccount to the predefined konflux-bot-0 SA to comply with Konflux SA security policy. Deadline: July 30, 2026.

  • Remove SA definition (konflux-bot-0 is pre-created by Konflux)
  • Rename Role/RoleBinding from tenant-release to conforma-release
  • Update RoleBinding subject to reference konflux-bot-0
  • Document required secrets (ec-cli-main, ec-tekton-task-main) in comments

Dependencies

  • konflux-release-data MR (updates ReleasePlan serviceAccountName) should merge first
  • Secrets and RoleBinding for konflux-bot-0 must be configured in the cluster

Test plan

  • Verify konflux-bot-0 has correct secrets attached in cluster
  • Trigger a release and confirm the pipeline succeeds with the new SA
  • Verify old tenant-release SA can be safely deleted

🤖 Generated with Claude Code

@qodo-for-conforma

Copy link
Copy Markdown

PR Summary by Qodo

Migrate release RBAC to use pre-created konflux-bot-0 ServiceAccount

⚙️ Configuration changes 🕐 10-20 Minutes

Grey Divider

AI Description

• Remove the in-repo tenant-release ServiceAccount in favor of Konflux-managed konflux-bot-0.
• Rename release Role/RoleBinding to conforma-release and re-target binding to konflux-bot-0.
• Document required registry push secrets that must be attached to konflux-bot-0 in-cluster.
Diagram

graph TD
  A["release/setup.yaml"] --> B["Role (conforma-release)"] --> C["RoleBinding (conforma-release)"] --> D["ServiceAccount: konflux-bot-0"] --> E[("Registry push secrets")]
  D --> F["Release pipelines"]
  G{{"Konflux
(pre-creates SA)"}} --> D

  subgraph Legend
    direction LR
    _cfg["Config/Manifest"] ~~~ _rbac["RBAC"] ~~~ _sa["ServiceAccount"] ~~~ _sec[("Secret")] ~~~ _ext{{"External system"}}
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Request a dedicated Konflux-managed bot SA for releases
  • ➕ Keeps a distinct identity for release automation (least privilege, clearer audit trails).
  • ➕ Avoids coupling multiple use-cases to the shared konflux-bot-0 identity.
  • ➖ Requires platform/cluster coordination and lead time; may miss the policy deadline.
  • ➖ Still relies on Konflux conventions and cluster-side setup.
2. Keep `tenant-release` SA but enforce policy via admission/labels
  • ➕ Maintains existing RBAC wiring and SA identity with minimal downstream changes.
  • ➖ Conflicts with the stated Konflux SA security policy (likely rejected by enforcement).
  • ➖ Does not remove the operational burden of managing SA lifecycle and secrets in-repo.

Recommendation: Proceed with this PR’s approach: binding RBAC to the pre-created konflux-bot-0 aligns with the stated Konflux policy and minimizes in-repo identity management. Ensure the dependent ReleasePlan serviceAccountName change is merged first and validate that ec-cli-main and ec-tekton-task-main are attached to konflux-bot-0 in the target cluster before relying on the new binding.

Files changed (1) +13 / -17

Other (1) +13 / -17
setup.yamlRebind release RBAC from tenant-release SA to konflux-bot-0 +13/-17

Rebind release RBAC from tenant-release SA to konflux-bot-0

• Removes the repo-defined 'tenant-release' ServiceAccount and replaces it with documentation indicating 'konflux-bot-0' is pre-created by Konflux. Renames the Role/RoleBinding to 'conforma-release' and updates the RoleBinding subject to 'konflux-bot-0' while keeping the same roleRef semantics.

release/setup.yaml

@coderabbitai

coderabbitai Bot commented Jul 6, 2026

Copy link
Copy Markdown

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 665e8906-bc66-4337-aec7-398d701cd6fe

📥 Commits

Reviewing files that changed from the base of the PR and between f9863e9 and 8224517.

📒 Files selected for processing (2)
  • release/README.md
  • release/setup.yaml
✅ Files skipped from review due to trivial changes (1)
  • release/README.md
🚧 Files skipped from review as they are similar to previous changes (1)
  • release/setup.yaml

📝 Walkthrough

Walkthrough

The release setup manifest now documents and binds the pre-created konflux-bot-0 ServiceAccount instead of declaring tenant-release. The README setup instructions were updated to match the new release pipeline account setup.

Changes

Release pipeline account update

Layer / File(s) Summary
Manifest and RBAC subject update
release/setup.yaml
Removes the tenant-release ServiceAccount declaration, adds comments about konflux-bot-0 and required push secrets, and changes the RoleBinding subject to konflux-bot-0.
Setup documentation update
release/README.md
Revises the Release Pipeline setup text to describe setup.yaml as RBAC for the pipeline running under the pre-created konflux-bot-0 ServiceAccount.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Related PRs: None identified.

Suggested labels: release, configuration

Suggested reviewers: None identified.

Poem

A bunny hopped through YAML fields so neat,
Swapped one old account for one pre-built and sweet,
konflux-bot-0 now holds the key,
With docs and RBAC in harmony,
A tiny hop, a tidy feat! 🐇

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly states the ServiceAccount migration to konflux-bot-0, which matches the primary change.
Description check ✅ Passed The description discusses the same ServiceAccount migration and related RBAC/secret updates, so it is on-topic.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@qodo-for-conforma

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 27 rules

Grey Divider


Remediation recommended

1. Outdated setup README 🐞 Bug ⚙ Maintainability
Description
release/README.md still claims setup.yaml "creates a ServiceAccount", but the PR removes the
ServiceAccount manifest and instead assumes an externally pre-created konflux-bot-0 SA, which will
mislead operators following the setup docs.
Code

release/setup.yaml[R18-26]

+# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
+# and role binding below grant it push access to the release registries
+# and read access to release resources.
+#
+# The following secrets must be attached to konflux-bot-0 in the cluster:
+#   - ec-cli-main: push credential for quay.io/conforma/cli
+#     and quay.io/enterprise-contract/cli
+#   - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
+#     and quay.io/enterprise-contract/tekton-task
Relevance

⭐⭐⭐ High

Team historically updates docs when behavior/config changes (see docs alignment PRs 2600, 3093).

PR-#2600
PR-#3093

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The README explicitly says applying setup.yaml creates a ServiceAccount, while
release/setup.yaml now documents that konflux-bot-0 is pre-created and contains no
ServiceAccount object definition.

release/README.md[6-10]
release/setup.yaml[18-26]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The release setup documentation no longer matches what `release/setup.yaml` actually creates after migrating to `konflux-bot-0`.

### Issue Context
`release/setup.yaml` now only defines RBAC and comments about required secrets, and does not create a ServiceAccount.

### Fix Focus Areas
- release/README.md[6-10]
- release/setup.yaml[18-26]

### Suggested fix
Update `release/README.md` to state that `setup.yaml` creates the Role/RoleBinding for the pre-created `konflux-bot-0` ServiceAccount and that the listed secrets must already be attached to `konflux-bot-0` in the cluster.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Leading empty YAML 🐞 Bug ☼ Reliability
Description
release/setup.yaml now contains an initial YAML document consisting only of comments (started by a
leading --- and ended by the next ---), which can deserialize to an empty object and fail in
apply flows that expect apiVersion/kind per document.
Code

release/setup.yaml[R18-27]

+# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
+# and role binding below grant it push access to the release registries
+# and read access to release resources.
+#
+# The following secrets must be attached to konflux-bot-0 in the cluster:
+#   - ec-cli-main: push credential for quay.io/conforma/cli
+#     and quay.io/enterprise-contract/cli
+#   - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
+#     and quay.io/enterprise-contract/tekton-task
---
Relevance

⭐⭐ Medium

No prior repo review history found about rejecting/accepting empty YAML documents with leading '---'
comments.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The file begins with a --- and does not define any Kubernetes object until after a second ---,
meaning the first document contains only comments. The repo’s YAML apply helper unmarshals each
document into an Unstructured and then resolves a REST mapping from its GVK; an empty document has
no GVK and will fail that mapping step.

release/setup.yaml[1-28]
acceptance/kubernetes/kind/kind.go[331-351]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`release/setup.yaml` currently has two YAML document separators (`---`) with only comments in between, which creates an empty first YAML document. Some YAML consumers (including this repo’s apply helper) unmarshal each document and immediately use its GVK; empty docs will produce an object with no GVK and can error.

### Issue Context
This was introduced when the `ServiceAccount` manifest was removed but the original document structure (`---` separators) remained.

### Fix Focus Areas
- release/setup.yaml[1-28]

### Suggested fix
Remove the leading `---` at the very top of `release/setup.yaml` (or alternatively remove the separator at current line ~27) so the first YAML document contains a real Kubernetes object (Role) rather than only comments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Stale RBAC resources 🐞 Bug ⛨ Security
Description
Renaming the Role/RoleBinding from tenant-release to conforma-release means existing clusters
that previously applied this file will keep the old tenant-release Role/RoleBinding unless they
explicitly prune/delete them, leaving stale privileges behind.
Code

release/setup.yaml[R48-55]

+  name: conforma-release
  namespace: rhtap-contract-tenant
subjects:
  - kind: ServiceAccount
-    name: tenant-release
+    name: konflux-bot-0
roleRef:
  kind: Role
-  name: tenant-release
+  name: conforma-release
Relevance

⭐⭐ Medium

No historical evidence found on renamed K8s RBAC resources leaving stale objects in apply-only
flows.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The PR changes object names in release/setup.yaml, which causes new objects to be created rather
than updating existing ones with the old names. The repository’s apply helper demonstrates an
apply-only strategy (no deletion/pruning), so old objects would persist unless removed out-of-band.

release/setup.yaml[28-56]
acceptance/kubernetes/kind/kind.go[360-378]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Clusters that previously applied the old `tenant-release` RBAC will not automatically delete it when applying the new manifest, because apply flows update/create only the objects present in the YAML.

### Issue Context
This repo contains apply logic that uses server-side Apply per object and does not prune resources removed from manifests. Since the PR renames objects, the old ones will remain unless explicitly deleted.

### Fix Focus Areas
- release/README.md[6-10]
- acceptance/kubernetes/kind/kind.go[360-378]
- release/setup.yaml[28-56]

### Suggested fix
Document a migration step in `release/README.md` (or add a small `release/cleanup.yaml` plus instructions) to delete the legacy objects:
- `ServiceAccount/tenant-release`
- `Role/tenant-release`
- `RoleBinding/tenant-release`

Also mention that a prune-capable GitOps sync is required if relying on automated deletion.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

Comment thread release/setup.yaml
Comment on lines +18 to 27
# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
# and role binding below grant it push access to the release registries
# and read access to release resources.
#
# The following secrets must be attached to konflux-bot-0 in the cluster:
# - ec-cli-main: push credential for quay.io/conforma/cli
# and quay.io/enterprise-contract/cli
# - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
# and quay.io/enterprise-contract/tekton-task
---

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Leading empty yaml 🐞 Bug ☼ Reliability

release/setup.yaml now contains an initial YAML document consisting only of comments (started by a
leading --- and ended by the next ---), which can deserialize to an empty object and fail in
apply flows that expect apiVersion/kind per document.
Agent Prompt
### Issue description
`release/setup.yaml` currently has two YAML document separators (`---`) with only comments in between, which creates an empty first YAML document. Some YAML consumers (including this repo’s apply helper) unmarshal each document and immediately use its GVK; empty docs will produce an object with no GVK and can error.

### Issue Context
This was introduced when the `ServiceAccount` manifest was removed but the original document structure (`---` separators) remained.

### Fix Focus Areas
- release/setup.yaml[1-28]

### Suggested fix
Remove the leading `---` at the very top of `release/setup.yaml` (or alternatively remove the separator at current line ~27) so the first YAML document contains a real Kubernetes object (Role) rather than only comments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread release/setup.yaml
Comment on lines +18 to +26
# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
# and role binding below grant it push access to the release registries
# and read access to release resources.
#
# The following secrets must be attached to konflux-bot-0 in the cluster:
# - ec-cli-main: push credential for quay.io/conforma/cli
# and quay.io/enterprise-contract/cli
# - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
# and quay.io/enterprise-contract/tekton-task

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

2. Outdated setup readme 🐞 Bug ⚙ Maintainability

release/README.md still claims setup.yaml "creates a ServiceAccount", but the PR removes the
ServiceAccount manifest and instead assumes an externally pre-created konflux-bot-0 SA, which will
mislead operators following the setup docs.
Agent Prompt
### Issue description
The release setup documentation no longer matches what `release/setup.yaml` actually creates after migrating to `konflux-bot-0`.

### Issue Context
`release/setup.yaml` now only defines RBAC and comments about required secrets, and does not create a ServiceAccount.

### Fix Focus Areas
- release/README.md[6-10]
- release/setup.yaml[18-26]

### Suggested fix
Update `release/README.md` to state that `setup.yaml` creates the Role/RoleBinding for the pre-created `konflux-bot-0` ServiceAccount and that the listed secrets must already be attached to `konflux-bot-0` in the cluster.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread release/setup.yaml Outdated
@codecov

codecov Bot commented Jul 6, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag Coverage Δ
acceptance 53.44% <ø> (+<0.01%) ⬆️
generative 17.37% <ø> (ø)
integration 28.67% <ø> (ø)
unit 71.76% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Replace the tenant-release ServiceAccount with the predefined
konflux-bot-0 SA to comply with Konflux SA security policy.

- Remove SA definition (konflux-bot-0 is pre-created by Konflux)
- Update RoleBinding subject to reference konflux-bot-0
- Document required secrets in comments

resolves: EC-1977

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant