Added labels support for ci-secret-bootstrap#5189
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Vault-driven secret labels: a new exported Vault key, proxy validation skip for that key, parsing/validation and application of labels in ci-secret-bootstrap (including reserved-key handling), and update-on-label-drift for managed Secrets. go.mod dependency versions are also updated. ChangesSecret sync target labels support
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 11 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hector-vido The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cmd/ci-secret-bootstrap/main.go`:
- Around line 674-680: User-provided labels parsed from
secretKeys[vaultapi.SecretSyncTargetLabelsKey] can overwrite the seeded
controller label api.DPTPRequesterLabel in the labels map; update the parsing
logic (the block that builds labels from vaultValue in
cmd/ci-secret-bootstrap/main.go) to reject or ignore any entry whose key equals
api.DPTPRequesterLabel so the initially-seeded labels map entry is never
replaced (ensure the same behavior is enforced before updateSecrets is called).
- Around line 675-680: The current Vault label parsing loop can panic on
malformed entries; update the block that handles
secretKeys[vaultapi.SecretSyncTargetLabelsKey] (variables vaultValue and labels)
to robustly parse each label: use strings.SplitN(entry, ":", 2),
strings.TrimSpace on both key and value, validate that you got exactly 2
non-empty parts, and either skip invalid entries or return a contextual error
(with which entry failed) instead of letting label[1] panic; ensure the final
parsed key/value are stored into labels only after trimming and validation.
In `@cmd/vault-subpath-proxy/kv_update_transport.go`:
- Around line 125-126: The branch only updated the regex but you must treat
SecretSyncTargetLabelsKey as a reserved key throughout this transport: update
validateKeysDontConflict to ignore vault.SecretSyncTargetLabelsKey when checking
for claimed keys, change syncSecret so it does not include
vault.SecretSyncTargetLabelsKey in Secret.Data or write it as normal secret
data, and update any cache builder routines that enumerate keys (e.g., functions
building the local cache or mapping keys to clusters) to skip
vault.SecretSyncTargetLabelsKey so it is never persisted or compared in conflict
checks; keep the same logic/guard used for vault.SecretSyncTargetClusterKey for
consistency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 1b2b4634-8cfc-4261-99af-ce14c9e57856
📒 Files selected for processing (3)
cmd/ci-secret-bootstrap/main.gocmd/vault-subpath-proxy/kv_update_transport.gopkg/api/vault/vault.go
| if key == vault.SecretSyncTargetClusterKey || key == vault.SecretSyncTargetLabelsKey { | ||
| continue |
There was a problem hiding this comment.
Treat SecretSyncTargetLabelsKey as reserved everywhere in this transport.
This branch only fixes the regex check. validateKeysDontConflict and syncSecret still treat the new key as normal secret data, so a Vault write can both raise false "key ... is already claimed" conflicts and persist secretsync/target-labels into Secret.Data. Please extend the same reserved-key handling there as well, and keep the cache builders aligned too.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@cmd/vault-subpath-proxy/kv_update_transport.go` around lines 125 - 126, The
branch only updated the regex but you must treat SecretSyncTargetLabelsKey as a
reserved key throughout this transport: update validateKeysDontConflict to
ignore vault.SecretSyncTargetLabelsKey when checking for claimed keys, change
syncSecret so it does not include vault.SecretSyncTargetLabelsKey in Secret.Data
or write it as normal secret data, and update any cache builder routines that
enumerate keys (e.g., functions building the local cache or mapping keys to
clusters) to skip vault.SecretSyncTargetLabelsKey so it is never persisted or
compared in conflict checks; keep the same logic/guard used for
vault.SecretSyncTargetClusterKey for consistency.
hector-vido
force-pushed
the
labels-support-secret-bootstrap
branch
from
f93da75 to
ff9898d
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@go.mod`:
- Line 5: The go.mod replace directive downgrades github.com/docker/distribution
to v2.7.1, reintroducing known vulnerabilities; remove or update that replace
entry so the project uses v2.8.3 or newer (i.e., delete or change the line
"replace github.com/docker/distribution => github.com/docker/distribution
v2.7.1+incompatible" to omit the replace or point to v2.8.3+incompatible), then
run go mod tidy to ensure module graph is refreshed and the secure version is
used.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 92bacdb6-52c2-4727-b315-c5086234b321
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum,!go.sum
📒 Files selected for processing (4)
cmd/ci-secret-bootstrap/main.gocmd/vault-subpath-proxy/kv_update_transport.gogo.modpkg/api/vault/vault.go
🚧 Files skipped from review as they are similar to previous changes (3)
- pkg/api/vault/vault.go
- cmd/vault-subpath-proxy/kv_update_transport.go
- cmd/ci-secret-bootstrap/main.go
| go 1.25.8 | ||
| go 1.26.0 | ||
|
|
||
| replace github.com/docker/distribution => github.com/docker/distribution v2.7.1+incompatible |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for security advisories on docker/distribution v2.7.1
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "github.com/docker/distribution") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: openshift/ci-tools
Length of output: 801
Remove the docker/distribution downgrade to v2.7.1 — it reintroduces known security vulnerabilities.
The replace directive downgrades from v2.8.3 to v2.7.1, reintroducing at least two documented vulnerabilities:
- HIGH: Distribution catalog API endpoint can lead to OOM via malicious user input (published 2023-05-11, patched in 2.8.2-beta.1)
- LOW: OCI Manifest Type Confusion Issue (published 2022-02-08, patched in 2.8.0)
Keep the required version v2.8.3 or remove the replace directive entirely.
🧰 Tools
🪛 OSV Scanner (2.3.8)
[HIGH] 5-5: github.com/docker/distribution 2.7.1+incompatible: Type confusion in github.com/docker/distribution
(GO-2022-0379)
[HIGH] 5-5: github.com/docker/distribution 2.7.1+incompatible: distribution catalog API endpoint can lead to OOM via malicious user input
[HIGH] 5-5: github.com/docker/distribution 2.7.1+incompatible: OCI Manifest Type Confusion Issue
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@go.mod` at line 5, The go.mod replace directive downgrades
github.com/docker/distribution to v2.7.1, reintroducing known vulnerabilities;
remove or update that replace entry so the project uses v2.8.3 or newer (i.e.,
delete or change the line "replace github.com/docker/distribution =>
github.com/docker/distribution v2.7.1+incompatible" to omit the replace or point
to v2.8.3+incompatible), then run go mod tidy to ensure module graph is
refreshed and the secure version is used.
ff9898d to
05c4a78
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@go.mod`:
- Line 157: Update the pinned indirect dependency k8s.io/kubernetes in go.mod to
a patched 1.29.x release (at least v1.29.7) to eliminate CVE-2024-10220 and
CVE-2024-5321; open go.mod, replace the existing k8s.io/kubernetes v1.29.2 entry
with v1.29.7 (or later) and run go get k8s.io/kubernetes@v1.29.7 followed by go
mod tidy to update the lock file, or if the package is unnecessary remove the
k8s.io/kubernetes line and run go mod tidy to prune it from the module graph.
- Line 59: The go.mod currently pins k8s.io/apimachinery to v0.35.5 while other
Kubernetes modules (k8s.io/api, k8s.io/apiserver, k8s.io/client-go) remain at
v0.32.8 causing API/type/protobuf skew; update the Kubernetes module versions so
their minor versions match (e.g., set k8s.io/apimachinery to v0.32.x to match
k8s.io/api, k8s.io/apiserver, k8s.io/client-go or bump all peers to the same
v0.35.x), then run go get / go mod tidy to resolve transitive deps and ensure
builds pass — target the same minor for k8s.io/apimachinery, k8s.io/api,
k8s.io/apiserver, and k8s.io/client-go.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: c20093fc-2c29-482d-a2d6-827116a19025
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum,!go.sum
📒 Files selected for processing (4)
cmd/ci-secret-bootstrap/main.gocmd/vault-subpath-proxy/kv_update_transport.gogo.modpkg/api/vault/vault.go
🚧 Files skipped from review as they are similar to previous changes (3)
- cmd/vault-subpath-proxy/kv_update_transport.go
- pkg/api/vault/vault.go
- cmd/ci-secret-bootstrap/main.go
| k8s.io/kube-openapi v0.0.0-20241212222426-2c72e554b1e7 // indirect | ||
| k8s.io/kubernetes v1.29.2 | ||
| k8s.io/kube-openapi v0.0.0-20250910181357-589584f1c912 // indirect | ||
| k8s.io/kubernetes v1.29.2 // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Query OSV for known vulnerabilities on k8s.io/kubernetes v1.29.2
curl -s https://api.osv.dev/v1/query -H 'Content-Type: application/json' -d '{
"package": {"name": "k8s.io/kubernetes", "ecosystem": "Go"},
"version": "1.29.2"
}' | jq .Repository: openshift/ci-tools
Length of output: 50374
Pin k8s.io/kubernetes to a patched version to resolve HIGH severity vulnerabilities.
Version 1.29.2 contains at least two HIGH severity vulnerabilities: CVE-2024-10220 (kubelet arbitrary command execution) and CVE-2024-5321 (incorrect Windows container log permissions). Upgrade to 1.29.7 or later in the 1.29.x series to address these issues, or remove if unnecessary for the module graph.
🧰 Tools
🪛 OSV Scanner (2.3.8)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes allows bypassing mountable secrets policy imposed by the ServiceAccount admission plugin in k8s.io/kubernetes
(GO-2024-2746)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes sets incorrect permissions on Windows containers logs in k8s.io/kubernetes
(GO-2024-2994)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes kubelet arbitrary command execution in k8s.io/kubernetes
(GO-2024-3286)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Node Denial of Service via kubelet Checkpoint API in k8s.io/kubernetes
(GO-2025-3465)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes GitRepo Volume Inadvertent Local Repository Access in k8s.io/kubernetes
(GO-2025-3521)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes allows Command Injection affecting Windows nodes via nodes/*/logs/query API in k8s.io/kubernetes
(GO-2025-3522)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes kube-apiserver Vulnerable to Race Condition in k8s.io/kubernetes
(GO-2025-3547)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes Nodes can delete themselves by adding an OwnerReference in k8s.io/kubernetes
(GO-2025-3915)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Half-blind Server Side Request Forgery in kube-controller-manager through in-tree Portworx StorageClass in k8s.io/kubernetes
(GO-2025-4240)
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes kubelet arbitrary command execution
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes GitRepo Volume Inadvertent Local Repository Access
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes Nodes can delete themselves by adding an OwnerReference
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes sets incorrect permissions on Windows containers logs
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Node Denial of Service via kubelet Checkpoint API
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes allows bypassing mountable secrets policy imposed by the ServiceAccount admission plugin
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: kube-controller-manager is vulnerable to half-blind Server Side Request Forgery through in-tree Portworx StorageClass
[HIGH] 157-157: k8s.io/kubernetes 1.29.2: Kubernetes allows Command Injection affecting Windows nodes via nodes/*/logs/query API
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@go.mod` at line 157, Update the pinned indirect dependency k8s.io/kubernetes
in go.mod to a patched 1.29.x release (at least v1.29.7) to eliminate
CVE-2024-10220 and CVE-2024-5321; open go.mod, replace the existing
k8s.io/kubernetes v1.29.2 entry with v1.29.7 (or later) and run go get
k8s.io/kubernetes@v1.29.7 followed by go mod tidy to update the lock file, or if
the package is unnecessary remove the k8s.io/kubernetes line and run go mod tidy
to prune it from the module graph.
bea027f to
4bba3a9
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (2)
go.mod (2)
5-5:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winRemove the docker/distribution downgrade to v2.7.1 — it reintroduces known security vulnerabilities.
This issue was previously flagged and remains unresolved. The replace directive downgrades from v2.8.3 to v2.7.1, reintroducing HIGH severity vulnerabilities including OOM via malicious catalog API input and OCI manifest type confusion.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go.mod` at line 5, The go.mod contains a replace directive "replace github.com/docker/distribution => github.com/docker/distribution v2.7.1+incompatible" which downgrades to a vulnerable version; remove or update that replace so the module uses a secure version (e.g., v2.8.3 or later) instead of v2.7.1+incompatible: edit the go.mod to delete or change the replace line referencing github.com/docker/distribution and run go mod tidy to ensure dependencies are resolved to the non-vulnerable release.
157-157:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftPin k8s.io/kubernetes to a patched version to resolve HIGH severity vulnerabilities.
This issue was previously flagged and remains unresolved. Version 1.29.2 contains multiple HIGH severity vulnerabilities including CVE-2024-10220 (kubelet arbitrary command execution) and CVE-2024-5321 (incorrect Windows container log permissions). Upgrade to v1.29.7 or later in the 1.29.x series.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go.mod` at line 157, Update the k8s.io/kubernetes module pin in go.mod (currently "k8s.io/kubernetes v1.29.2") to a patched 1.29.x release (e.g., v1.29.7 or later) to address the reported HIGH severity CVEs, then run the Go tooling to apply and verify the change (e.g., `go get k8s.io/kubernetes@v1.29.7`, followed by `go mod tidy` and `go test`/build) so go.sum is updated and the project still compiles/tests pass.
🧹 Nitpick comments (1)
go.mod (1)
191-191: ⚡ Quick winConsider investigating the reason for pinning k8s.io/metrics to v0.32.0.
k8s.io/metricsis atv0.32.0while core modules (k8s.io/api,k8s.io/apimachinery,k8s.io/apiserver,k8s.io/client-go) are atv0.35.5. The codebase uses it only inpkg/metrics/(3 files) and there are no observed build or type compatibility issues. This version is likely pinned to satisfy a transitive dependency requirement (e.g., fromsigs.k8s.io/prow). Verify whether aligning versions is safe or if the lower version is intentional for compatibility.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go.mod` at line 191, The go.mod pins k8s.io/metrics to v0.32.0 while core k8s modules are v0.35.5; inspect whether this downgrade is required by a transitive dependency and if it's safe to align to v0.35.5. In the repo, check usage in pkg/metrics/* and run go list -m all / go mod graph to find which module requires v0.32.0 (e.g., sigs.k8s.io/prow), attempt to update by running go get k8s.io/metrics@v0.35.5 and go mod tidy, then build and run tests to confirm no type/API breakage; if a transitive consumer prevents the bump, document that dependency and keep the pin.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@go.mod`:
- Line 5: The go.mod contains a replace directive "replace
github.com/docker/distribution => github.com/docker/distribution
v2.7.1+incompatible" which downgrades to a vulnerable version; remove or update
that replace so the module uses a secure version (e.g., v2.8.3 or later) instead
of v2.7.1+incompatible: edit the go.mod to delete or change the replace line
referencing github.com/docker/distribution and run go mod tidy to ensure
dependencies are resolved to the non-vulnerable release.
- Line 157: Update the k8s.io/kubernetes module pin in go.mod (currently
"k8s.io/kubernetes v1.29.2") to a patched 1.29.x release (e.g., v1.29.7 or
later) to address the reported HIGH severity CVEs, then run the Go tooling to
apply and verify the change (e.g., `go get k8s.io/kubernetes@v1.29.7`, followed
by `go mod tidy` and `go test`/build) so go.sum is updated and the project still
compiles/tests pass.
---
Nitpick comments:
In `@go.mod`:
- Line 191: The go.mod pins k8s.io/metrics to v0.32.0 while core k8s modules are
v0.35.5; inspect whether this downgrade is required by a transitive dependency
and if it's safe to align to v0.35.5. In the repo, check usage in pkg/metrics/*
and run go list -m all / go mod graph to find which module requires v0.32.0
(e.g., sigs.k8s.io/prow), attempt to update by running go get
k8s.io/metrics@v0.35.5 and go mod tidy, then build and run tests to confirm no
type/API breakage; if a transitive consumer prevents the bump, document that
dependency and keep the pin.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 76b6c04c-57c4-48f8-a89c-827a3173069b
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum,!go.sum
📒 Files selected for processing (5)
cmd/ci-secret-bootstrap/main.gocmd/vault-subpath-proxy/kv_update_transport.gogo.modpkg/api/vault/vault.gopkg/lease/client_test.go
✅ Files skipped from review due to trivial changes (1)
- pkg/api/vault/vault.go
🚧 Files skipped from review as they are similar to previous changes (2)
- cmd/vault-subpath-proxy/kv_update_transport.go
- cmd/ci-secret-bootstrap/main.go
hector-vido
force-pushed
the
labels-support-secret-bootstrap
branch
2 times, most recently
from
f18c83b to
76c88d8
Compare
|
/test lint unit |
hector-vido
force-pushed
the
labels-support-secret-bootstrap
branch
from
76c88d8 to
6449a1f
Compare
hector-vido
force-pushed
the
labels-support-secret-bootstrap
branch
from
6449a1f to
f601659
Compare
|
/retest |
|
Scheduling tests matching the |
|
@hector-vido: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
1 participant
Since we are using ci-secret-bootstrap to manage ArgoCD cluster secrets we need a way specify labels inside the secret stored on vault to avoid manual work.
ArgoCD identify cluster secrets based on the label
argocd.argoproj.io/secret-type: clusteradded to the secrets that maps aServiceAccountand a token from other clusters insideopenshift-gitops.This PR add this possibility.
Labels support for ci-secret-bootstrap
This PR enables ci-secret-bootstrap to apply Kubernetes labels to Secrets it syncs from Vault so operators can manage label-dependent workflows (notably ArgoCD cluster-secret discovery) automatically.
What changed (practical impact)
ci-secret-bootstrap (cmd/ci-secret-bootstrap)
vault-subpath-proxy (cmd/vault-subpath-proxy)
Why this matters for CI operators
Technical notes