Possible supply chain attack via Helm chart deployed `jimmidyson/configmap-reload` pod

julian-waibel commented 1 month ago

What's wrong?

Without further customizing, the Grafana Alloy Helm chart spawns the config-reloader pod ghcr.io/jimmidyson/configmap-reload:v0.12.0, see configReloader section in values.yaml.

To me jimmidyson/configmap-reload looks like a smaller project (976 stars on GitHub) and more kind of a personal project of GitHub user https://github.com/jimmidyson. At least I speculate that it's not hosted or maintained by a company.

Doesn't this dependency make Alloy very vulnerable for supply chain attacks? E.g. an attacker gains access over this container registry repository and pushes a malicious image under the same tag which would then automatically be pulled and run at least for new customer cluster installations?

In general there is this famous xkcd Dependency comic and this attack vector was abused already a lot in other software.

While a safe default configuration is desirable, I am aware of the fact that consumers of this Helm chart could fix this concern themself:

Reviewing and building the config-reloader image themself, pushing it to a private registry and referencing this private image via Alloy Helm chart configReloader.image.* values.yaml
Specifing the image via digest instead of tag via Alloy Helm chart configReloader.image.digest values.yaml
Disabling the config-reloader via Alloy Helm chart configReloader.enabled values.yaml; however at the cost of losing its functionality

How is Grafana Labs in general dealing with such 3rd party dependencies? Or is this Helm chart community-maintained?

Would it be possible to fork and maintain this dependency by Grafana Labs? Or maybe replace the dependency with another one (like stakater/Reloader which seems more popular with 7.5k stars on GitHub; note that I am not affiliated, I just list it as an example)?

What are your thoughts?

Steps to reproduce

Deploy the Grafana Alloy Helm chart without further customizing of the config-reloader.

System information

No response

Software version

No response

Configuration

No response

Logs

No response

calebAtIspot commented 1 month ago

Check out the bottom left of https://github.com/jimmidyson. It may be under his personal user, but they seem trustworthy as they are a member of the Kubernetes org and a principal engineer at Nutanix. They could still be hacked, of course, just saying it's not just some random person maintaining it.

Pinning the digest does sound like a good idea though.

github-actions[bot] commented 1 week ago

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it. If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue. The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity. Thank you for your contributions!

grafana / alloy