ServiceAccount pruning skips consecutive auto-generated token secrets in removeServiceAccountIrrelevantField

[Anjali-Chauhan1]

What happened

When Karmada prunes a ServiceAccount before propagating it to member clusters, removeServiceAccountIrrelevantField (in pkg/resourceinterpreter/default/native/prune/prune.go) is meant to strip all auto-generated <sa-name>-token-* secrets.

It fails to do so when two or more such secrets are listed consecutively in the secrets array: only the first of each adjacent run is removed and the rest survive and get propagated.

The loop removes an element and advances the index in the same step, so when an element is deleted the following element shifts into the freed slot and is then skipped without being checked.

What you expected to happen

All secrets whose name starts with <sa-name>-token- are removed regardless of their position/ordering in the secrets list.

Expected result for the input above:

secrets:
  - name: foo-dockercfg-zzz

How to reproduce it

Propagate a ServiceAccount with adjacent auto-generated token secrets:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: foo
secrets:
  - name: foo-token-aaaaa
  - name: foo-token-bbbbb
  - name: foo-dockercfg-zzz

Expected propagated result: both foo-token-* entries removed.

Actual: foo-token-bbbbb remains.

The existing unit test in prune_test.go only covers a single token secret followed by a non-token secret, so this code path is never exercised—which is why it went unnoticed.

Anything else we need to know?

Separately, the entry inspection on the same line uses non-comma-ok type assertions, so a malformed secrets entry (not an object, or missing name) would panic the interpreter goroutine rather than being handled gracefully.

I'm happy to submit a PR with a fix and a regression test.

Environment

• Karmada version: master (v1.19.0-alpha.1, commit ffbade9); the affected code is long-standing, so all currently supported releases are affected.
• kubectl-karmada / karmadactl version: N/A (source-level defect in the resource interpreter).
• Others: Found via source code review and reproduced with an in-package Go test.

[Anjali-Chauhan1]

/assign