perf: cache required keys in secrets and configmaps#8045
perf: cache required keys in secrets and configmaps#8045arkodg merged 1 commit intoenvoyproxy:mainfrom
Conversation
✅ Deploy Preview for cerulean-figolla-1f9435 canceled.
|
0a572e5 to
641eb3d
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8045 +/- ##
==========================================
+ Coverage 73.70% 73.78% +0.08%
==========================================
Files 237 237
Lines 35703 35744 +41
==========================================
+ Hits 26314 26374 +60
+ Misses 7529 7513 -16
+ Partials 1860 1857 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| ) | ||
|
|
||
| var ( | ||
| // cachedConfigMapKeys defines the keys to keep in ConfigMap data cache |
There was a problem hiding this comment.
for some of these cases we pick the first key if we cant find the desired key, we'll need to make sure we dont include those
cc @zirain
There was a problem hiding this comment.
expectedAndFirstFallbackFilter is supposed to handle this (moved it to helpers just now)
7606860 to
d36bcdb
Compare
|
it would be good to have a test case for fallback to first key of the configmap, maybe change an existing one. |
d36bcdb to
0e2495e
Compare
|
Added unit tests for the transform functions, also changed the key in Lua configmap in E2E so it picks first key. |
1ffdf7e to
a1b45b0
Compare
Signed-off-by: Rudrakh Panigrahi <rudrakh97@gmail.com>
a1b45b0 to
97cbc2b
Compare
| var ( | ||
| // cachedConfigMapKeys defines the keys to keep in ConfigMap data cache | ||
| cachedConfigMapKeys = map[string]bool{ | ||
| gatewayapi.JWKSConfigMapKey: true, | ||
| gatewayapi.LuaConfigMapKey: true, | ||
| gatewayapi.ResponseBodyConfigMapKey: true, | ||
| gatewayapi.CACertKey: true, | ||
| gatewayapi.CRLKey: true, | ||
| } | ||
|
|
||
| // cachedSecretKeys defines the keys to keep in Secret data cache | ||
| cachedSecretKeys = map[string]bool{ | ||
| corev1.TLSCertKey: true, | ||
| corev1.TLSPrivateKeyKey: true, | ||
| egv1a1.TLSOCSPKey: true, | ||
| egv1a1.OIDCClientIDKey: true, | ||
| egv1a1.OIDCClientSecretKey: true, | ||
| egv1a1.BasicAuthUsersSecretKey: true, | ||
| egv1a1.InjectedCredentialKey: true, | ||
| egv1a1.APIKeysSecretKey: true, | ||
| corev1.DockerConfigJsonKey: true, | ||
| gatewayapi.CACertKey: true, | ||
| gatewayapi.CRLKey: true, | ||
| hmacSecretKey: true, | ||
| } | ||
| ) | ||
|
|
There was a problem hiding this comment.
Do we need to define an unified list instead of different ones for configmap vs secret? I have seen cases where we use secrets and configmaps interchangeably using SecretObjectReference.
There was a problem hiding this comment.
this is fine, we can add comments to remind devs to add to both places
|
This looks good - just curious, are people putting other keys in the Secret/ConfigMaps that aren't required? |
Might be sharing configmap for multiple purposes @zhaohuabing |
Signed-off-by: Rudrakh Panigrahi <rudrakh97@gmail.com> Signed-off-by: Sadmi Bouhafs <sadmibouhafs@gmail.com>
|
This PR introduced a regression for API key authentication when secrets contain multiple client IDs. Issue: The Example: apiVersion: v1
kind: Secret
metadata:
name: apikey-secret
data:
client1: a2V5MQ== # cached ✓
client2: a2V5Mg== # dropped ✗
client3: a2V5Mw== # dropped ✗Impact: Authentication fails for all API keys except the first client ID alphabetically. Affected: v1.7.0 and main branch Tracking issue: #8227 |
Fixes API key authentication bug where secrets with multiple client IDs were incorrectly filtered, keeping only the first client ID alphabetically. The filter now detects when NO predefined keys exist in the data and preserves all keys in that case. This handles API key secrets where each key represents a client ID, as well as any other similar use cases. Changes: - Modified expectedAndFirstFallbackFilter to check if any predefined keys exist before filtering - If no predefined keys found, all keys are preserved - Updated tests to reflect new expected behavior Fixes envoyproxy#8227 Related to envoyproxy#8045
Fixes API key authentication bug where secrets with multiple client IDs were incorrectly filtered, keeping only the first client ID alphabetically. The filter now detects when NO predefined keys exist in the data and preserves all keys in that case. This handles API key secrets where each key represents a client ID, as well as any other similar use cases. Changes: - Modified expectedAndFirstFallbackFilter to check if any predefined keys exist before filtering - If no predefined keys found, all keys are preserved - Updated tests to reflect new expected behavior Fixes envoyproxy#8227 Related to envoyproxy#8045
Fixes API key authentication bug where secrets with multiple client IDs were incorrectly filtered, keeping only the first client ID alphabetically. The filter now detects when NO predefined keys exist in the data and preserves all keys in that case. This handles API key secrets where each key represents a client ID, as well as any other similar use cases. Changes: - Modified expectedAndFirstFallbackFilter to check if any predefined keys exist before filtering - If no predefined keys found, all keys are preserved - Updated tests to reflect new expected behavior Fixes envoyproxy#8227 Related to envoyproxy#8045 Signed-off-by: Alexej Disterhoft <alexej@disterhoft.de>
What type of PR is this?
perf: cache required keys in secrets and configmaps
What this PR does / why we need it:
Including only needed keys in Secret and ConfigMap data to reduce memory usage.
Release Notes: Yes