envoyproxy / envoyproxy/ratelimit

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

Open
#1,139 7 comments 3 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
2.7k
Forks
535
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.