.dockercfg 文件应该如何托管在 Mesosphere-on-AWS 设置中，以便只有 Mesosphere 可以使用它？答案

【问题标题】：How should a .dockercfg file be hosted in a Mesosphere-on-AWS setup so that only Mesosphere can use it?.dockercfg 文件应该如何托管在 Mesosphere-on-AWS 设置中，以便只有 Mesosphere 可以使用它？
【发布时间】：2015-09-13 13:24:06
【问题描述】：

我们在私有 VPC 中使用 Mesosphere on AWS 建立了一个测试集群。我们有一些公开的 Docker 镜像，它们很容易部署。但是，我们的大多数服务都是私有镜像，托管在 Docker Hub 私有计划上，并且需要身份验证才能访问。

Mesosphere 能够进行私有注册表身份验证，但它以一种不完全理想的方式实现这一点：需要在所有 Mesos/Marathon 任务定义中指定 .dockercfg 文件的 HTTPS URI。

正如标题所暗示的，问题基本上是：.dockercfg 文件应该如何托管在 AWS 中，以便尽可能严格地将访问权限限制在 Mesos 主从服务器上？ p>

【问题讨论】：

标签： amazon-web-services mesos amazon-vpc docker-registry mesosphere

【解决方案1】：

我见过的许多项目都使用您提到的 S3 方法。您的观点仍然有效，我们应该/将在社区中讨论这一点。

【讨论】：

如果 Mesos 社区正在考虑改进它的方法，如果要使用 .dockercfg 文件，最好在 GUI 中有一个文件上传框（以及相应的 REST API 端点) 您可以在其中拖放一个 .dockercfg，将其发送到 Mesos(phere?) 主节点，主节点会在内部完成艰苦的工作，将其存储并提供给集群从节点。

【解决方案2】：

您还可以在 HDFS 或 FTP/FTPS 服务器中托管 .dockercfg。如果 HTTPS 不可接受，Mesos 提取器可以支持任何这些协议。

【讨论】：

【解决方案3】：

由于 Mesos 文档在这方面做得很差，我将回答这个 wiki 风格的问题并随时更新这个答案。

应该有效的策略

在 S3 上托管（具有基于网络的访问限制）

在 S3 上托管 .dockercfg 文件。为了获得更好的安全性，您应该考虑将其放在自己的存储桶中，或者专门用于存储机密的存储桶中。这给创建安全策略带来了一些有趣的挑战，该策略实际上可以锁定 S3 存储桶，以便只有 Mesos 可以看到它，但可以做到。

Mesos 任务配置：

{
  ...
  "uris": ["https://s3-eu-west-1.amazonaws.com/my-s3-bucket-name/.dockercfg"]
  ...
}

S3 存储桶策略（使用 VPC 端点）：

注意：此策略允许允许的主体做任何事情，这对于生产来说太草率了，但在测试集群中调试时应该会有所帮助。

{
  "Id": "Policy123456",
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Stmt123456",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::my-s3-bucket",
      "arn:aws:s3:::my-s3-bucket/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-my-mesos-cluster-vpce-id"
      }
    },
    "Principal": "*"
  }]
}

您还需要一个 VPCE 配置，为您提供一个 VPCE ID 以插入上述 S3 存储桶条件。（我猜如果您不使用 VPC 端点，您可以只匹配 VPC id 吗？）

您可以通过转到 Mesos UI（如果您使用的是 DCOS，这不是漂亮的 DCOS UI）并观察具有您的应用名称的任务是否出现在 Active Tasks 或 Completed Tasks 中来检查这是否有效列表。

（目前）不起作用的诱人策略

在 S3 上托管（带有签名的 URL）

在这个 S3 变体中，我们不使用基于网络的访问限制，而是使用 .dockercfg 文件的签名 URL。

Mesos 任务配置应如下所示：

{
  ...
  "uris": ["https://my-s3-bucket/.dockercfg?AWSAccessKeyId=foo&Expires=bar&Signature=baz"]
  ...
}

不幸的是，上面的 S3 签名 URL 策略不起作用，因为 Mesos-1686 观察到任何下载的文件都准确地保留了远程文件名，包括查询字符串，导致文件名类似于“.dockercfg ?AWSAccessKeyId=foo&Expires=bar&Signature=baz"。由于 Docker 客户端无法识别该文件，除非它被准确命名为“.dockercfg”，因此它无法看到身份验证凭据。

将 .dockercfg 文件直接传给每个从站

可以将 .dockercfg SCP 传送到每个 Mesos 从站。虽然这是一个快速修复，但它：

需要提前了解所有从站
不会随着新的从属服务器添加到集群而扩展
需要对从属设备进行 SSH 访问，这些从属设备是在它们自己的 VPC 中配置的（因此它们的 IP 地址通常在 10.0.[blah] 范围内）。

如果使用像 Chef 这样的配置管理工具自动化，这可以变成一种更可行的生产方法，该工具将在从属设备上运行，并将 .dockercfg 文件拉到正确的位置。

这将导致如下配置：

{
  ...
  "uris": ["file:///home/core/.dockercfg"]
  ...
}

因为 'core' 是基于 CoreOS 的 Mesos slave 上的默认用户，并且 .dockercfg 按照惯例应该位于想要使用 Docker 的当前用户的主目录中。

更新：这应该是最可靠的方法，但我还没有找到方法。就 Marathon 而言，该应用程序仍然永远停留在“部署”阶段。

使用密钥库服务

当我们处理用户名和密码时，AWS 密钥管理服务（甚至是极端情况下的 CloudHSM）似乎应该是一个好主意 - 但 AFAIK Mesos 对此没有内置支持，我们是不处理单个变量而是一个文件。

故障排除

在您设置好您选择的解决方案后，您可能会发现 .dockercfg 文件已被下拉，但您的应用仍停留在“部署”阶段。检查这些东西...

确保您的 .dockercfg 格式适合 Mesos Docker 版本

在某些时候，“auth”字段的格式发生了变化。如果您提供的 .dockercfg 与此格式不匹配，则 docker pull 将静默失败。集群 slave 上的 Mesos Docker 版本所期望的格式是：

{
  "https://index.docker.io/v1/": {
    "auth": [base64 of the username:password],
    "email": "your_docker_registry_user@yourdomain.com"
  }
}

不要为您的应用使用端口 80

如果您尝试部署 Web 应用程序，请确保您没有使用主机端口 80 - 它没有在文档中的任何地方编写，但 Mesos Web 服务本身需要端口 80，如果您尝试使用 80您自己的应用程序它将永远挂起。精明的读者会注意到，除其他原因外，这就是为什么 Mesosphere “Oinker” Web 应用程序改为绑定到稍微不寻常的端口 0 选择。

【讨论】：

您还可以在集群中部署一个简单的 S3 代理服务，以便使用标准 Mesos 提取器从受凭证保护的 S3 存储桶下载：github.com/adyatlov/s3proxy

【解决方案4】：

您可以在集群中部署一个简单的 S3 代理服务，以便使用标准 Mesos 提取器从受凭证保护的 S3 存储桶下载：github.com/adyatlov/s3proxy。不需要 HDFS 或其他存储机密信息。

【讨论】：