Skip to content

bug(api): TenantSecrets API ignores labelSelector parameter #2527

Open

Description

@IvanHunters

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

  1. Create multiple applications in a tenant namespace (e.g., tenant-root)
  2. Each application creates TenantSecrets with appropriate labels (e.g., apps.cozystack.io/application.name=test)
  3. 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.

Activity

  1. dosubot commented on Apr 28, 2026

    @dosubot

    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=true label 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.kind and apps.cozystack.io/application.name are 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-labels

    If 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.

    Leave Feedback Ask Dosu about cozystack Share Dosu with your team

  2. self-assigned this
    on Apr 29, 2026
  3. added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    and removed on Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

kind/bugCategorizes issue or PR as related to a buglifecycle/staleDenotes an issue or PR has remained open with no activity and has become staletriage/acceptedIndicates an issue is ready to be actively worked on

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions