谷歌gcp 远程计算机
Earlier this year, Google made Secret Manager generally available (GA), and with this release came a new, native secrets manager solution available for workloads in Google Cloud. In an earlier blog post, we took a first look at Secret Manager.
今年早些时候，Google使Secret Manager普遍可用(GA)，并且在此版本中提供了一种新的本机Secret Manager解决方案，可用于Google Cloud中的工作负载。 在较早的博客文章中，我们首先了解了Secret Manager 。
As more secrets management solutions come to market, the decision of whether or not to use this solution may not be as clear for some organizations as it is for others. This article will examine three of the most popular solutions for Google Cloud Platform (GCP) and compare their features, security concerns, and cost associated with each one.
随着越来越多的机密管理解决方案进入市场，对于某些组织来说，是否使用此解决方案的决定可能不那么清晰。 本文将介绍三种最流行的Google Cloud Platform(GCP)解决方案，并比较它们的功能，安全性以及与之相关的成本。
介绍 (Introduction)
For those new to secrets or secrets managers, check out our previous article on secrets managers here. In short, secrets are values that typically authenticate applications and users to give them access to sensitive systems, services, and information. A secrets manager is used to secure and easily manage these secrets and is essential to creating applications that are suitable for deployment on modern cloud platforms, such as a Twelve-Factor Application.
对于那些不熟悉秘密或秘密管理器的人 ，请在此处查看我们之前关于秘密管理器的文章。 简而言之，秘密是通常对应用程序和用户进行身份验证以使他们能够访问敏感系统，服务和信息的值。 机密管理器用于保护和轻松管理这些机密，对于创建适合在现代云平台上部署的应用程序(例如十二要素应用程序)至关重要。
本地与第三方 (Native vs. Third Party)
Secrets manager solutions come in two different categories: native and third party. Cloud Native solutions are built into the cloud service provider platforms (i.e. Cloud Services) and third party solutions can be deployed onto the cloud native solution. This article will compare one native solution, GCP Secret Manager, and two third party solutions, HashiCorp Vault and Berglas.
秘密管理器解决方案分为两个不同的类别：本机和第三方。 Cloud Native解决方案内置在云服务提供商平台(即Cloud Services)中，并且第三方解决方案可以部署到Cloud Native解决方案上。 本文将比较一个本地解决方案GCP Secret Manager和两个第三方解决方案HashiCorp Vault和Berglas 。
Third party solutions are usually not tied to any specific cloud and can be very useful for those who want a unified secrets solution across on-premise or other clouds such as Amazon Web Services and Microsoft Azure. Public clouds have native solutions to do the undifferentiated heavy lifting — that is, taking care of managing servers and APIs under the hood so that focus can remain on developing applications and services.
第三方解决方案通常不与任何特定的云捆绑在一起，对于希望在本地或其他云(如Amazon Web Services和Microsoft Azure)上寻求统一机密解决方案的人来说，第三方解决方案非常有用。 公有云具有本机解决方案来完成无差别的繁重任务 ，也就是说，要在后台管理服务器和API，以便可以将重点始终放在开发应用程序和服务上。
特征 (Features)
Some secret managers focus on doing one thing (managing key/value storage of secrets), whereas other solutions are feature-rich and can include access brokering and inline encryption. Note that this is not an exhaustive list of features for each secrets manager, but it does provide an outline of the most common features.
一些秘密管理者专注于做一件事(管理秘密的密钥/值存储)，而其他解决方案则功能丰富，可以包括访问代理和内联加密。 请注意，这不是每个机密管理器的功能的详尽列表，但确实提供了最常见功能的概述。
键/值存储 (Key/Value Storage)
Most secrets come in the form of key value pairs, such as username/password or environment variable name/value. Being able to store key-value pairs is a fundamental feature to being a secrets manager and is present in all three solutions.
大多数机密以键值对的形式出现，例如用户名/密码或环境变量名称/值。 能够存储键值对是成为秘密管理员的一项基本功能，并且在所有三个解决方案中都存在。
Secret Manager
秘密经理
Secret Manager does not share any limits on the size of secrets that can be stored within it, however it is safe to say that it should be able to handle any type of typical key/value store secret.
机密管理器对可存储在其中的机密大小没有任何限制，但是可以肯定地说它应该能够处理任何类型的典型密钥/值存储机密。
Berglas
贝格拉斯
Berglas uses a GCM cipher mode to encrypt data, meaning the data must fit in memory and is limited to 64GiB. Seeing that Berglas is targeted at holding typical secrets such as API keys, passwords, and certificates, most users should not run into this limit.
Berglas使用GCM密码模式来加密数据，这意味着数据必须适合内存，并且限制为64GiB 。 看到Berglas的目标是保存诸如API密钥，密码和证书之类的典型机密，因此大多数用户不应遇到此限制。
HashiCorp Vault
HashiCorp保险库
HashiCorp Vault does not enforce a size limit for key-value pairs, but it can vary depending on the storage backend. It should be noted that Vault’s HTTP API has a default limit of 32MB to help mitigate denial of service (DoS) attacks due to arbitrarily large requests, but this can be adjusted by changing the configuration file.
HashiCorp Vault并未对键值对强制执行大小限制，但是它会根据存储后端而有所不同。 应当注意，Vault的HTTP API 的默认限制为32MB，以帮助缓解由于任意大的请求而导致的拒绝服务(DoS)攻击，但是可以通过更改配置文件来进行调整。
秘密轮换 (Secrets Rotation)
Being able to rotate secrets is essential in maintaining proper security hygiene for applications and services. Rotating secrets ensures that any secrets that exist in code or infrastructure will not be valid if compromised, and in addition ensures that the application is doing proper fetching from the secrets manager, thus encouraging a tight integration with the secrets manager and those applications that adopt it. In other words, regularly rotating secrets not only keeps applications secure, but encourages the adoption of a secrets manager throughout the project and/or company. For those who are compliance conscious, NIST 800–57 prescribes the rotation of secrets and having a proper rotation mechanism can help significantly with achieving that or similar types of goals.
能够旋转秘密对于维护应用程序和服务的适当安全卫生至关重要。 轮换机密可以确保代码或基础结构中存在的任何机密信息一旦遭到泄露，都将无效，此外，还可以确保应用程序正在从机密管理器中进行正确的提取，从而鼓励与机密管理器以及采用该机密的应用程序紧密集成。 换句话说，定期轮换机密不仅可以确保应用程序的安全，还可以鼓励整个项目和/或公司采用机密管理器。 对于那些遵守法规的人， NIST 800-57规定了秘密的轮换，拥有适当的轮换机制可以极大地帮助实现该目标或类似类型的目标。
Secret Manager
秘密经理
At the time of writing, GCP Secret Manager does not have a single API call to rotate secrets. Luckily, creating a new version of a secret managed by Secret Manager is a single API call and can easily be scripted into applications, cloud functions, or cron jobs.
在撰写本文时，GCP Secret Manager没有单个API调用来旋转机密。 幸运的是，创建由Secret Manager管理的机密的新版本只是一个API调用，并且可以轻松地编写脚本到应用程序，云功能或cron作业中。
Berglas
贝格拉斯
Like Secret Manager, Berglas does not have a mechanism in place to simply rotate secrets, instead the secret value would have to be updated using either the Berglas CLI or library.
像Secret Manager一样，Berglas没有适当的机制来简单地旋转机密，而是必须使用Berglas CLI或库来更新机密值。
HashiCorp Vault
HashiCorp保险库
Vault has a feature called dynamic secrets, which allows for Just-in-time (JIT) provisioning of secrets . Basically this means that dynamic secrets are generated when they are accessed and don’t exist until they are read, lowering the risk of someone stealing them or another client using the same secrets. As of the time of this writing, Vault supports dynamic secrets with a variety of backends including databases, messaging queues, cloud providers, Secure Shell (SSH), and Public Key Infrastructure (PKI). Other types of secrets can be enabled with plugins.
保管箱具有称为动态机密的功能，该功能允许即时(JIT)设置机密。 基本上，这意味着动态机密在访问时会生成，并且在被读取之前不存在，从而降低了有人窃取动态机密或另一个使用相同机密的客户端的风险。 在撰写本文时，Vault支持具有各种后端的动态机密 ，包括数据库，消息队列，云提供商，安全Shell(SSH)和公钥基础结构(PKI)。 可以使用插件启用其他类型的秘密。
密码产生 (Password Generation)
Password Generation is not an essential feature of a secrets manager, but can be useful for automation purposes and serves to be a useful tool to have in the cloud security toolbox.
密码生成不是机密管理器的基本功能，但对于自动化目的很有用，并且可以用作云安全工具箱中的有用工具。
Both Berglas and GCP Secret Manager do not have this feature since their focus is on being a simple key/value storage for generally used, basic secrets.
Berglas和GCP Secret Manager都没有此功能，因为它们的重点是为通常使用的基本机密提供简单的键/值存储。
HashiCorp Vault has the vault-secrets-gen plugin to generate high entropy passwords and passphrases with a variety of options to control the secret’s length and complexity.
HashiCorp Vault具有vault-secrets-gen插件，可生成高熵密码和密码短语，并提供多种选项来控制秘密的长度和复杂性。
基础架构即代码集成 (Infrastructure as Code Integration)
Infrastructure as Code (IaC) is important for cloud environments, and we at ScaleSec are indeed fans of it. The two most prominent declarative IaC solutions for GCP are HashiCorp Terraform and Google Cloud Deployment Manager. Using a secrets manager in IaC ensures that secrets are not hardcoded into source code and the most recent version of a particular secret can be fetched on demand when code is run.
基础架构即代码(IaC)对云环境很重要，而ScaleSec的我们确实是其拥护者 。 用于GCP的两个最杰出的声明式IaC解决方案是HashiCorp Terraform和Google Cloud Deployment Manager 。 在IaC中使用机密管理器可确保不会将机密硬编码为源代码，并且可以在运行代码时按需获取特定机密的最新版本。
Deployment Manager
部署经理
Deployment Manager has support for all three solutions and is able to both read and manage secrets through the use of adding an API as a Type Provider. By adding the Type Providers for your secret manager of choice, all resources of that secret manager are exposed to Deployment Manager as base types that can be used in configurations. Deployment manager does this by leveraging the RESTful API that supports Create, Read, Update, and Delete (CRUD) operations — a feature that each of these secret managers have.
Deployment Manager支持所有这三种解决方案，并且能够通过将API添加为类型提供程序来读取和管理机密。 通过为您选择的机密管理器添加类型提供程序，该机密管理器的所有资源将作为可在配置中使用的基本类型公开给Deployment Manager。 Deployment Manager通过利用支持创建，读取，更新和删除(CRUD)操作的RESTful API来实现此目的-这些秘密管理器均具有此功能。
HashiCorp Terraform
HashiCorp地形
Terraform also supports all three solutions and is able to both create and read secrets. HashiCorp Vault has first class support as a Terraform provider. The terraform-provider-google-beta provider has support for performing CRUD operations on secrets stored within Secret Manager. There’s also a Berglas Terraform provider available that also allows for the creation and management of secrets using Berglas.
Terraform还支持所有三种解决方案，并且能够创建和读取机密。 HashiCorp Vault作为Terraform提供程序具有一流的支持。 terraform-provider-google-beta provider支持对存储在Secret Manager中的机密执行CRUD操作。 还有一个Berglas Terraform提供程序，该提供程序还允许使用Berglas创建和管理机密。
安全 (Security)
It is extremely important for any secrets manager to effectively keep secrets safe. Security for secrets managers must be examined in terms of confidentiality, integrity, and availability of the secrets that they are managing. The following topics will be examined: what access control mechanisms are in place to manage both the modification and the retrieval of secrets, how secrets are protected at rest, and how secrets are protected in transit. This is by no means an exhaustive list of security concerns that should be considered when selecting a secrets manager for use in the cloud, but highlights the most important points that should be taken into account before selecting a secrets manager.
对于任何秘密管理员来说，有效地保护秘密都是极其重要的。 必须从机密性，完整性和所管理机密的可用性方面检查机密管理者的安全性。 将研究以下主题：设置了哪些访问控制机制来管理秘密的修改和检索，如何在静止时保护秘密，以及如何在传输中保护秘密。 这绝不是选择在云中使用的秘密管理器时应考虑的安全性问题的详尽列表，而是突出了选择秘密管理器之前应考虑的最重要的要点。
访问控制 (Access Control)
Secret Manager
秘密经理
The Secret Manager API is governed by Google Cloud IAM. Cloud IAM governs the access of payload of secrets, administration, and viewing of metadata of secret manager resources individually through the use of Cloud IAM roles. A list of these roles can be found in the table below:
Secret Manager API受Google Cloud IAM管辖。 Cloud IAM通过使用Cloud IAM角色来分别控制秘密有效负载的访问，管理和秘密管理器资源的元数据的查看。 下表中列出了这些角色：
Note that, as with other Google resources, the effects of the hierarchy created by Cloud IAM exist for resources, including secrets (which is the lowest level resource in this case) managed by Secret Manager. To help facilitate the principle of least privilege and granting the minimum level of access to an identity, it is recommended that if an identity only needs access to a single secret’s value — only grant that identity the ability to access the single secret.
请注意，与其他Google资源一样，由Cloud IAM创建的层次结构对于资源(包括由Secret Manager管理的机密(在这种情况下，这是最低级别的资源))存在。 为了帮助促进最小特权原则并授予对身份的最低访问权限，建议如果身份仅需要访问单个秘密的值，则仅授予该身份访问单个秘密的能力。
Berglas
贝格拉斯
Berglas also leverages Cloud IAM, but in a different way due to the fact that it uses Cloud Storage buckets to store secrets. Authorizations to secrets (e.g. specifying who/what has access to a secret) is governed by using the berglas grant and berglas revoke commands or associated API methods. These API methods use Cloud IAM internally by adding the
Berglas还利用Cloud IAM，但由于它使用Cloud Storage存储桶来存储机密，因此采用了不同的方式。 秘密授权(例如，指定谁/什么人可以访问秘密)是通过使用berglas grant和berglas revoke命令或相关的API方法来控制的。 这些API方法在内部使用Cloud IAM，方法是添加
roles/storage.objectCreator (to create a secret),
roles/storage.objectCreator (创建秘密)，
roles/storage.objectViewer (to view a secret), and
roles/storage.objectViewer (查看机密)，以及
roles/storage.objectAdmin (to delete a secret).
roles/storage.objectAdmin (删除机密)。
Cloud KMS permissions are also necessary for encrypting/decrypting data as necessary for access.
Cloud KMS权限对于访问所需的加密/解密数据也是必需的。
HashiCorp Vault
HashiCorp保险库
HashiCorp Vault manages access control through path-based policies. Through the use of policies, Role-Based Access Control can be achieved by specifying access privileges via path-based matching. Vault policies can be written in JSON or HashiCorp Configuration Language (HCL) for easier human readability. Like IAM policies, Vault policies have an implicit deny as well, and paths in Vault must be explicitly allowed along with the corresponding capabilities.
HashiCorp Vault通过基于路径的策略管理访问控制。 通过使用策略，可以通过基于路径的匹配指定访问权限来实现基于角色的访问控制。 保险柜策略可以用JSON或HashiCorp配置语言(HCL)编写，以便于人类阅读。 与IAM策略一样，保管库策略也具有隐式拒绝，并且必须明确允许保管库中的路径以及相应的功能。
An example of a Vault policy written in HCL is given below. Note the glob (*) syntax for allowing access to all paths under the specified prefix (in this case secret/), a path for specific access (such as secret/super-secret), and conditional access based on allowed parameters (shown in the secret/restricted block):
下面给出了用HCL编写的保管库策略的示例。 请注意glob( * )语法，该语法允许访问指定前缀下的所有路径(在本例中为secret/ )，特定访问的路径(例如secret/super-secret )以及基于允许的参数的条件访问(如secret/restricted block )：
静止保护 (Protection at Rest)
Secret Manager
秘密经理
Secret Manager, like other Google Cloud services, always encrypts data before it is persisted to disk. This is known as default encryption in which Google both creates and manages the cryptographic material used to protect data at rest. In other words, data is already encrypted transparently using AES-256. Through the use of Cloud KMS, Secret Manager also supports Customer-managed encryption keys (CMEKs). The use of CMEKs with Secret Manager is not yet generally available, but interest can be expressed via a form to the Google Cloud team. As of writing, Customer-supplied encryption keys (CSEKs) are not available as an option.
与其他Google Cloud服务一样，Secret Manager 总是在将数据持久保存到磁盘之前先对其进行加密 。 这就是所谓的默认加密，其中Google会创建和管理用于保护静态数据的加密材料。 换句话说，数据已经使用AES-256进行了透明加密。 通过使用Cloud KMS，Secret Manager还支持客户管理的加密密钥(CMEK)。 尚不普遍将CMEK与Secret Manager结合使用，但可以通过向Google Cloud团队提交表格来表达兴趣 。 在撰写本文时，不能提供客户提供的加密密钥(CSEK)。
Berglas
贝格拉斯
When encrypting a secret, Berglas generates a data encryption key (DEK) using 256-bit Advanced Encryption Standard (AES) cipher in the Galois Counter Mode (GCM) via Go’s crypto package for each secret. This means that each secret has its own DEK. Berglas then encrypts the plaintext data using the locally-generated DEK, producing encrypted ciphertext, prepended with the unique nonce created from AES-GCM. Berglas then uses a process called envelope encryption to then encrypt the DEK using a specified Cloud KMS key, known as a key encryption key (KEK). Finally, Berglas stores the Cloud KMS key name, encrypted DEK, and encrypted ciphertext as a single blob in Cloud Storage.
加密机密时，Berglas通过Go's加密程序包为每个机密使用Galois计数器模式(GCM)中的256位高级加密标准(AES)密码生成数据加密密钥(DEK)。 这意味着每个机密都有自己的DEK。 然后，Berglas使用本地生成的DEK对明文数据进行加密，从而生成加密的密文，并以从AES-GCM创建的唯一随机数开头。 然后，Berglas使用称为信封加密的过程使用指定的Cloud KMS密钥(称为密钥加密密钥(KEK))对DEK进行加密。 最后，Berglas将Cloud KMS密钥名称，加密的DEK和加密的密文作为一个Blob存储在Cloud Storage中。
When decrypting a secret, Berglas downloads the blob from Cloud Storage and separates the Cloud KMS key name, encrypted DEK, and ciphertext from the blob. Then using Cloud KMS, the DEK is decrypted, and then the ciphertext data is locally decrypted using the decrypted DEK.
解密机密时，Berglas从Cloud Storage下载Blob，并从Blob中分离Cloud KMS密钥名称，加密的DEK和密文。 然后使用Cloud KMS对DEK进行解密，然后使用解密的DEK对密文数据进行本地解密。
HashiCorp Vault
HashiCorp保险库
The storage backends used by HashiCorp Vault are designed with a zero trust mindset. Vault uses a security barrier for all requests made to the backend. The security barrier automatically encrypts all data leaving Vault using a 256-bit AES-GCM with a 96-bit nonce. The nonce is randomly generated for every encrypted object. When data is read from the security barrier the GCM authentication tag is verified during the decryption process to detect integrity breaches.
HashiCorp Vault使用的存储后端设计为零信任心态。 保险柜对向后端发出的所有请求使用安全屏障。 安全屏障使用具有96位随机数的256位AES-GCM自动加密离开保管库的所有数据。 随机数是为每个加密对象随机生成的。 当从安全屏障读取数据时，将在解密过程中验证GCM身份验证标签，以检测完整性漏洞。
By design, Vault needs an encryption key in order to decrypt data. This encryption key is stored with the data, but is encrypted with another encryption key known as the master key. The master key is actually not stored anywhere. Instead of distributing this single master key to an operator, Vault uses an algorithm known as Shamir’s Secret Sharing to split the key into shards. A certain threshold of shards is required to reconstruct the master key. This protects against insider threat because in the case of a detected intrusion, the Vault data can be sealed in order to quickly minimize damages. The master key must then be reconstructed using the distributed shards to reach a quorum and unseal the vault so that applications and services can access secrets again. Google Cloud KMS keys, including the use of CMEKs and CSEKs, can also be used to auto-unseal the Vault.
根据设计，保险柜需要加密密钥才能解密数据。 该加密密钥与数据一起存储，但是使用另一个称为主密钥的加密密钥进行加密。 主密钥实际上不存储在任何地方。 Vault不会将单个主密钥分配给操作员，而是使用称为Shamir的秘密共享的算法将密钥拆分为分片 。 需要一定的分片阈值来重建主密钥。 这样可以防止内部威胁，因为在检测到入侵的情况下，可以将保管库数据密封起来 ，以快速将损失降到最低。 然后必须使用分布式分片重建主密钥，以达到法定人数并解封保管库，以便应用程序和服务可以再次访问机密。 Google Cloud KMS密钥(包括CMEK和CSEK的使用)也可以用于自动打开保险柜。
运输途中的保护 (Protection in Transit)
Secret Manager
秘密经理
By default, Google encrypts and authenticates data in transit when it moves to and from Google Cloud. However, inside a Google-managed physical boundary data in transit is always authenticated, but not necessarily encrypted. Since API interactions with Secret Manager are always communicated over a secure HTTPS connection, this will suffice as data protected in transit for almost every use case.
默认情况下，当Google向Google Cloud迁移数据时，Google会对传输中的数据进行加密和身份验证。 但是，在Google管理的物理边界内部，传输过程中的数据始终经过身份验证，但不一定经过加密。 由于与Secret Manager的API交互总是通过安全的HTTPS连接进行通信，因此对于几乎每个用例而言，在传输过程中受保护的数据就足够了。
Berglas
贝格拉斯
Since Berglas uses Google services like Cloud Storage and Cloud KMS under the hood, API interactions are also communicated over a secure HTTPS connection, and thus data is protected in transit for most use cases.
由于Berglas在后台使用Google服务(例如Cloud Storage和Cloud KMS)，因此API交互也通过安全的HTTPS连接进行通信，因此在大多数使用情况下，数据在传输过程中受到保护。
HashiCorp Vault
HashiCorp保险库
Since HashiCorp Vault is run on hardware provisioned by the consumer of it, the networking situation can differ between installations. Transport Layer Security (TLS) can be configured on Vault via a listener to enable encryption in transit, and thus protects data as it travels over a network. Vault can be configured to be highly available and have end-to-end TLS over a network with relative ease.
由于HashiCorp Vault在其使用者提供的硬件上运行，因此安装之间的网络情况可能会有所不同。 可以通过侦听器在Vault 上配置传输层安全性(TLS)，以启用传输中的加密，从而在数据通过网络传输时对其进行保护。 可以将保管库配置为高可用性，并且相对容易地通过网络使用端到端TLS 。
成本 (Cost)
Cost must also be considered since the pricing models differ between native and third party offerings. The native option, Secret Manager has a per active secret monthly charge and access operations for those secrets, however has no operational cost. Both third party secret managers (HashiCorp Vault and Berglas) have operational cost due to the infrastructure necessary to support these solutions, however have no cost for per active secret monthly charge or access operations. Also note that HashiCorp Vault has a licensing cost for Enterprise features.
由于本地产品和第三方产品之间的定价模型不同，因此还必须考虑成本。 本机选项Secret Manager按活动的机密按月收费，并对这些机密进行访问操作，但是没有任何操作成本。 由于支持这些解决方案所必需的基础结构，第三方秘密管理者(HashiCorp Vault和Berglas)都有运营成本，但是对于每个活动的秘密月度收费或访问操作都没有成本。 另请注意，HashiCorp Vault拥有企业功能的许可费用。
秘密经理 (Secret Manager)
Secret Manager has a cost associated with both API operations and active secret versions (active meaning secrets that are either in the ENABLED or DISABLED state). Also note that this is not only a per secret charge, but is also _a per location _charge. This means that for each secret stored in Secret Manager, multiply by the number of locations that secrets are stored in.
密钥管理器具有与API操作和活动密钥版本(处于启用或禁用状态的活动含义密钥)相关的成本。 另请注意，这不仅是按秘密收费，而且是每个位置_a收费。 这意味着对于存储在Secret Manager中的每个机密，乘以存储机密的位置数。
贝格拉斯 (Berglas)
Berglas is simply a command line tool and library for storing and retrieving secrets stored in Cloud Storage with encryption fulfilled by Cloud KMS. When you bootstrap Berglas, you specify a BUCKET_LOCATION (default US multi-regional location) where the bucket will be located, and Berglas will provision one for you; optionally you can have full control over the Cloud Storage bucket and Cloud KMS key via custom setup.
Berglas只是一个命令行工具和库，用于存储和检索通过Cloud KMS实现的加密而存储在Cloud Storage中的机密。 引导Berglas时，您指定存储桶将位于的BUCKET_LOCATION (默认的US多区域位置)，Berglas将为您提供一个。 (可选)您可以通过自定义设置完全控制Cloud Storage存储桶和Cloud KMS密钥。
In addition to the Cloud Storage setup, Berglas can integrate with App Engine (Standard and Flex), Cloud Run, Cloud Functions, Cloud Build, Kubernetes, and berglas exec (anywhere). Depending on the deployment of Berglas, the cost of using one of these integrations also need to be kept in mind.
除云存储设置外，Berglas还可以与App Engine(标准和Flex)，Cloud Run，Cloud Functions，Cloud Build，Kubernetes和berglas exec (任何地方) berglas exec 。 根据Berglas的部署，还需要牢记使用这些集成之一的成本。
HashiCorp保险库 (HashiCorp Vault)
HashiCorp Vault comes in both open-source and two enterprise versions: Enterprise Platform and Enterprise Modules. Both enterprise solutions come at an additional cost, which can be given by contacting HashiCorp. Vault is also a self-hosted solution for both open source and enterprise, therefore both provisioned infrastructure and operational upkeep must be considered when calculating cost. There is no additional cost for the number of stored secrets or secrets retrieval.
HashiCorp Vault具有开源版本和两个企业版本：Enterprise Platform和Enterprise Modules。 两种企业解决方案都需要额外付费，可以通过与HashiCorp联系来支付。 Vault还是开放源代码和企业版的自托管解决方案，因此在计算成本时必须同时考虑预配置的基础架构和运营维护。 存储的机密或机密检索的数量没有额外的费用。
For most typical setups, the cost of HashiCorp Vault to store secrets in GCP is comparable to that of Berglas due to the fact that HashiCorp Vault runs on VM instances or containers on other GCP services in addition to the storage backend.
对于大多数典型设置，HashiCorp Vault在GCP中存储机密的成本与Berglas相当，这是因为HashiCorp Vault除了存储后端以外，还运行在VM实例或其他GCP服务上的容器上。
结论 (Conclusion)
For new and/or lightweight projects, GCP Secret Manager should definitely be investigated. Secret Manger should be favored over Berglas in most situations directly, since it has less operational overhead and complexity, however the per active secret and access costs associated with Secret Manager should be kept in mind.
对于新的和/或轻量级的项目，绝对应该对GCP Secret Manager进行调查。 在大多数情况下，Secret Manger应该比Berglas直接受青睐，因为它具有较少的运营开销和复杂性 ，但是应牢记与Secret Manager相关的每个活动机密和访问成本。
If a native secret manager is desired, Secret Manger is the way to go. Leveraging features like Cloud IAM for secret-level access granularity is a good, cloud native way to provision access to secrets. In addition, you will not have to manage resources which can save a lot of operational costs.
如果需要本地机密管理器，则可以使用Secret Manger。 利用Cloud IAM之类的功能实现秘密级别的访问粒度是一种很好的云原生方法，用于提供对秘密的访问。 此外，您将不必管理可节省大量运营成本的资源。
The most feature rich and the solution of choice is HashiCorp Vault. It excels in most categories and has great community support. Arguably, it is much more than a secrets manager. It has been described as the “Swiss Army Knife” of cloud security because of its additional features such as brokering SSH access, being a Certificate Authority to generate X.509 certificates on demand, and performing encryption as a service. This is also the best option if you are considering a multi-cloud strategy in the future and would like to keep secrets in a centralized location.
HashiCorp Vault是功能最丰富且选择的解决方案。 它在大多数类别中都很出色，并得到了社区的大力支持 。 可以说，这不仅仅是秘密经理。 它被称为云安全性的“ 瑞士军刀 ”，因为它具有其他功能，例如代理SSH访问， 作为按需生成X.509证书的证书颁发机构以及执行加密即服务的功能 。 如果您将来考虑采用多云策略，并且希望将机密信息保存在集中位置，那么这也是最佳选择。
关于我们 (About Us)
Eric Evans is a Senior Cloud Security Consultant at ScaleSec, where he enjoys innovating and making the cloud a safer place. Originally a software developer, for the past half decade his passion has been focused on DevOps & Information Security. When he’s not working, he’s hacking away at electronics projects using technologies like the Raspberry Pi, Arduino, and OpenBCI. Connect with Eric on LinkedIn here.
埃里克·埃文斯 ( Eric Evans)是ScaleSec的高级云安全顾问，他在创新和使云成为更安全的地方感到满意。 最初是软件开发人员，在过去的五年中，他的热情一直集中在DevOps和信息安全上。 当他不工作时，他正在使用Raspberry Pi，Arduino和OpenBCI等技术从事电子项目。 在此处与LinkedIn上的Eric联系。
ScaleSec is a service-disabled, veteran-owned small business (SDVOSB) for cloud security and compliance that helps innovators meet the requirements of their most scrutinizing customers. We specialize in cloud security engineering and cloud compliance. Our team of experts guides customers through complex cloud security challenges, from foundations to implementation, audit preparation and beyond. Learn more at https://scalesec.com.
ScaleSec是一家禁用服务的老牌小型企业(SDVOSB)，可提供云安全性和合规性，可帮助创新者满足其最严格的客户要求。 我们专注于云安全工程和云合规性。 我们的专家团队将指导客户应对复杂的云安全挑战，从基础到实施，审计准备等等。 在https://scalesec.com上了解更多信息。
We are hiring!
我们正在招聘 ！
翻译自: https://blog.scalesec.com/a-comparison-of-secrets-managers-for-google-cloud-platform-gcp-573d28caf419
谷歌gcp 远程计算机