Google Cloud Run安全问题 [英] Google Cloud Run security concerns

问题描述

我正在测试Google Cloud Run，并且存在一些安全问题。假设我使用二进制程序处理用户输入。如果程序容易受到攻击并且恶意代码注入了容器，该怎么办？攻击者将能够访问我的数据库或存储或容器有权访问的任何资源。

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.

推荐答案

这确实是一个真正的问题-但是，此类攻击并非特定于Cloud Run，并且适用于您将不受信任的二进制文件放入其中的任何计算平台。

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.

想象您正在容器中运行 ffmpeg ，您的一位用户为您提供了要转换的视频输入。该视频可以利用ffmpeg中的漏洞（因为它不是用内存安全的语言编写的，因此存在很多漏洞），并且可以执行任意代码。此任意代码可以通过以下方式强大地泄漏您的环境，包括访问GCP API的令牌：

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.

：

• 在Cloud Run上创建一个单独的服务，其唯一的工作就是将外壳封装到不受信任的可执行文件中（如您所述）。 / li>
  
• 使用没有权限在对象中执行任何操作的服务帐户（-service-account ）运行此服务。这样，攻击者可以窃取无法完成的令牌（但是，可能会获悉您的GCP项目ID或该服务帐户的电子邮件地址）。


• （在Cloud Run中是不可能的据我所知–）以只读模式运行容器的文件系统，以防止攻击者更改容器上的可执行文件或库，这可能会影响容器随后处理的请求。


• （今天缺乏只读的容器文件系统），如果正在执行的不受信任的二进制文件是可以静态编译的，可以在每次请求时考虑创建一个包含二进制文件的新临时目录。然后，在此处 chroot 并在此目录中执行二进制文件（这样它的副作用就不会影响

• 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.

希望这会有所帮助。

这篇关于Google Cloud Run安全问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！