When I started working with Kubernetes and Infrastructure as Code, I quickly found out that I needed a secrets management solution, but when I googled around there didn’t seem to be a solid consensus on a best practice approach that could be universally applied to all situations. So, earlier this year I set a goal for myself to discover what application and infrastructure secret management solutions exist, come up with which one I thought was best and develop a working mastery of it. While pursuing this goal, I came to the conclusion that HashiCorp Vault is overhyped and Mozilla SOPS with KMS and Git is massively underrated. I think SOPS is underrated for two main reasons:
当我开始使用 Kubernetes 和基础设施即代码（Infrastructure as Code）时，我很快就发现我需要一个秘密管理解决方案，但当我在网上搜索时，似乎并没有就可普遍适用于所有情况的最佳实践方法达成一致意见。因此，今年早些时候，我为自己设定了一个目标，那就是探索现有的应用程序和基础架构秘密管理解决方案，找出我认为最好的解决方案，并在工作中加以掌握。在追求这个目标的过程中，我得出了这样一个结论：HashiCorp Vault 被过分夸大了，而带有 KMS 和 Git 的 Mozilla SOPS 则被严重低估了。我认为 SOPS 被低估主要有两个原因：

1. The majority of people don’t have a technical to layman’s-terms understanding of what a Cloud KMS is or does.
   大多数人对云 KMS 的含义和作用缺乏技术性和通俗性的了解。
2. Those same people don’t realize that although in the past there was no safe way to store encrypted secrets in Git, Cryptography has evolved since then, and now safely storing encrypted secrets in Git is possible thanks to Cloud Provider KMS Solutions such as AWS KMS, Azure KeyVault, or GCP KMS.
   这些人并没有意识到，虽然过去没有安全的方法在 Git 中存储加密机密，但密码学已经发展到了今天，有了云提供商的 KMS 解决方案（如 AWS KMS、Azure KeyVault 或 GCP KMS），在 Git 中安全存储加密机密已经成为可能。

Most of Vault’s hype is warranted as for decades there were no good secrets management solutions, and then here comes Vault from the makers of Terraform, with built-in secrets rotation, actively maintained over time, with great docs, support, and a community, and Vault was the only* solution that met my requirements for what the ideal secrets management solution looks like. I say Vault’s overhyped because I often see it recommended as the gold standard cure all that should be applied to all secrets management scenarios.
Vault的大部分炒作都是有道理的，因为几十年来一直没有好的秘密管理解决方案，后来Terraform的制造商推出了Vault，内置秘密轮换功能，长期积极维护，有很好的文档、支持和社区，Vault是唯一*能满足我对理想秘密管理解决方案要求的解决方案。我之所以说 Vault 被夸大了，是因为我经常看到它被推荐为适用于所有机密管理方案的黄金标准。

Ideal Secrets Management Solution Requirements
理想的秘密管理解决方案要求

1. Works universally (any cloud and on-prem)
   普遍适用（任何云和内部部署）
2. Integrates nicely with any tech stack via REST API or platform independent CLI binaries. (Bonus if it has smooth integrations with Terraform, Ansible, Kubernetes, and CICD Pipelines)
   通过 REST API 或独立于平台的 CLI 二进制程序与任何技术堆栈很好地集成。(如果能与 Terraform、Ansible、Kubernetes 和 CICD Pipelines 顺利集成，则更有优势）。
3. Future Proof  面向未来
   1. Open Source/Free (No risk of disappearing service offerings or price hikes)
      开放源码/免费（没有服务项目消失或价格上涨的风险）
   2. Large Community or a history of being maintained over time (Don’t want abandonware, unless it’s could be timeless/feature complete abandonware like Unix Utilities)
      大型社区或具有长期维护历史的软件（不需要废弃软件，除非是像 Unix 实用工具这样没有时间限制/功能齐全的废弃软件）。
   3. Scales well and offers High Availability
      良好的扩展性和高可用性
4. Truly secure (I should be able to convince any security head that it’s bulletproof enough to pass a security audit.)
   真正安全（我应该能让任何安全主管相信它刀枪不入，足以通过安全审计）。
   1. Encryption at Rest 静态加密
   2. Encryption in Transit 传输中加密
   3. Access should be revocable
      访问权限应可撤销
   4. Vulnerabilities should be pre-researched and countermeasures should be applied.
      应预先研究漏洞并采取应对措施。
5. Support for Granular ACLs + Dev secret creation self-service options
   支持细粒度 ACL + Dev 秘密创建自助服务选项
   1. Devs should be able to manage dev secrets but not prod secrets.
      开发人员应该能够管理开发机密，但不能管理产品机密。
   2. Ops should be able to manage dev and prod secrets.
      运营部门应该能够管理开发和生产部门的机密。
   3. Project level isolation: Ops of project A, shouldn’t see project B’s prod secrets.
      项目级隔离：项目 A 的运营人员不应该看到项目 B 的产品机密。
6. Versioned secrets (Can assist with staging and automating, deployments, rollbacks, and supporting technical debt scenarios where secrets and configuration are intertwined in config files and database connection strings.)
   版本化的机密（可协助进行暂存和自动化、部署、回滚，并支持机密和配置交织在配置文件和数据库连接字符串中的技术债务方案。）

*Note: Mozilla SOPS also met my requirements, but I didn’t realize it at the time because I originally thought there was no safe way to do git encrypted secrets.
*注：Mozilla SOPS 也符合我的要求，但我当时并没有意识到这一点，因为我原本以为没有安全的方法来实现 git 加密保密。

Security Challenges with storing secrets in a git repo
在 git 仓库中存储机密的安全挑战

• Many tools involve storing the decryption key in the user’s home directory or keyring, which leads to the encrypted data and the key being on the same machine.
  许多工具都将解密密钥存储在用户的主目录或钥匙圈中，这就导致加密数据和密钥在同一台机器上。
• In that scenario compromised decryption keys are a statistical inevitability (Vulnerabilities multiplied by clones of the repo multiplied by time)
  在这种情况下，解密密钥的泄露在统计学上是不可避免的（漏洞乘以克隆版本乘以时间）。
• It’s impossible to revoke a leaked decryption key. If you’re worried a decryption key could have been compromised, but the probability that it was compromised is low, revoking the key isn’t an option, due to git’s distributed history. Even if you could purge the history of the git server and re-encrypt all the secrets with new encryption keys, there would still exist a historic clone of the repo that could be decrypted with the old key.
  不可能撤销泄露的解密密钥。如果你担心解密密钥被泄露，但泄露的可能性很低，那么由于 git 的分布式历史，撤销密钥是不可能的。即使你能清除 git 服务器的历史记录，并用新的加密密钥重新加密所有机密，仍然会存在一个历史上的 repo 克隆，可以用旧密钥解密。
• If a compromise is suspected the only viable countermeasure is to rotate all the credentials, which is an expensive operation that management usually isn’t willing to back on a hunch.
  如果怀疑发生了入侵，唯一可行的对策就是轮换所有凭证，但这是一项昂贵的操作，管理层通常不会凭直觉支持。
• Some of the git encryption tools are footgun solutions: Run command to decrypt secret, then forget to encrypt it before pushing it up to the repo.
  有些 git 加密工具是 "脚枪 "式的解决方案：运行命令解密，然后在推送到 repo 之前忘记加密。

Whenever I found a secrets management solution I noticed I could group it into 4 main categories:
每当我发现一个秘密管理解决方案时，我都会注意到它可以分为四大类：

1. Specific to a single cloud provider (I dismissed these for reasons 1 and 3)
   仅限于单一云提供商（由于第 1 和第 3 条原因，我放弃了这些选项）
2. Specific to a single tech stack (Ansible, Chef, Puppet, Salt, Jenkins) (I dismissed these for reasons 2 and 5)
   针对单一技术堆栈（Ansible、Chef、Puppet、Salt、Jenkins）（由于第 2 和第 5 条原因，我放弃了这些技术堆栈）
3. Encrypted Git Repo (I dismissed these for reasons 4 and 5)
   加密的 Git Repo（由于第 4 和第 5 条原因，我放弃了加密的 Git Repo）
4. Roll your own Secrets Management Service (There were a few potentially viable options, but each introduced it’s own complexity so it made sense to focus on one. Hashicorp’s Vault was the clear winner given its number of features, documentation, big community, and track record for long term support and development.)
   推出自己的秘密管理服务（有几个潜在的可行方案，但每个方案都有其自身的复杂性，因此只需专注于一个方案即可。鉴于 Hashicorp 的 Vault 拥有众多功能、文档、庞大的社区以及长期支持和开发的记录，它显然是赢家）。

With my analysis complete, I spent a month of spare time working on a Vault Server for storing static secrets to help me gain a working mastery of Vault, I wanted it to be secure, easy to maintain, and easy to use. I did my best to achieve this by enabling TLS, adding Vault Configuration, Roles, Policies, and Kubernetes Infrastructure as Code for a highly available Vault/Consul Cluster to a git repo, using KMS auto unseal, writing good readme documentation, enabling versioned key-value store, LDAP authentication, the web GUI, and a third party desktop GUI called Cryptr by Adobe. While learning Vault I noticed many drawbacks to its usage:
分析完成后，我花了一个月的业余时间开发了一个用于存储静态机密的 Vault 服务器，以帮助我在工作中掌握 Vault，我希望它安全、易于维护且易于使用。为了实现这一目标，我尽力启用了 TLS，将 Vault 配置、角色、策略和用于高可用 Vault/Consul 集群的 Kubernetes 基础架构即代码添加到 git repo，使用 KMS 自动解封，编写良好的 readme 文档，启用版本化键值存储、LDAP 身份验证、Web GUI 和 Adobe 提供的名为 Cryptr 的第三方桌面 GUI。在学习 Vault 的过程中，我注意到了使用它的许多缺点：

1. Vault still needs a place to store its secrets. (Where does Vault store its Infrastructure as code secrets? HTTPS cert and IAM password for KMS Auto Unseal)
   Vault 仍需要一个存储其机密的地方。(Vault 在哪里存储基础架构作为代码的机密？用于 KMS 自动解封的 HTTPS 证书和 IAM 密码）
2. Vault’s very expensive in more ways than one. (You have to pay for infrastructure and storage. It’s not simple enough that you could set it up from scratch, write a readme, and train a few people on how to use it within an hour, using Infrastructure as Code and a premade readme in a git repo can help, but even then there’s still a lot to learn. Ops will need to spend time maintaining it with backups, upgrades, and monitoring. Devs need to spend time writing custom wrapper scripts to authenticate and pull the desired data.)
   保险库在很多方面都非常昂贵。(你必须支付基础设施和存储的费用。要在一小时内从头开始设置、编写自述文件并培训几个人如何使用它并不简单，使用 "基础设施即代码"（Infrastructure as Code）和 git repo 中的预制自述文件会有所帮助，但即便如此，仍有很多东西需要学习。运维人员需要花时间进行备份、升级和监控。开发人员需要花时间编写自定义封装脚本来验证和提取所需的数据）。
3. Vault makes life harder for people who need to store secrets, so they’ll avoid using it, which hurts its goal of being a central secrets repo. (Devs need to learn several new commands to interface with Vault or rely on slow Vault GUIs. The majority of preexisting tools are designed to interface with files on a file system. So using tools like vimdiff now require extra steps of logging in, fetching the secret, converting it to a file, and removing the file when done.)
   Vault 给需要存储秘密的人带来了困难，因此他们会避免使用 Vault，这就损害了 Vault 作为中央秘密存储库的目标。(开发人员需要学习几条新命令才能与 Vault 接口，或者依赖缓慢的 Vault GUI）。大多数现有工具都是为与文件系统中的文件连接而设计的。因此，现在使用 vimdiff 等工具需要登录、获取秘密、将其转换为文件并在完成后删除文件等额外步骤）。
4. The default implementation has a security vulnerability that’s expensive to secure. (If someone gets root access to a Vault Server, they can get the master decryption key by doing a memory dump. Hosting Vault on Kubernetes or Cloud VMs leads to more opportunities to get root access. In order to fully mitigate the risk of root access, you’d need to provision machines with Intel Software Guard Extensions, and run your Vault Servers on those in SCONE Security Enclaves (containers running in encrypted RAM). Adding these will add more infrastructure and research costs. Twistlock, Aqua, or SysDig are alternative options for partially mitigating this risk.)
   默认实现存在一个安全漏洞，要确保其安全代价高昂。(如果有人获得了 Vault 服务器的 root 访问权限，他们就可以通过内存转储获得主解密密钥。在 Kubernetes 或云虚拟机上托管 Vault 会带来更多获得 root 访问权限的机会。为了完全降低 root 访问风险，你需要为机器配置英特尔软件防护扩展，并在 SCONE 安全飞地（在加密 RAM 中运行的容器）中运行 Vault 服务器。增加这些功能将增加基础设施和研究成本。Twistlock、Aqua 或 SysDig 是部分降低这种风险的替代选择）。

Given these drawbacks, I decided to dive deeper and research further, that research lead me to Soluto’s Kamus where I was introduced to 2 cool concepts: GitOps and zero-trust secrets encryption. That got me leaping through a rabbithole of encryption techniques. At the end of the journey I came up with the following mental schema.
鉴于这些弊端，我决定深入研究，并在研究中发现了 Soluto 的 Kamus，在那里我了解到了两个很酷的概念：GitOps 和零信任机密加密。这让我跃入了加密技术的兔子洞。最后，我总结出了以下思维模式。

Abridged Evolution of Cryptography
密码学发展简编

1.) Symmetric Encryption Keys:
1.)对称加密密钥：

• Long password is used for both encryption and decryption.
  长密码用于加密和解密。

2.) Asymmetric Encryption Public-Private Key Pairs:
2.)非对称加密公私密钥对：

• Public key encrypts data, private key decrypts data encrypted with the public key.
  公用密钥加密数据，私人密钥解密用公用密钥加密的数据。

3.) HSMs (Hardware Security Modules):
3.)HSM（硬件安全模块）：

• Make it so the private key doesn’t get leaked.
  确保私钥不会泄露。
• HSMs are expensive. HSM 价格昂贵。
• HSMs are not user or automation friendly.
  HSM 对用户或自动化都不友好。

4.) Cloud KMSs (Key Management Services):
4.)云 KMS（密钥管理服务）：

• KMS is a trusted service that encrypts and decrypts data on behalf of clients, it basically allows a user or machine to encrypt and decrypt data using their identity instead of encryption/decryption keys. (A client authenticates against a KMS, which checks their identity against an ACL, if they have decryption rights, the client can send encrypted data in a request to the KMS, which will then decrypt the data on behalf of the client, and send the decrypted data back to the client over a secure TLS tunnel.)
  KMS 是一种代表客户对数据进行加密和解密的可信服务，它基本上允许用户或机器使用自己的身份而不是加密/解密密钥对数据进行加密和解密。(客户通过 KMS 进行身份验证，KMS 会根据 ACL 检查客户的身份，如果客户有解密权限，客户就可以向 KMS 请求发送加密数据，KMS 会代表客户解密数据，并通过安全的 TLS 隧道将解密数据发送回客户）。
• KMSs are cheap. KMS 很便宜。
• KMSs are exposed via REST API, which makes them user and automation friendly.
  KMS 通过 REST API 公开，因此对用户和自动化都很友好。
• KMSs are extremely secure, they make it feasible to go a decade without leaking decryption keys.
  KMS 非常安全，可以做到十年不泄露解密密钥。
  • KMS encryption technique’s invention introduced 3 killer pieces of functionality:
    KMS 加密技术的发明引入了三大杀手级功能：
    1. When responding to a known breach: Before KMS decryption keys would get leaked: you can’t revoke a decryption key, which means you’d need to rotate several decryption keys, re-encrypt all data with the new keys, and try your best to purge old encrypted data. While doing all of this you’ll need to fight with management to get approval to cause downtime to several production systems, minimize said downtime, and even if you do everything right, you may be unable to completely purge the old encrypted data, like in the case of git history, and backups. After KMS it’s identity credentials that get leaked: Identity credentials can be revoked, when they’re revoked they’re worthless. The nightmare of re-encrypting data and purging old encrypted data goes away. You still need to rotate secrets (identity credentials vs decryption key), but the act of rotation becomes cheap enough that it can be automated and scheduled as a preventative measure.
       应对已知漏洞时：在 KMS 解密密钥泄露之前：您无法撤销解密密钥，这意味着您需要轮换多个解密密钥，使用新密钥重新加密所有数据，并尽力清除旧的加密数据。在做这一切的时候，你需要与管理层沟通，以获得批准，从而导致多个生产系统宕机，并尽量减少宕机时间，而且即使你做对了一切，也可能无法完全清除旧的加密数据，比如 git 历史记录和备份。KMS 之后，身份凭证也会泄露：身份凭证可以被撤销，一旦被撤销就一文不值。重新加密数据和清除旧加密数据的噩梦也就不复存在了。你仍然需要轮换机密（身份凭据与解密密钥），但轮换的成本变得足够低，可以作为预防措施自动安排。
    2. Management of encrypted data shifts from an impossible task involving distributed decryption keys, to a trivial task of managing a centralized ACL. It now becomes possible to easily revoke, edit, and assign granular access to encrypted data; and as a bonus since Cloud KMS, IAM, and SSO Identity Federations integrate together, you can leverage preexisting user identities.
       加密数据的管理从涉及分布式解密密钥的不可能任务转变为管理集中式 ACL 的琐碎任务。现在，可以轻松撤销、编辑和分配对加密数据的细粒度访问权限；此外，由于云 KMS、IAM 和 SSO 身份联盟集成在一起，您还可以利用已有的用户身份。
    3. Crypto Anchoring techniques become possible:
       加密锚定技术成为可能：
       • Network ACLs can be applied to KMS to make it so data can only be decrypted in your environment.
         网络 ACL 可应用于 KMS，使数据只能在环境中解密。
       • KMS decryption rates can be monitored for a baseline, when an anomalous rate occurs, alerts and rate limiting can be triggered.
         可以监控 KMS 的解密率基线，当出现异常率时，可以触发警报和限制率。
  • KMS’s decryption keys can be secured by an HSM.
    KMS 的解密密钥可由 HSM 保护。
  • Opportunities for decryption keys to get leaked are near zero because clients don’t interact directly with decryption keys.
    由于客户不会直接与解密密钥交互，因此解密密钥泄露的机会几乎为零。
  • Cloud Providers can afford to hire the best security professionals and implement expensive operational processes that are required to keep the backend systems as secure as possible, so backend key leakage opportunities are also near zero.
    云提供商有能力聘请最好的安全专业人员，并实施昂贵的操作流程，以尽可能保证后端系统的安全，因此后端密钥泄漏的机会也接近于零。

My new understanding of advanced encryption techniques lead me to realize that KMS could be leveraged to prevent decryption keys from being leaked. That plus the ability to revoke decryption rights without needing to make any changes to encrypted files makes truly secure encrypted files in Git a reality. I revisited a few Git based encryption solutions I’d previously dismissed and discovered that Mozilla SOPS satisfied all of my criteria for an ideal secrets management solution. It also integrates well with CICD pipeline tools: There’s a SOPS Terraform Provider, Helm Secrets is just a wrapper for SOPS, and you can always fallback to:
对高级加密技术的新认识让我意识到，可以利用 KMS 来防止解密密钥泄露。再加上无需对加密文件做任何改动就能撤销解密权限的功能，Git 中真正安全的加密文件就成为了现实。我重新审视了之前否定的几个基于 Git 的加密解决方案，发现 Mozilla SOPS 满足了我对理想秘密管理解决方案的所有标准。它还能与 CICD 管道工具很好地集成：它有一个 SOPS Terraform Provider，Helm Secrets 只是 SOPS 的一个封装器，而且你可以一直使用它：

Bash# sops --decrypt mysecret.yaml | kubectl apply -f -

(where kubectl could have been any CLI Utility that accepts standard input (-)) SOPS has none of the drawbacks of other Git based encryption solutions: One of the footguns in other Git based encryption solutions was that someone could accidentally push a decrypted secret to the git repo. With SOPS when you want to edit a file, the file stays encrypted on disk, gets decrypted in RAM where you can edit it with vim, and when you save the edited file it gets re-encrypted before being written to disk. At the same time, it does offer the flexibility to quickly decrypt a few files so you can use a tool like vimdiff. SOPS has none of the drawbacks of Vault: It doesn’t require infrastructure and it’s as cheap as KMS. You could easily set it up, train a few people, and write a readme file within an hour, here’s an example of how easy it is to setup and use:
(其中 kubectl 可以是任何接受标准输入 (-) 的 CLI 工具）。SOPS 没有其他基于 Git 的加密方案的缺点：其他基于 Git 的加密解决方案的一个弊端是，有人可能会不小心将解密后的秘密推送到 git 仓库。有了 SOPS，当你想编辑文件时，文件会在磁盘上加密，然后在 RAM 中解密，你可以用 vim 编辑它，当你保存编辑过的文件时，它会在写入磁盘前重新加密。同时，它还能灵活地快速解密一些文件，以便使用 vimdiff 等工具。SOPS 没有 Vault 的缺点：它不需要基础设施，而且和 KMS 一样便宜。你可以在一小时内轻松设置好它，培训几个人，并编写一份自述文件，下面的例子就说明了它的设置和使用有多简单：

Bash# aws kms create-key --description "Mozilla SOPS” | grep Arn

"Arn": "arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb",

Bash# cd $repo

Bash# vim .sops.yaml

(Create a file named .sops.yaml, with the following 2 lines of text)
(创建一个名为 .sops.yaml 的文件，其中包含以下两行文字）

creation_rules:
- kms: 'arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb'

Bash# sops mysecret.yaml

This will open the vim editor so you can type what you want to store in the secret. This simple command is used to both create and edit files.
这将打开 vim 编辑器，以便输入要存储在秘密文件中的内容。这个简单的命令既可用于创建文件，也可用于编辑文件。

Bash# cat mysecret.yaml

Will show you an encrypted yaml
将向您显示加密的 yaml

Bash# sops --decrypt mysecret.yaml

Will show you the decrypted yaml SOPS will use your AWS credentials stored in ~/.aws to authenticate against KMS so you can encrypt and decrypt without a password. SOPS will also recursively look for .sops.yaml files so it’ll auto discover metadata about how it should encrypt and decrypt things, which has two important ramifications: first, a user doesn’t have to learn a ton of commands or flags. Second, an additional .sops.yaml file can be added to a subfolder representing a production environment or different project, that .sops.yaml file could have a different encryption/decryption key. You could give different Cloud IAM users different rights to each KMS key, to achieve granular access control. If you’re worried about someone deleting your AWS KMS key you can configure SOPS so the data can be encrypted or decrypted by AWS, GCP, or Azure KMS solutions, so you can keep a secondary backup KMS that few people have access to. SOPS encourages workflows patterns that make life easier. Devs can store their secrets encrypted right next to and in sync with the version of the code that uses it. Secrets management suddenly gains all the benefits of git: auditable change management, peer reviews via pull requests, diffs of edits to secrets are meaningful because only edited values will get updated on edits, vs the entire file getting re-encrypted, this also makes merge conflicts less likely. Consistency and standardization always make automation and CICD Pipeline development easier, which makes the Ops folks happy. SOPS allows code, configuration, and secrets to be stored in a consistent location, which makes GitOps workflows easier to achieve. Hashicorp Vault will have trouble achieving its goal of being a centralized secret repo for your organization because users will find it hard to use, devops will find it troublesome to maintain, and management could find it expensive. SOPS, on the other hand, is pain-free to use, easy to learn, cheap to maintain, and supports workflow patterns that make life easier! These things together mean as long as someone can pitch it to the organization, there will be no barriers to adoption, which means an increased security posture for the entire organization is more likely to occur. This is why SOPS with KMS and Git is massively underrated. I’d like to clarify that the purpose of this article isn’t to say Vault’s bad and you should use SOPS and KMS instead. I wrote this article for 3 reasons: One, I love to teach. Two, I wanted to point out some shortcomings of Vault. Three, KMS with SOPS is an amazing combo that’s massively underrated: no one seems to know about it, I never encountered a proper explanation of either during my research, and according to Google Trends there are not many searches of SOPS compared to Vault. I’d like to end this article by saying that I wholeheartedly recommend everyone learn SOPS, KMS, and Vault. Why learn Vault if it’s hard and SOPS with KMS does the same thing with ease? Two reasons really: One, Vault is among the best in class when it comes to PKI and secrets rotation, both of which can be needed to satisfy many government and banking security compliance standards. Two, Vault gets easier to use every year: The community has accepted it as a clear winner and added Vault support into several products: Jenkins, cert-manager, and Kubernetes. Kubernetes, in particular, works nicely with Vault, a lot of the pain points have been abstracted and automated to the point where they are worth together smoothly. The Vault team also has a proven track record of being committed to making Vault easier to use over time by improving documentation, offering some IaC, and responding to the needs of the community: After the community-made auto unseal solutions, backend storage migration solutions, and 3rd party web GUIs; Vault’s Developers decided to bake these functionalities into the open-source version. Given this, it wouldn’t surprise me if in the future Vault’s Transit Secrets Engine (Vault’s KMS solution) was made to integrate smoothly with Mozilla SOPS.
将向你显示解密后的 yaml SOPS 会使用存储在 ~/.aws 中的 AWS 凭据来验证 KMS，这样你就可以在没有密码的情况下进行加密和解密。SOPS 还会递归查找 .sops.yaml 文件，以便自动发现有关加密和解密方式的元数据，这有两个重要影响：首先，用户无需学习大量命令或标记。其次，可以在代表生产环境或不同项目的子文件夹中添加额外的 .sops.yaml 文件，该 .sops.yaml 文件可以拥有不同的加密/解密密钥。您可以赋予不同的云 IAM 用户对每个 KMS 密钥的不同权限，以实现细粒度的访问控制。如果你担心有人删除你的 AWS KMS 密钥，你可以配置 SOPS，让 AWS、GCP 或 Azure KMS 解决方案对数据进行加密或解密，这样你就可以保留一个很少有人能访问的辅助备份 KMS。SOPS 鼓励工作流模式，让生活更轻松。开发人员可以将机密加密存储在使用该机密的代码版本旁边，并与之同步。秘密管理突然获得了 git 的所有好处：可审计的变更管理、通过拉取请求进行同行评审、对秘密的编辑差异是有意义的，因为只有编辑过的值才会在编辑时更新，而不是整个文件都被重新加密，这也降低了合并冲突的可能性。一致性和标准化总是能让自动化和 CICD 管道开发变得更容易，这也会让运行人员感到高兴。SOPS 允许将代码、配置和机密存储在一个一致的位置，这使得 GitOps 工作流程更容易实现。Hashicorp Vault 很难实现成为企业集中式秘密存储库的目标，因为用户会觉得难以使用，开发人员会觉得维护麻烦，管理层会觉得成本高昂。另一方面，SOPS 不但使用简单、易学、维护成本低，而且支持工作流程模式，让生活更轻松！这些优点加在一起，意味着只要有人能向组织推荐它，就不会有采用的障碍，这意味着整个组织更有可能提高安全态势。这就是为什么带有 KMS 和 Git 的 SOPS 被严重低估的原因。我想说明的是，本文的目的并不是说 Vault 不好，你应该使用 SOPS 和 KMS。我写这篇文章有三个原因：第一，我喜欢教学。第二，我想指出 Vault 的一些缺点。第三，KMS与SOPS是一个神奇的组合，但却被严重低估了：似乎没有人知道它，我在研究过程中从未遇到过对两者的适当解释，而且根据谷歌趋势，与Vault相比，SOPS的搜索量并不多。 在本文的最后，我想说，我衷心建议大家学习 SOPS、KMS 和 Vault。如果 Vault 很难学，而 SOPS 和 KMS 可以轻松完成同样的工作，那为什么还要学呢？其实有两个原因：其一，Vault 在 PKI 和机密轮换方面是同类产品中最好的，这两项功能都能满足许多政府和银行的安全合规标准。其二，Vault 每年都变得更容易使用：社区已将其视为当之无愧的赢家，并在多个产品中添加了对 Vault 的支持：Jenkins、cert-manager 和 Kubernetes。尤其是 Kubernetes，它与 Vault 配合得非常好，很多痛点都已被抽象和自动化，使它们能够顺利地结合在一起。Vault 团队也一直致力于通过改进文档、提供一些 IaC 和响应社区需求来使 Vault 更好用：在社区推出自动解封解决方案、后端存储迁移解决方案和第三方网络图形用户界面之后，Vault的开发人员决定将这些功能纳入开源版本。有鉴于此，如果将来 Vault 的 Transit Secrets Engine（Vault 的 KMS 解决方案）能与 Mozilla SOPS 平滑集成，我也不会感到惊讶。

Oteemo thanks you for reading this post, if you want to find out more as to DoD Iron Bank services, DevSecOps adoption or Cloud Native Enablement, contact us by submitting our form via our website.
Oteemo 感谢您阅读这篇文章，如果您想了解更多有关 DoD Iron Bank 服务、DevSecOps 采用或云原生启用的信息，请通过我们的网站提交表单与我们联系。

We will be happy to answer all your questions, especially the hard ones!
我们很乐意回答您的所有问题，尤其是疑难问题！