dapr / dapr/components-contrib

Kubernetes secret store does not declare FeatureMultipleKeyValuesPerSecret despite supporting it

Open Beginner friendly
#4,544 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.