问题
I testing Google Cloud Run and I have some security concerns. Let's say I process a user input with a binary program. What if the program is vulnerable and malicious code injected into the container. The attacker would be able to access my database or storage or any resource the container has the permissions to access.
The question is: is this a genuine concern and how do I prevent it?
The best idea I have is to put another container inside that just holds the potentially vulnerable binary.
回答1:
It is indeed a genuine concern –however, this class of attacks are not specific to Cloud Run, and applicable to any compute platforms that you would the untrusted binary in.
Imagine you're running ffmpeg
in a container, and one of your users gives you a video input to convert. This video can exploit vulnerabilities in ffmpeg (since it's not written in a memory-safe language, there has been plenty), and may execute arbitrary code. This arbitrary code can potentilly exfiltrate your environment, including access token to GCP APIs by querying:
curl -H "metadata-flavor: Google" http://metadata/computeMetadata/v1/instance/service-accounts/default/token
The secrets you injected to your container and this token are probably the most sensitive artifacts to be exfiltrated in case of an attack.
To prevent yourself from this class of attacks I recommend:
- Create a separate service on Cloud Run whose only job is to shell out to the untrusted executable (as you've mentioned).
- Run this service with a Service Account (
--service-account
) that has no permissions to do anything in your object. This way, the attacker can exfiltrate a token that cannot do much (however, may learn your GCP project ID or email address of this service account). - (This is not possible on Cloud Run yet as far as I know–) Run the container’s filesystem in a readonly mode to prevent the attacker from changing the executables or libraries on the container which can be influence subsequent requests handled by the container.
- (In lack of a read-only container filesystem today–) if the untrusted binary you’re executing is/can be "statically compiled", on every request, consider creating a new temporary directory that contains the binary. Then, chroot there and execute the binary in this directory (so that its side effects will not influence rest of the container), and cleanup this directory before the request finishes.
Hope this helps.
来源:https://stackoverflow.com/questions/61448152/google-cloud-run-security-concerns