search

brancz / kube-rbac-proxy

Kubernetes RBAC authorizing HTTP proxy for a single upstream.
Apache License 2.0
587 stars 189 forks source link

vulnerabilities on kube-rbac-proxy v0.14.4 #263

Closed fredprod closed 1 year ago

fredprod commented 1 year ago

Hi,

We found 1 high vulnerability in last release:

Library Vulnerability Severity Status Installed Version Fixed Version
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp CVE-2023-45142 HIGH fixed v0.20.0 0.44.0

Can you please give us an estimated time when it is planned to be resolved?

Thanks, Frederic

ibihim commented 1 year ago

With found, you mean that you have a working example of it being abused? Checking the description of the CVE, I don't see a codepath that would affect kube-rbac-proxy.

If it would be a high severity CVE that affects us, I would drop everything and fix it right now. As it doesn't look like so and in the context of http/2 discussions going on, I might still create another release this week, which would replace the dep.

fredprod commented 1 year ago

I do not have any working example of it being abused. But with this high vulnerability, we could not use and deploy this release.

ibihim commented 1 year ago

So you are saying that there is a vulnerability scanner, that finds a vulnerability in the dependencies, which isn't being used by kube-rbac-proxy and doesn't affect kube-rbac-proxy, but blocks your release? Oh, my...

We need a better solution for this. Time-wise it is pretty intensive to release several times a month.

I will try to make a release tomorrow (CEST). I don't want to block anyone's release.

ibihim commented 1 year ago

Sorry, i was to tired yesterday, but it should be fixed with v0.15.0

Uttkarsh commented 1 year ago

Vulnerability is still visible with 0.15.0 image. Aqua security tool shows it specifically for go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp but go.opentelemetry.io/contrib/instrumentation was replaced by PR #264

Below command shows the security vulnerability # docker run -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy:0.46.0 image quay.io/brancz/kube-rbac-proxy:v0.15.0

RDarnel commented 1 year ago

Yeah unfortunately I think we should reopen this ticket or create a new one to track this effort.

Many of us use trivy to scan our code, and you can even create a github action to run these scans. You could also use Dependabot to keep these packages up to date and reduce maintenance effort overall on these vulnerabilities.

So you are saying that there is a vulnerability scanner, that finds a vulnerability in the dependencies, which isn't being used by kube-rbac-proxy and doesn't affect kube-rbac-proxy, but blocks your release? Oh, my...

Yeah while it gets to be a pain since we are bound to have transient dependencies that have vulnerable code we don't use in them, I've learned that many companies track vulnerable packages that their software imports regardless of whether they can be exploited. In the end, The general idea is that when it comes to library packages with vulnerable code, even if you don't use the code today, there's always the risk that a future commit will. No developer can really know if the method they are using from a library is vulnerable while they are adding it in so they can't be expected to worry about that while they are writing their code. I'm not aware of IDEs smart enough to track this and warn you. The best we can do today is to keep our packages up to date using tools like Dependabot, so that we can spend less time worrying about package management and vulnerabilities.