我用 juju 管理一些部署。然而，我不是孤岛，我有同事也想管理共享环境。
我知道我可以使用以下节~/.juju/environments.yaml让人们访问我的 juju 环境：
authorized-keys: [and then put their ssh IDs in here]
还有哪些其他最佳实践可用于管理具有多个系统管理员的多个环境？
小智 3
Juju 目前确实没有针对多个管理员进行优化。特别是，当前 Juju 中出现的一些安全问题在与多个管理员合作时变得更加明显。然而，尽管有一些警告，这对于受信任的（因此可能是一小群）管理员来说仍然是一个有用的选择。
考虑到这一点，我们来看看文件中的相关配置项~/.juju/environment.yaml。
该authorized-keys项目在环境引导中使用，为引导节点（运行 ZooKeeper 的机器 0）和所有后续配置的节点上的 ubuntu 用户定义公共 SSH 密钥。只需在每行列出一个授权的公钥即可。它将如下所示：
authorized-keys: |
ssh-rsa AAAblahblahZZZZ user@domain
ecdsa-sha2-nistp256 AAAAfoobarZZZZ= user2@domain
这种方法优于使用authorized-keys-path- 或其默认值 ( ~/.ssh/) - 它仅适合一个管理员，因为您必须共享 SSH 密钥（不要这样做！）。简而言之，这只是authorized-keys-path实现方式的限制。
接下来，云提供商定义其特定的安全凭证，然后 Juju 使用该凭证。举例来说，让我们看一下 EC2，特别是 AWS。对于 AWS，使用两个键来确定访问权限：
access-key和secret-key，对应于环境变量
AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY（如果未在配置文件中指定，则这些是默认值）。对于多管理环境（甚至是单一管理环境）来说，这里的挑战是这些信息被复制到 ZooKeeper 并在 ZK 节点中清晰可见/environment。请参阅 Juju bug #907094。
在 AWS 示例中，可以通过使用 AWS Identity and Access Management FAQ（搜索此内容）对访问密钥提供某种程度的控制，但目前没有机制可以为给定管理员提供更细粒度的控制。 Juju 环境。
在我们自己的使用中，尤其是在测试中，还有一个值得注意的模式：在给定节点上设置一个 Juju 环境（“控制”）来控制其他 Juju 环境；只需部署juju 符咒
即可完成此设置。它需要作为配置选项
environment.yaml来使用。然后可以ubuntu通过手动将其密钥添加到 来将其他管理员授权为用户
~ubuntu/.ssh/authorized-keys。
这样可以通过一个点来管理其中一些问题，同时最大程度地减少麻烦。它对于解决前面提到的一些安全问题没有任何作用 - 您仍然必须对其他管理员有相当深的信任。
Juju 将在使用某些命令（、、
、、 ）时重新同步environments.yaml到 ZK 节点。在实践中，这不会很有用——除了其真正的预期用途，即支持约束。但是，它可以帮助最大限度地减少更新授权密钥文件的需要，因为同步后任何新配置的计算机都会获得该文件；然后您只需负责更新早期配置的计算机即可。/environmentjuju add-unitjuju constraints-getjuju constraints-setjuju deployjuju terminate-machine
当我谈到这一点时，值得注意的是 in 的
~ubuntu/.ssh/authorized-keys实际使用方式和位置：
除两个例外外，所有 Juju 控制命令都使用到 ZooKeepeer 实例的 SSH 隧道来管理或查找来自 Juju 环境的信息。（juju bootstrap并juju destroy-environment
直接与底层云提供商 API 配合使用。）因此，您肯定需要保持authorized-keys机器 0 上的最新。
juju ssh并juju scp允许直接使用计算机，并且它们还需要具有当前的状态authorized-keys，您必须考虑在多个管理情况下进行更新。这些命令默认使用ubuntu目标计算机上的用户。