Description
The Kubernetes secret store's Features() returns an empty list:
// 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:
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
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).
Description
The Kubernetes secret store's
Features()returns an empty list:But its own
GetSecret()/BulkGetSecret()implementations already correctly return multiple key-value pairs per secret:This is correct behavior, since a Kubernetes
Secretresource'sDatafield is inherently amap[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 insecretstores/:FeatureMultipleKeyValuesPerSecret(multi-key-value backend):local/file,hashicorp/vault(conditionally, based onvaultValueType),aws/secretmanagerazure/keyvault,gcp/secretmanager,huaweicloud/csms,tencentcloud/ssm- each has an explicit// No Feature supported.comment, consistent with their backend's actual data modelkubernetes: the one outlier - same multi-key-value backend shape as the first group, but declares no featuresImpact
I couldn't find
FeatureMultipleKeyValuesPerSecretwired into any runtime control-flow decision indapr/daprtoday (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
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).