在云平台上存储 Secret
翻译自：
TURTLES ALL THE WAY DOWN - Storing Secrets in the Cloud and in the Data Center
Daniel Somerfield
引言
乌龟的梗是这么来的：某次霍金发表了一个关于宇宙起源的演讲，有个老太太说，你讲的都是 rubbish，宇宙是一个大乌龟扛着的！有人问，那这个乌龟站在哪里呢？老太太说，你傻叉吗，乌龟站在另一个更大的乌龟上。
这个解释恰好也是 Secret Store 面临的一个问题。数据通过密钥来保护，那密钥通过什么来保护呢？通常我们别无选择，只能再设置一个 Master Key 来加密密钥。更 General 地说，每次我们试图把一个东西弄得安全，都不得不假设假设另一个东西（例如Master Key，信道，etc.）是安全的。
似乎是无解的。那应该怎样做？这就是以下要讨论的。
目标
Security Goals
- Secrets are secrets Secret 应该以加密的方式存储
- Auditing 所有的访问和操作都应该被记录，以便出问题时审查
- No reliance on heroes 不能让整个系统依赖某一个人（比如某个 DBA）
- Standard practices 遵守某些既定的业界标准，比如协议、算法等。但这不是让你在 Github 上随便下载一个开源工具，就以为他已经身经百战了，Naive!
Operational Goals
- Automated 可以自动化部署，就像其他的任何组件一样
- Scales operationally 在数据量慢慢变大以后，也有方法能应对这种变化
Easy to Use
它一定要容易被别的开发者所使用，不然占用的都是自己的时间。这一点对于任何组件的开发同样适用。
第一只乌龟
首先，不管那么多了——Secret 需要是安全的。目标：
- Secrets 是加密的
- 受权限控制的分发
- 自动化地部署到应用程序
策略1： orchestrator decryption
如果你用了 Git-crypt 或者 ansible vault 那你多数是这种情况。
优势：
- 容易管理 Key，因为是集中存放在 orchestrator
- 容易和现有的 orchestration 工具集成
缺点：
- 所有的东西都依赖于 orchestrator，有风险
- 会导致产生很多不用的 Secret
- 更多的“乌龟”，Provision可靠吗？传输信道可靠吗？
策略2：application decryption
优势：
- orchestrator 和 Secret Store 解耦
- 容易和现有的 orchestration 工具集成
缺点：
- Key 管理不那么容易
- 会导致产生很多不用的 Secret
- 更多的“乌龟”，Provision可靠吗？传输信道可靠吗？
策略3：operational compartmentalization
优势：
- 清晰的责任划分
- 容易和现有的 orchestration 工具集成
缺点：
- 清晰的划分也导致了组织孤岛（organizational silos）
- 缺少透明性
实现上述策略的工具
1. SCM 加密
加密整个 Source Repo，或者只加密相关的项目。
优点：
- 容易集成
- 审计（audit）可以基于 SCM
缺点：
- 缺少 Secret 滚动功能
- Data at rest
- 缺少 usage 信息的 audit
- 更多的乌龟
相关工具：
- Blackbox
- GitCrypt
- Transcrypt
（未完）