当前位置：文江博客话题详情

在 Chef 中存储密码？

发布于 2024-10-06 23:22:45 字数 110 浏览 0 评论 0原文

使用 Chef 存储密码和 API 密钥的最佳实践是什么？将数据库密码、AWS api 密钥和其他敏感凭证存储为 Chef 服务器属性以在菜谱中使用确实很诱人 - 但安全考虑又如何呢？对此的最佳实践是什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

深府石板幽径 2024-10-13 23:22:45

从 #chef IRC 频道来看，很多人将此类数据存储在 Chef 服务器上的数据包中。

例如，数据包可能是“aws”，其中包含一个“main”项目，指的是主 AWS 账户。项目中的单独键将针对每个特定值。例如：

{
  "id": "main",
  "aws_secret_key": "The secret access key",
  "aws_access_key": "The access key"
}

您可能还对加密数据包感兴趣。我更详细地介绍了它们以管理 postfix SASL 身份验证。

更新：我在 Chef Vault 上撰写了博客文章href="http://jtimberman.housepub.org/blog/2013/09/10/managing-secrets-with-chef-vault/" rel="noreferrer">我的博客和 sysadvent。

From the #chef IRC channel, many people store this kind of data in a data bag on the chef server.

For example, a data bag might be 'aws', with an item 'main', referring to the primary AWS account. Separate keys in the item would be for each particular value. E.g.:

{
  "id": "main",
  "aws_secret_key": "The secret access key",
  "aws_access_key": "The access key"
}

You may also be interested in encrypted data bags. I wrote about them in more detail for managing postfix SASL authentication.

Update: I've written blog posts about Chef Vault on my blog and sysadvent.

回复收藏 0 原文

长不大的小祸害 2024-10-13 23:22:45

这个问题很旧，没有公认的答案，但是，这个问题的正确答案是 Chef 允许使用加密数据包，用于在数据包<中存储敏感数据/a>.

回复收藏 0 原文

自演自醉 2024-10-13 23:22:45

我认为 Hashicorp 的 Vault 作为一种动态检索加密信息的方法确实很有前途，并消除了该领域 Chef 工作流程的一些奇怪之处。

这是一篇有趣的文章，开始触及这个主题。
https://www.hashicorp.com/blog/using-hashicorp -vault-with-chef.html

回复收藏 0 原文

我不是你的备胎 2024-10-13 23:22:45

最佳实践是将密钥和密码保存在 Chef data_bags 中。数据包包含数据包项目。单个 data_bag 项采用 json 格式。

例如：

{
  /* This is a supported comment style */
  // This style is also supported
  "id": "ITEM_NAME",
  "key": "value"
}

加密数据包项目：
数据包项目可以使用共享秘密加密来加密。这允许每个数据包项目存储机密信息（例如数据库密码或 ssh 密钥）或在源代码控制系统中进行管理（修订历史记录中不会出现纯文本数据）。这可以按如下方式完成：

克里特岛密钥：
创建一个名为“encrypted_data_bag_secret”的密钥，例如

$ openssl rand -base64 512 | tr -d '\r\n' > encrypted_data_bag_secret

，其中“encrypted_data_bag_secret”是将包含密钥的文件的名称

加密 data_bag：
数据包项使用刀命令进行加密，类似于：

$ knife data bag create passwords mysql --secret-file /tmp/my_data_bag_key

其中“passwords”是数据包的名称，“mysql”是数据包项的名称，“/tmp/my_data_bag_key”是位置的路径其中包含密钥的文件位于

验证加密：
当数据包项目的内容被加密时，在解密之前它们将无法读取。可以使用类似于以下的刀命令来验证加密：

$ knife data bag show passwords mysql

解密数据包：
加密的数据包项目使用类似于以下的 Knife 命令进行解密：

$ knife data bag show --secret-file /tmp/my_data_bag_key passwords mysql

The best practice is to keep keys and passwords in chef data_bags. A data bag contains databag items. Individual data_bag item are in json format.

For exmaple:

{
  /* This is a supported comment style */
  // This style is also supported
  "id": "ITEM_NAME",
  "key": "value"
}

Encrypt Data Bag Item:
data bag item may be encrypted using shared secret encryption. This allows each data bag item to store confidential information (such as a database password or ssh keys) or to be managed in a source control system (without plain-text data appearing in revision history). This can be done as follow:

Crete Secret Keys:
Create a secret key called encrypted_data_bag_secret for example

$ openssl rand -base64 512 | tr -d '\r\n' > encrypted_data_bag_secret

where encrypted_data_bag_secret is the name of the file which will contain the secret key

Encrypt the data_bag:
A data bag item is encrypted using a knife command similar to:

$ knife data bag create passwords mysql --secret-file /tmp/my_data_bag_key

where “passwords” is the name of the data bag, “mysql” is the name of the data bag item, and “/tmp/my_data_bag_key” is the path to the location in which the file that contains the secret-key is locate

Verify Encryption:
When the contents of a data bag item are encrypted, they will not be readable until they are decrypted. Encryption can be verified with a knife command similar to:

$ knife data bag show passwords mysql

Decrypt data Bag:
An encrypted data bag item is decrypted with a knife command similar to:

$ knife data bag show --secret-file /tmp/my_data_bag_key passwords mysql

回复收藏 0 原文

白龙吟 2024-10-13 23:22:45

Chef Encrypted data_bags 确实是一个合法的解决方案。
除此之外，您还可以使用 ruby Gem，它允许您使用 Chef 节点列表的公钥来加密 Chef 数据包项。这仅允许那些厨师节点解密加密值。
参见https://github.com/Nordstrom/chef-vault

回复收藏 0 原文

深爱不及久伴 2024-10-13 23:22:45

Chef Vault 可能是一个不错的选择。它提供简单的界面，用于在厨师服务器上存储加密数据、访问管理。使用knifeVault...命令上传、编辑、更新数据。

要从配方中获取数据，请使用 ChefVault::Item.load 命令。

chef_gem "chef-vault"
require 'chef-vault'
item = ChefVault::Item.load("passwords", "root")
item["password"]

要设置用户，可以使用 Knife vault_admins 属性来更新数据。

knife[:vault_admins] = [ 'example-alice', 'example-bob', 'example-carol' ]

Chef Vault can be a good choice. It provides simple interface for storing encrypted data on chef-server, access management. Upload, edit, update data with knife vault ... commands.

To get data from recipe use ChefVault::Item.load command

chef_gem "chef-vault"
require 'chef-vault'
item = ChefVault::Item.load("passwords", "root")
item["password"]

To set users, which can update data use knife vault_admins property.

knife[:vault_admins] = [ 'example-alice', 'example-bob', 'example-carol' ]

回复收藏 0 原文

╰◇生如夏花灿烂 2024-10-13 23:22:45

我从未尝试过数据包，但这可能是因为我发现除了厨师独奏之外的一切都有点太复杂了。这就是为什么我将厨师食谱与名为 Scalarium 的服务结合使用的原因。

因此，密码或私钥和各种其他凭证的问题是一个非常棘手的问题。我也有很多需要创建或正确设置密码的食谱。

通常我所做的就是指定 scalarium 人员所称的“自定义 json”。此 json 类似于一些人使用 chef-solo -j node.json 为 Chef-solo 提供的 node.json。

例如，在 Scalarium Web 界面上的自定义 json 中，我有以下内容：

{"super_secure_password":"foobar"}

它的作用是，我的超级安全密码在我的 Chef 在 node 中运行期间可用[:super_secure_password] 我可以在食谱或模板中使用它。

只要我只使用 Scalarium 部署我的服务器，这种方法就可以正常工作，但我们也在本地 vagrant box 中使用我们的配方，以实现开发环境和更轻松的测试。当我使用 vagrant （甚至是 Chef-solo 本身）时，我无法访问 Scalarium 上的自定义 json。

这就是我在 my_recipe/attributes/default 中解决这个问题的方法：

set_unless[:super_secure_password] = "test123"

这意味着当我的配方在 scalarium 之外运行时，密码在 node[:super_secure_password]< 中仍然可用。 /code> 我的食谱有效等等。当配方在 scalarium 上下文中执行时，它不会覆盖它们提供的内容。

I've never tried databags, but that's probably because I find everything apart from chef-solo a little too complicated. Which is why I'm using chef recipies with a service called Scalarium.

So the issue with passwords, or e.g. private keys and all kinds of other credentials is a pretty tough one. I too have a bunch of recipes where passwords need to be created, or set correctly.

Usually what I do is, I specify what the scalarium folks call custom json. This json is similar to the node.json some people give to chef-solo using chef-solo -j node.json.

So e.g. in my custom json on Scalarium web interface, I have the following:

{"super_secure_password":"foobar"}

What this does is, my super secure password is available during my chef run in node[:super_secure_password] and I can use it in recipes or templates.

This works fine as long as I only deploy my server using Scalarium but we also use our recipes in local vagrant boxes for a development environment and easier testing. And when I use vagrant (or even chef-solo by itself), I don't have access to the custom json on Scalarium.

This is what I do to fix that, in my_recipe/attributes/default:

set_unless[:super_secure_password] = "test123"

This means that when my recipe is run outside of scalarium, the password is still available in node[:super_secure_password] and my recipes work and so on. When the recipe is executed in the scalarium context, it will not override what they provide.

回复收藏 0 原文

暖风昔人 2024-10-13 23:22:45

目前最广泛使用且在大多数情况下足够安全的方法是使用 Chef-Vault。

它使用共享密钥来加密您的数据（类似于厨师加密的数据包）。此共享密钥针对将使用它的每个客户端和/或用户进行加密（如果您允许使用它）。

优点：

在测试环境中，您可以使用未加密的数据
不将共享秘密存储为纯文本
可以仅向少数服务器授予访问权限以读取和写入一些数据包

上面的示例

export EDITOR=vi #sets your favourite text editor 

knife vault create secret_data john_doe  --admins "admin" --search "*:*" --mode client

命令在 secret_data 数据包中创建item：john_doe，可以由admin修改并由所有客户端使用。之后，命令 EDITOR 将打开，以便您可以键入 o 粘贴您的秘密数据（以 json 形式）。

搜索查询可以是："role:basic" - 这意味着只有具有 basic 角色的服务器才能读取此数据
knifeVault 需要

在您的 Cookbook

chef_gem 'chef-vault' do
    compile_time true if respond_to?(:compile_time)
end

require 'chef-vault'

item = ChefVault::Item.load("secret_data", "john_doe")
item["password"]

和 metadata.rb 中进行一些额外安装：
取决于 'chef-vault', '1.3.0'

和这里：https:/ /github.com/chef/chef-vault

Currently most widely used approach and for most cases secure enough is to use chef-vault.

It uses shared secret to encrypt your data (similarity to chef-encrypted databag). This shared secret is encrypted for every client and/or user that will use it(if You allow to use it).

Benefits:

on test environment you can use unencrypted data
One doesn't store shared secret as a plain text
One may grant access only few out their servers to read and write some databags

Example

export EDITOR=vi #sets your favourite text editor 

knife vault create secret_data john_doe  --admins "admin" --search "*:*" --mode client

Command above creates in secret_data databag item: john_doe that can modified by admin and used by all clients. After that command EDITOR will open so you can type o paste your secret data(in json ).

Search query can be: "role:basic" - Which means only servers with role basic can read this data
knife vault need some extra installation

In Your Cookbook

chef_gem 'chef-vault' do
    compile_time true if respond_to?(:compile_time)
end

require 'chef-vault'

item = ChefVault::Item.load("secret_data", "john_doe")
item["password"]

and in metadata.rb:
depends 'chef-vault', '1.3.0'

more info here: https://blog.chef.io/2016/01/21/chef-vault-what-is-it-and-what-can-it-do-for-you/

and here: https://github.com/chef/chef-vault

回复收藏 0 原文

只有影子陪我不离不弃 2024-10-13 23:22:45

我建议使用 IAM 角色与厨师配置

require 'chef/provisioning/aws_driver'
iam = AWS::Core::CredentialProviders::EC2Provider.new
puts iam.credentials.inspect
with_driver(
  'aws:IAM:eu-west-1',
  :aws_credentials => { 'IAM' => iam.credentials }
)

I would Suggest use IAM role with chef provisioning

require 'chef/provisioning/aws_driver'
iam = AWS::Core::CredentialProviders::EC2Provider.new
puts iam.credentials.inspect
with_driver(
  'aws:IAM:eu-west-1',
  :aws_credentials => { 'IAM' => iam.credentials }
)

回复收藏 0 原文

~没有更多了~