在云平台上存储 Secret

翻译自:

TURTLES ALL THE WAY DOWN - Storing Secrets in the Cloud and in the Data Center

Daniel Somerfield

Homepage | YouTube | Slides

引言

乌龟的梗是这么来的:某次霍金发表了一个关于宇宙起源的演讲,有个老太太说,你讲的都是 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

(未完)