Compatibility with recent cloud-run-proxy changes

[ricardogesuatto-tw]

Hello,

A recent commit in cloud-run-proxy switches from the Authorization header to X-Serverless-Authorization to prevent conflicts with authentication/authorization flows from actual Cloud Run applications.

While this change is technically correct, it breaks how the proxy is used for the local FreshClam database mirror. Since the Cloud Storage API expects regular authentication (vs service-to-service auth with either header), an Forbidden error is returned during container startup.

I'm actually not sure if this issue should be opened here or in the cloud-run-proxy repository... My understanding is that the proxy is being used in an unusual way by the malware scanner, but please let me know if it should be supported in the long run.

[ntang86]

Same issue. Any update on this?

[ntang86]

@nielm ?

[nielm]

In the short term, use cloud-run-proxy v0.3.0 -- which it already does

Cloud-run-proxy have been reluctant to add new features to support my use of their tool...

[ntang86]

Hi, thank you for your answer. I'm failing to understand how their new header X-Serverless-Authorization is impacting clamav? Any clue?

[nielm]

As we don't use 0.4, it doesn't affect it at all! However if we did try to use 0.4 cloud-run-proxy would not work to proxy freshclam's http requests to authenticated cloud storage URLs. 0.3 has a variety of critical CVEs in golang standard libraries, so I am looking at implementing my own authenticating reverse proxy in node.js, specifically for this use case

…

Message ID: <GoogleCloudPlatform/docker-clamav-malware-scanner/issues/54/1824790751@ github.com>

[ricardogesuatto-tw]

@ntang86 The Cloud Storage API expects an access token in the Authorization header. The X-Serverless-Authorization header is effectively ignored by Cloud Storage, since it's specific for serverless scenarios. Cloud Run accepts either Authorization or X-Serverless-Authorization.

Some time before the original post, cloud-run-proxy switched to X-Serverless-Authorization so it frees up the Authorization header for application-specific flows. Whilst this change improves compatibility for most common scenarios, it also breaks CVD updates as implemented in this repository.

Even though cloud-run-proxy supports a -host parameter, pointing it to https://storage.googleapis.com (a completely different service) goes way beyond its intended usage. I'm not sure the team responsible for the proxy endorses this workaround ... Also consider that the equivalent functionality bundled in Google Cloud SDK (mentioned in their README file)does not includes that parameter at all.

I am still using cloud-run-proxy v.0.3.0 as indicated above, but for CVEs / compliance reasons I'm considering if Cloud Storage FUSE can be used instead.

[ntang86]

Thank you for your explanation !

Indeed, we are also facing some CVEs security issue, using the cloud-run-proxy v.0.3.0, not ideal for any production system.
Storage Fuse is a great idea, I might give it a try.

[nielm]

Freshclam - which downloads updates and applies them to the clamav database - only supports http(s) targets for the clamav database update servers. That's why I had to use cloud-run-proxy to add the authentication headers so that it could use non-public GCS buckets. It may be possible to simply copy the cvd files to the clamav database location, but I have not tried it, preferring to use freshclam which verifies DB integrity...

[nielm]

Fix in progress in #60

[ntang86]

Thank you, that's awesome, less dependency to worry about! Looking forward to the fix to be merged !