本文共 13193 字，大约阅读时间需要 43 分钟。
kms服务器管理
by Ramesh Lingappa
通过拉梅什·林加帕(Ramesh Lingappa)
Let’s jump right in. We all know it’s a bad idea to store application secrets within our code. So why we are storing there it still? Let’s take an example.
让我们直接进入。我们都知道在我们的代码中存储应用程序秘密是一个坏主意。 那么，为什么我们仍将其存储在那里？ 让我们举个例子。
We could store those secrets in a file and add it to the gitignore so it’s not added to version control. But there are a couple of hurdles:
我们可以将这些秘密存储在文件中，并将其添加到gitignore中，这样就不会将其添加到版本控制中。 但是有两个障碍：
A lot of questions! So we end up storing it within the code, since it’s too much complexity to deal with.
有很多问题！ 所以我们最终将其存储在代码中，因为它处理起来太复杂了。
For a big application or application which needs a higher level of security, we can use Production grade secret management services like .
对于大型应用程序或需要更高安全性的应用程序，我们可以使用生产级秘密管理服务，例如 。
In this article, we will look at a decent approach in dealing with secrets while still achieving better security. We are going to achieve this using Google KMS + Git + IAM+ automation.
在本文中，我们将研究一种处理机密信息的方法，同时仍能实现更好的安全性。 我们将使用Google KMS + Git + IAM +自动化来实现这一目标。
The idea is not new. This is what we are going to do:
这个想法并不新鲜。 这是我们要做的：
is a cloud-hosted key management service that lets you manage cryptographic keys for your cloud services. You can generate, use, rotate, and destroy cryptographic keys. Cloud KMS is integrated with Cloud IAM and Cloud Audit Logging so that you can manage permissions on individual keys and monitor how these are used.
是一种云托管的密钥管理服务 ，可让您管理云服务的加密密钥。 您可以生成，使用，旋转和销毁加密密钥。 Cloud KMS与Cloud IAM和Cloud Audit Logging集成在一起，因此您可以管理各个密钥的权限并监视其使用方式。
So Cloud KMS will encrypt and decrypt our secrets so we don’t have to store the keys. Only an authorised user or a service account can perform encrypt or decrypt operations.
因此，Cloud KMS将加密和解密我们的秘密，因此我们不必存储密钥。 只有授权用户或服务帐户才能执行加密或解密操作。
Let’s get started!
让我们开始吧！
For our use-case, we are going to have application secrets for each environment, prod stag and dev . We do so by creating a new folder called credentials under the root project folder and then create one folder for each environment.
对于我们的用例，我们将为每种环境， prod stag和dev拥有应用程序的秘密。 为此，我们在根项目文件夹下创建一个名为credentials的新文件夹，然后为每个环境创建一个文件夹。
Make sure this folder is not tracked under version control by adding the following line in the .gitignore file:
通过在.gitignore文件中添加以下行，确保不在版本控制下跟踪此文件夹：
/credentials/
Here I am using a properties file, but it could be anything like JSON, YAML etc. Now you can add any sensitive information in these files. I have added the following:
在这里，我使用的是属性文件，但可能是JSON，YAML等。现在您可以在这些文件中添加任何敏感信息。 我添加了以下内容：
# dev credentialsoauth_client_id=1234oauth_client_secret=abcdapi_key=api_123# ...
Okay, our secrets are ready for hiding.
好吧，我们的秘密已经准备好隐藏了。
We need to create encryption keys for each environment in order to use this service. For us, each environment will be a different google cloud project (recommended). It’s better this way since it gives isolation and access control (more on this later).
为了使用此服务，我们需要为每个环境创建加密密钥。 对于我们来说，每个环境都是一个不同的Google Cloud项目(推荐)。 这样比较好，因为它提供了隔离和访问控制(稍后会有更多介绍)。
So go ahead and create a key for each environment using this link . It has step by step instructions (different ways) to create those keys. We are creating those keys using the command line like below:
因此，继续使用此链接为每个环境创建一个密钥。 它具有分步说明(不同方式)来创建这些键。 我们正在使用以下命令行创建这些键：
// create key-ring (think of this as grouping)gcloud kms keyrings create [KEYRING_NAME] \--location [LOCATION] \--project live-project-id
// create the encryption keygcloud kms keys create [KEY_NAME] \--location [LOCATION] \--keyring [KEYRING_NAME] \--purpose encryption \--project live-project-id
Here I am creating a key for production using the production project id. Repeat this process for each environment by replacing the Project ID for stag and other environments.
在这里，我使用生产项目ID为生产创建密钥。 通过替换stag和其他环境的Project ID对每个环境重复此过程。
Note: You need to have four pieces of information for each key: location keyring cryptokey and project. This information is not sensitive so you can store it in your code or build scripts
注意 ：每个密钥需要具有四个信息： location keyring cryptokey和project 。 此信息不敏感，因此您可以将其存储在代码中或构建脚本
Here comes the beauty of the KMS IAM system: in order to use each key, we need to explicitly grant access for an individual user or a service account. This makes it very powerful since now we can define who can manage secrets, who can view those secrets, and more.
KMS IAM系统的优点就在于此：为了使用每个密钥，我们需要为单个用户或服务帐户显式授予访问权限。 这使它变得非常强大，因为现在我们可以定义谁可以管理机密，谁可以查看这些机密等等。
Check out for more information. With this, we can achieve the following:
请参阅获取更多信息。 这样，我们可以实现以下目标：
No one should be able to see the secrets except the few people who can make changes to secrets. We can do so by granting them the role:
除了少数可以更改秘密的人之外，没有人应该能够看到秘密。 我们可以通过授予他们以下角色来做到这一点：
cloudkms.cryptoKeyEncrypterDecrypter
So in this way, even though the encrypted credentials are stored in version control, other developers won't be able to use them. Note, even those developers can make live deployments without ever needing to know the secrets (more on this later).
因此，以这种方式，即使加密的凭据存储在版本控制中，其他开发人员也将无法使用它们。 请注意，即使是那些开发人员也可以进行实时部署，而无需知道秘密(稍后会详细介绍)。
Every developer can see the secrets and use them in development, but only a few people can make changes to secrets. We can do so by granting them the role:
每个开发人员都可以看到秘密并在开发中使用它们，但是只有少数人可以更改秘密。 我们可以通过授予他们以下角色来做到这一点：
// for read onlycloudkms.cryptoKeyDecrypter
// for managingcloudkms.cryptoKeyEncrypterDecrypter
Likewise, you can grant key roles for different environments depending on the need. For the exact commands, refer to in the docs.
同样，您可以根据需要为不同的环境授予关键角色。 有关确切的命令，请参阅文档中的 。
We are done with prep work, and now it’s time to hide some secrets. Assuming you have the encrypter role, with that you can encrypt a file using the following command:
准备工作已经完成，现在该隐瞒一些秘密了。 假设您具有加密角色，可以使用以下命令对文件进行加密：
gcloud kms encrypt --location global \ --keyring secrets-key-ring --key quickstart \ --plaintext-file credentials/stag/credentials.properties \ --ciphertext-file credentials-encrypted/stag/credentials.properties.encrypted
Since it’s a shell gcloud command, you can easily integrate it with any build system to encrypt all files under the credentials folder. For example, I am using gradle for this:
由于它是shell gcloud命令，因此您可以轻松地将其与任何构建系统集成，以对凭据文件夹下的所有文件进行加密。 例如，我为此使用gradle ：
Basically, there are two helper functions:
基本上，有两个辅助函数：
kmsEncryptSecrets takes the src folder to encrypt each file within it and write it to the target folder with .enc (encrypted) extension, and
kmsEncryptSecrets使用src文件夹加密其中的每个文件，并将其写入扩展名为.enc (加密)的目标文件夹 ，然后
kmsDecryptSecrets which does the reverse process.
kmsDecryptSecrets执行相反的过程。
So each time we modify secrets, you can call the encrypt helper method with a simple task:
因此，每次我们修改机密时，您都可以通过一个简单的任务来调用crypto helper方法：
Now the encrypted folder will look like below:
现在，加密的文件夹将如下所示：
This folder can be added to version control so each time an authorised user changes secrets, a new encrypted file is generated and logs the history in version control.
该文件夹可以添加到版本控制中，因此，每当授权用户更改秘密时，都会生成一个新的加密文件，并将历史记录记录在版本控制中。
Similarly, there is a for the reverse process.
同样，逆向过程也有一个 。
Now that we are done encrypting secrets and properly managing them in version control, let's look at how it can be used at runtime, meaning when the app is actually running in staging or production. We can do that in two ways:
现在，我们已经完成了对机密的加密并在版本控制中对其进行了适当的管理，让我们看一下如何在运行时使用它，这意味着该应用程序实际在登台或生产中运行时。 我们可以通过两种方式做到这一点：
So during deployment, an authorised user can simply decrypt those encrypted secrets and add it to the deployment (eg: build directory), thus making it available for the code at runtime. We are not going to cover this deeply.
因此，在部署期间，授权用户可以简单地解密那些加密的机密并将其添加到部署中(例如：构建目录)，从而使其在运行时可用于代码。 我们不会对此进行深入介绍。
This approach is good when deployer needed to be very restrictive or process is automated using CD pipeline.
当部署人员需要严格限制或使用CD流水线使流程自动化时，此方法很好。
Here we are not going to decrypt and send raw secrets during deployment. Instead, we are simply passing encrypted secrets. And during runtime we will decrypt those secrets and use them.
在这里，我们不会在部署过程中解密和发送原始机密。 相反，我们只是传递加密的机密。 在运行时，我们将解密并使用这些机密。
Note: this works best within the Google Cloud Platform. Otherwise you need to generate a service account so you can use this approach with external providers.
注意：这在Google Cloud Platform中最有效。 否则，您需要生成一个服务帐户，以便可以与外部提供商一起使用此方法。
This approach is even more secure since we are not relying on any intermediate user action or a pipeline, but instead only on authorised servers that can decrypt content at runtime.
这种方法更加安全，因为我们不依赖任何中间用户操作或管道，而仅依赖可以在运行时解密内容的授权服务器。
For example, we can allow the staging server (service account) the ability to decrypt staging secrets and not the ability to decrypt production secrets.
例如，我们可以允许登台服务器(服务帐户)解密登台秘密的能力，而不是解密生产秘密的能力。
With this approach, even any developer who doesn’t have access to decrypt production secrets can able to perform production deployment and everything still works fine.
通过这种方法，即使是没有权限解密生产机密的开发人员也可以执行生产部署，并且一切都可以正常进行。
We are going to use the second approach (passing encrypted secrets).
我们将使用第二种方法(传递加密的机密)。
For the demo, assume we are going to deploy to AppEngine since it has a default service account generated already. We will grant it the access to decrypt secrets like below:
对于该演示，假设我们将部署到AppEngine，因为它已经生成了一个默认服务帐户。 我们将授予它如下解密机密的权限：
gcloud kms keys add-iam-policy-binding secrets-enc-key \ --project kms-demo \--location global \--keyring secrets-key-ring \--member serviceAccount:kms-demo@appspot.gserviceaccount.com \--project kms-demo \--role roles/cloudkms.cryptoKeyDecrypter
Thus when the server starts, we could simply load the encrypted file and use the to decrypt its content.
因此，当服务器启动时，我们可以简单地加载加密的文件并使用解密其内容。
Finally, you can see audit logs for operations on each key by enabling KMS audit logging (not enabled by default). Thus we can now keep track of all operations performed for future auditing.
最后，通过启用KMS审核日志记录(默认情况下未启用)，您可以查看每个键上的操作的审核日志。 因此，我们现在可以跟踪执行的所有操作，以备将来审核。
You can enable the audit log using gcloud, but we have seen enough of the command line way. Alternatively, we can enable this configuration using the Cloud Console UI. From the left menu, choose IAM & admin -> Audit Logs.
您可以使用gcloud启用审核日志，但是我们已经了解了足够的命令行方式。 或者，我们可以使用Cloud Console UI启用此配置。 从左侧菜单中，选择IAM＆admin-> Audit Los。
Click Cloud Key Management Service and enable Data Read and Data Write and hit Save.
单击云密钥管理服务，然后启用数据读取和数据写入，然后单击保存。
That's it! Now if any encrypt, decrypt or any other sorts of operations are performed, an audit log is generated and you can check those in the Logging section under Cloud KMS CryptoKey.
而已！ 现在，如果执行了任何加密，解密或任何其他类型的操作，则将生成审核日志，您可以在Cloud KMS CryptoKey下的Logging部分中进行检查。
As you can see, it has audit logs for all sorts of operations including failures like Invalid permissions, or requests etc. It shows which user performed what operation using which key (or if it was done under a service account). That's a pretty neat solution. For more info, read .
如您所见，它具有针对各种操作的审核日志，包括无效权限或请求等失败。它显示了哪个用户使用哪个密钥执行了什么操作(或者是否在服务帐户下完成)。 那是一个非常整洁的解决方案。 有关更多信息，请参阅 。
With this approach, we can store, manage and use application secrets or any sensitive information securely and also track changes using version control. The techniques discussed in this article can be used with any language, and it can use used fully or partially in other platforms as well like iOS, Android, external servers etc.
通过这种方法，我们可以安全地存储，管理和使用应用程序秘密或任何敏感信息，还可以使用版本控制来跟踪更改。 本文讨论的技术可以与任何语言一起使用，并且可以在其他平台(例如iOS，Android，外部服务器等)中完全或部分使用。
For a list of kms commands, refer to . Also, check out the sample application for the complete code:
有关kms命令的列表，请参阅 。 另外，请查看示例应用程序以获取完整的代码：
Here are some reference links:
以下是一些参考链接：
翻译自:
kms服务器管理
转载地址：http://bbewd.baihongyu.com/