Repository navigation
bug(api): TenantSecrets API ignores labelSelector parameter #2527
Copy link
Copy link
Open
Labels
kind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a buglifecycle/staleDenotes an issue or PR has remained open with no activity and has become staleDenotes an issue or PR has remained open with no activity and has become staletriage/acceptedIndicates an issue is ready to be actively worked onIndicates an issue is ready to be actively worked on
Description
Description
The TenantSecrets API (core.cozystack.io/v1alpha1) ignores labelSelector query parameter when listing resources, returning all secrets in the namespace regardless of labels.
Steps to Reproduce
- Create multiple applications in a tenant namespace (e.g.,
tenant-root) - Each application creates TenantSecrets with appropriate labels (e.g.,
apps.cozystack.io/application.name=test) - Query TenantSecrets API with labelSelector:
kubectl get tenantsecrets -n tenant-root \
-l "apps.cozystack.io/application.kind=Bucket,apps.cozystack.io/application.name=test"Expected Behavior
API should return only secrets matching the label selector (similar to regular Secrets API).
Actual Behavior
API returns all TenantSecrets in the namespace, ignoring the labelSelector parameter completely.
Verification
# With labelSelector - returns empty (incorrect)
kubectl get tenantsecrets -n tenant-root \
-l "apps.cozystack.io/application.kind=Bucket,apps.cozystack.io/application.name=test"
# Output: No resources found
# Without labelSelector - returns all secrets (shows labels exist)
kubectl get tenantsecrets -n tenant-root --show-labels
# Output: Shows all secrets with correct labels like:
# apps.cozystack.io/application.name=monitoring
# apps.cozystack.io/application.name=new
# etc.Impact
- Dashboard UI shows all secrets in tenant namespace for every application
- Users see secrets from other applications (privacy/UX issue)
- No way to filter secrets by application
- Workaround requires client-side filtering (inefficient for large namespaces)
Environment
- Cozystack version: v1.3.0+
- Kubernetes: v1.31+
- Tested on: dev3.infra.aenix.org
Additional Context
Regular Kubernetes Secrets API supports labelSelector correctly. TenantSecrets should behave the same way for consistency.
Related API implementation: likely in pkg/registry or custom API server code.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
kind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a buglifecycle/staleDenotes an issue or PR has remained open with no activity and has become staleDenotes an issue or PR has remained open with no activity and has become staletriage/acceptedIndicates an issue is ready to be actively worked onIndicates an issue is ready to be actively worked on
Activity
fix(ui): add client-side filtering for TenantSecrets
dosubot commentedon Apr 28, 2026
I looked into the TenantSecrets List implementation and the labelSelector logic actually does appear to be correctly implemented — it combines user-provided selectors with the required
internal.cozystack.io/tenantresource=truelabel before querying the Kubernetes API [1].However, there are a couple of things worth investigating:
The application labels might not be on the underlying Secrets. Labels like
apps.cozystack.io/application.kindandapps.cozystack.io/application.nameare not set during TenantSecret creation itself [2]. They're expected to be injected by the lineage mutating webhook, which walks the ownership chain to find the managing Application and adds lineage labels. If the webhook isn't applying them (misconfigured, missing owner references, etc.), the Secrets won't have those labels and the selector will return empty results.You can verify by checking the raw Secrets:
kubectl get secrets -n tenant-root -l "internal.cozystack.io/tenantresource=true" --show-labelsIf the
apps.cozystack.io/application.*labels are missing from the underlying Secrets, that's the root cause.One code issue I did spot: TenantSecrets silently ignores errors from
Requirements()[3], while similar resources like TenantModule and Application explicitly check and return those errors [4] [5]. This inconsistency is worth fixing for robustness.Also notable: TenantSecrets has no test coverage at all (no
rest_test.go), unlike similar resources like TenantNamespace and TenantModule which have dedicated test files.So the behavior you're seeing ("returns empty with selector, returns all without") is actually consistent with the filtering working — it's just that no Secrets match the combined label criteria because the application labels may not be present on them. Could you check whether those labels exist on the raw Secrets?
To reply, just mention @dosu.
Docs are dead. Just use Dosu.
fix(ui): drop watch for TenantSecrets to honor labelSelector
fix(ui): add client-side filtering for TenantSecrets
fix(ui): drop watch for TenantSecrets to honor labelSelector