我们的平台结构要求在单个和/或仅几个项目中(如果可能的话(中大量私有映像。 此外，我们主要是一家 GCP 商店，希望留在 Google 环境中。
目前 - 据我了解 - GCR ACL 结构需要附加到服务帐户(在本例中(的 storage.objects.get 和 storage.objects.list 权限(或 objectViewer 角色(才能访问 GCR。 这通常不是问题，我们在使用 gsutil 在项目级别为容器注册表启用读取访问权限时没有任何直接问题。 下面是我们正在执行的实现常规访问的工作流示例。 但是，它无法实现我们限制每个图像访问的服务帐户的目标。
简单的 Docker 镜像被构建、标记并推送到 GCR 中，使用 exproj 代替使用的项目名称。
sudo docker build -t hello_example:latest
sudo docker tag hello_example:latest gcr.io/exproj/hello_example:latest
sudo docker push gcr.io/exproj/hello_example:latest
这为我们提供了ex_proj项目中hello_example存储库。 我们创建一个服务帐户，并授予其读取存储桶的权限。
gsutil acl ch -u gcr-read-2@exproj.iam.gserviceaccount.com:R gs://artifacts.exproj.appspot.com/
Updated ACL on gs://artifacts.exproj.appspot.com
然后，这允许我们通过密钥使用 Docker 登录。
sudo docker login -u _json_key --password-stdin https://gcr.io < gcr-read-2.json
Login Succeeded
然后按预期从注册表中拉下映像
sudo docker run gcr.io/exproj/hello_example
但是，出于我们的目的，我们不希望允许服务帐户访问每个项目的整个注册表，而只能访问上述hello_example。 在我对 gsutil 的测试中，我无法定义特定的基于每个图像的 ACL，但是，我想知道我是否只是错过了一些东西。
gsutil acl ch -u gcr-read-2@exproj.iam.gserviceaccount.com:R gs://artifacts.exproj.appspot.com/hello_example/
CommandException: No URLs matched: gs://artifacts.exproj.appspot.com/hello_example/
在这一切的宏伟计划中，我们想达到以下模型：
- 帐户 A 在 ExampleProj 中创建 ImageA：TagA
- 生成服务帐户 A
- 为服务帐户 A 设置的 ACL 仅访问 ExampleProj/ImageA 及其下的所有标签
- ServiceAccountA JSON 被提供给账户 A
- 帐户 A 现在只能访问 ExampleProj/ImageA，帐户 B 无法访问帐户 A 的示例Proj/ImageA
虽然我们可以按项目执行每个账户的容器注册表，但需要跨每个账户跟踪项目以及在大量使用期间受到 GCP 项目限制的扩展潜力令人担忧。
除了上述之外，我也对任何可以实现这一目标的想法或结构持开放态度！
编辑
感谢强生的回应！ 我按照推荐的有关 blob 读取的行编写了一个快速而肮脏的脚本。 我仍在努力验证它的成功，但是，我确实想声明，我们确实控制了何时发生推送，因此跟踪结果不像在其他情况下那样脆弱。
下面是我整理的一个脚本，作为清单 -> 摘要权限修改的示例。
require 'json'
# POC GCR Blob Handler
# ---
# Hardcoded params and system calls for speed
# Content pushed into gcr.io will be at gs://artifacts.{projectid}.appspot.com/containers/images/ per digest
def main()
puts "Running blob gathering from manifest for org_b and example_b"
manifest = `curl -u _token:$(gcloud auth print-access-token) --fail --silent --show-error https://gcr.io/v2/exproj/org_b/manifests/example_b`
manifest = JSON.parse(manifest)
# Manifest is parsed, gather digests to ensure we allow permissions to correct blobs
puts "Gathering digests to allow permissions"
digests = Array.new
digests.push(manifest["config"]["digest"])
manifest["layers"].each {|l| digests.push(l["digest"])}
# Digests are now gathered for the config and layers, loop through the digests and allow permissions to the account
puts "Digests are gathered, allowing read permissions to no-perms account"
digests.each do |d|
puts "Allowing permissions for #{d}"
res = `gsutil acl ch -u no-perms@exproj.iam.gserviceaccount.com:R gs://artifacts.exproj.appspot.com/containers/images/#{d}`
puts res
end
puts "Permissions changed for org_b:example_b for no-perms@exproj.iam.gserviceaccount.com"
end
main()
虽然这确实适合设置权限，但我看到对 Docker 的实际身份验证存在相当大的脆弱性，并且在未识别 Docker 登录方面下拉。
这是你所说的琼约翰逊吗？ 本质上是否允许基于与该映像/标记关联的清单/层对每个服务帐户的每个 blob 进行访问？
谢谢！
目前没有一种简单的方法来做你想做的事情。
您可以做的一件事是为每个映像授予对存储桶中各个 Blob 的访问权限。这不是非常优雅，因为您必须在每次推送后更新权限。
您可以使用 GCR 中的 pubsub 支持来侦听推送，查看该映像引用的 Blob，将存储库路径与需要访问的任何服务帐户匹配，然后向这些服务帐户授予对每个 blob 对象的访问权限，从而自行自动执行此操作。
一个缺点是每个服务帐户仍然可以查看映像清单(本质上是层摘要列表 + 一些映像运行时配置(。但是，他们将无法提取实际的图像内容。
此外，这有点依赖于 GCR 的一些实现细节，因此将来可能会中断。