envoyproxy / envoyproxy/ratelimit
Question: Compatibility matrix ratelimit SHA vs what's actually in the Helm chart, which should we follow?
- Lingua principale
- Go
- Stelle
- 2.7k
- Fork
- 535
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
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: -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
1. 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?
2. 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.
3. 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
- Compatibility matrix: https://gateway.envoyproxy.io/news/releases/matrix/
- ratelimit Docker Hub: https://hub.docker.com/r/envoyproxy/ratelimit/tags
Guida per i contributori
Apri la guida per i contributori
Valutazione
Questa issue non è ancora stata valutata.