Hey all, hoping to get some clarity on something I stumbled across while pinning the ratelimit image for a v1.7.x deployment.
What I noticed
The compatibility matrix https://gateway.envoyproxy.io/news/releases/matrix/ shows a single SHA for the whole v1.7 line:
| EG Version |
Rate Limit SHA |
| v1.7 |
3fb70258 |
But if you look at what's actually in the Helm chart values.yaml across the v1.7.x patches, it's been bumped twice since then:
| Release |
Rate Limit SHA |
PR |
| v1.7.0 |
3fb70258 |
(matches matrix) |
| v1.7.1 |
c8765e89 |
#8500 |
| v1.7.2 / v1.7.3 |
05c08d03 |
#8763 |
So the matrix is still pointing at 3fb70258 but anyone installing via the Helm chart today gets 05c08d03. Not necessarily a problem, but it does make it a bit confusing to know what to actually pin if you're managing images yourself.
Security
Out of curiosity I ran a quick grype scan against all three SHAs directly from the registry:
grype registry:docker.io/envoyproxy/ratelimit:<SHA> -o table
| SHA |
EG Release |
Critical |
High |
Medium |
Low |
3fb70258 |
v1.7.0 |
3 |
16 |
10 |
1 |
c8765e89 |
v1.7.1 |
2 |
14 |
9 |
0 |
05c08d03 |
v1.7.2 / v1.7.3 |
2 |
14 |
9 |
0 |
So we move forward and get less vulnerabilities
A few questions
-
Which is the source of truth: the matrix or the Helm chart? Should the matrix be tracking the SHA per patch rather than just per minor, or is there a reason to keep it tied to the initial minor release?
-
Is there any CI/test coverage that runs when the ratelimit SHA is bumped? just curious if there's e2e coverage that validates the new image before it goes in or if that's something being looked at.
-
Is there a cadence or process for proactively bumping the ratelimit image when fixes are available upstream or does it tend to be reactive?
Not expecting perfection here, just trying to understand the intended workflow so I can make sensible decisions about which SHA to track. If I've missed some docs that cover this happy to be pointed in the right direction!
References
Hey all, hoping to get some clarity on something I stumbled across while pinning the ratelimit image for a v1.7.x deployment.
What I noticed
The compatibility matrix https://gateway.envoyproxy.io/news/releases/matrix/ shows a single SHA for the whole v1.7 line:
3fb70258But if you look at what's actually in the Helm chart
values.yamlacross the v1.7.x patches, it's been bumped twice since then:3fb70258c8765e8905c08d03So the matrix is still pointing at
3fb70258but anyone installing via the Helm chart today gets05c08d03. Not necessarily a problem, but it does make it a bit confusing to know what to actually pin if you're managing images yourself.Security
Out of curiosity I ran a quick
grypescan against all three SHAs directly from the registry:3fb70258c8765e8905c08d03So we move forward and get less vulnerabilities
A few questions
Which is the source of truth: the matrix or the Helm chart? Should the matrix be tracking the SHA per patch rather than just per minor, or is there a reason to keep it tied to the initial minor release?
Is there any CI/test coverage that runs when the ratelimit SHA is bumped? just curious if there's e2e coverage that validates the new image before it goes in or if that's something being looked at.
Is there a cadence or process for proactively bumping the ratelimit image when fixes are available upstream or does it tend to be reactive?
Not expecting perfection here, just trying to understand the intended workflow so I can make sensible decisions about which SHA to track. If I've missed some docs that cover this happy to be pointed in the right direction!
References