envoyproxy / envoyproxy/ratelimit

Question: Compatibility matrix ratelimit SHA vs what's actually in the Helm chart, which should we follow?

Aperta
#1,139 7 commenti 3 reazioni 0 assegnatari Vedi su GitHub
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.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.