dapr / dapr/components-contrib
Kubernetes secret store does not declare FeatureMultipleKeyValuesPerSecret despite supporting it
- Dominant language
- Go
- Stars
- 602
- Forks
- 580
- Avg merge
- 4d 9h
- Merged PRs (30d)
- 6
Description
## Description
The Kubernetes secret store's `Features()` returns an empty list:
```go
// secretstores/kubernetes/kubernetes.go
func (k *kubernetesSecretStore) Features() []secretstores.Feature {
return []secretstores.Feature{}
}
```
But its own `GetSecret()`/`BulkGetSecret()` implementations already correctly return **multiple** key-value pairs per secret:
```go
func (k *kubernetesSecretStore) GetSecret(ctx context.Context, req secretstores.GetSecretRequest) (secretstores.GetSecretResponse, error) {
resp := secretstores.GetSecretResponse{Data: map[string]string{}}
...
for k, v := range secret.Data {
resp.Data[k] = string(v)
}
return resp, nil
}
```
This is correct behavior, since a Kubernetes `Secret` resource's `Data` field is inherently a `map[string][]byte` - multiple keys per secret is the normal case, not an edge case.
## Comparison across all secret store providers
I checked `Features()` across every provider in `secretstores/`:
- **Correctly declare `FeatureMultipleKeyValuesPerSecret`** (multi-key-value backend): `local/file`, `hashicorp/vault` (conditionally, based on `vaultValueType`), `aws/secretmanager`
- **Correctly declare no features** (genuinely single-value-per-secret backend): `azure/keyvault`, `gcp/secretmanager`, `huaweicloud/csms`, `tencentcloud/ssm` - each has an explicit `// No Feature supported.` comment, consistent with their backend's actual data model
- **`kubernetes`**: the one outlier - same multi-key-value backend shape as the first group, but declares no features
## Impact
I couldn't find `FeatureMultipleKeyValuesPerSecret` wired into any runtime control-flow decision in `dapr/dapr` today (only referenced in test mocks), so this doesn't currently break request handling. It is, however, a real metadata/capability-advertisement inconsistency: any tooling, SDK, or dashboard that inspects a secret store's declared features to decide how to present or handle its results would get an inaccurate answer for the Kubernetes provider specifically.
## Proposed fix
```go
func (k *kubernetesSecretStore) Features() []secretstores.Feature {
return []secretstores.Feature{secretstores.FeatureMultipleKeyValuesPerSecret}
}
```
Happy to open a PR with this plus a regression test asserting the declared feature matches the actual multi-key return behavior (similar in spirit to the existing Vault tests, which cover the conditional case).
Contributor guide
Research direction
Start in secretstores/kubernetes/kubernetes.go by reading Features(), GetSecret(), and BulkGetSecret() to compare the declared capability with the returned data shape. Confirm the Kubernetes provider advertises FeatureMultipleKeyValuesPerSecret and add a regression test that verifies this declaration matches its multi-key behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 88/100