TiKV 使用 AWS 的 KMS 服务进行静态加密，如何安全通过 AWS 的认证？

[musenwill]

【概述】 场景 + 问题概述

我想开启 TiKV 的静态加密功能，并使用 AWS 提供的 KMS 服务。

问题是配置中可以配置 key-id, region, endpoint 字段告诉 TiKV 如何检索到 KMS 中存储的密钥，但却没有告诉 TiKV 如何拿到 AWS 的访问凭证以通过 AWS 的认证。

AWS 的访问凭证也属于机密信息，确实不应该通过配置的方式提供给 TiKV，这样不安全，但文档完全没有提到如何以安全的方式去处理这个问题。

【问题】 当前遇到的问题

不知道该如何以安全的方式将 AWS 的访问凭证提供给 TiKV 服务，以支持 TiKV 使用 AWS 的 KMS 进行静态加密。

【TiDB 版本】
TiKV v4.0.0

[yilong (yi888long)]

如果是使用 binary 部署，则让 ec2 获取到访问 KMS 的权限， https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-metadata.html 这样不会暴露你的 AKSK 只要 node 没有被侵入，密码就是安全的， 如果用的 eks ， 则可以用 eks 的 serviceaccount 方案。https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html， 如果是自建的， 那么推荐使用 kube2iam

[musenwill]

kube2iam 也需要 AWS 的 credentials 去访问 AWS 的 KMS 服务，而根据 AWS 的文档描述，该 credentials 也是直接以环境变量、配置等明文方式提供的，credentials 也有暴露的风险。

其实我关注的根本问题是 TiDB 静态加密是如何保证安全的？

数据库实现静态加密是基于一个前提，即攻击者有能力登录数据库所在的机器。如果攻击者都没有能力访问存储数据的机器，那自然也就没有对数据静态加密的需要了。

那么 TiDB 是如何保证即便在攻击者登录数据所在的机器时，也无法得到密钥的？
现有的所有配置方案似乎都无法阻止攻击者得到密钥。而我能想到的唯一可行的方式是在数据库启动时以交互模式人工输入密钥；或者在数据库启动后立即阻断对密钥的访问途径。

[aylei]

@musenwill

数据静态加密的安全边界在于：当数据文件泄露，而密钥未泄露时，真实数据将不会泄露。

因此数据文件和密钥的安全性需要独立分析，二者之间没有必然联系。以基于 AWS KMS 的 TiKV 静态加密为例，主密钥永远不会离开 KMS，安全性由 AWS 保证，TiKV 解密数据文件时需要持有 KMS 的相关权限，把数据密钥发送给 KMS 解密（详见信封加密）。那么：

• 假如攻击者依赖漏洞获取了数据文件：没有能力解密，真实数据不会泄漏
• 假如攻击者获取了数据文件，同时获取了访问 KMS 的权限（情况一：获取了 TiKV 所在 EC2 的 root 权限，依赖 EC2 metadata 服务获取 AWS 权限；情况二：盗取了静态的 AWS AK SK）：此时攻击者有能力解密，但 DBA 可以通过切断对目标 EC2 或 AK SK 的 KMS 授权来取消攻击者的解密能力
• 假如攻击者获取来数据文件，同时盗取了 AWS 的根账号权限：此时攻击者有能力解密，DBA 也无法通过 AWS 撤消攻击者盗取的授权，真实数据将泄漏

这个例子可以推广到其它场景，静态加密是实现安全体系的一个可选工具，而安全方案的投入时无上限的，最终需要根据投入产出比确定一个折衷。