Storing passwords in the chef?

Question

What is the best practice for storing passwords and API keys with a chef? It's really tempting to store database passwords, AWS api keys, and other sensitive credentials as chef server attributes for use in recipes - but what about security concerns? What is the best practice for this?

Answer 1

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

For example, a data bag might be "aws" with an element of "main", referring to the main AWS account. Separate keys in the element will be for each specific value. For example:.

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

You may also be interested in encrypted data packets . I wrote about them in more detail to control the postfixation of SASL authentication .

Update: I wrote a blog post about Chef on my blog and sysadvent .

Answer 2

This question is old and does not have an accepted answer, but the correct answer to this question is that the Chef allows you to use Encrypted Data Bags to store sensitive data in Data Bags .

Answer 3

I think that Hashicorp Vault is really promising as a way to dynamically obtain encrypted information and leave behind some of the oddities of Chef's workflow in this area.

This is an interesting post that begins to relate to the subject. https://www.hashicorp.com/blog/using-hashicorp-vault-with-chef.html

Answer 4

Chef Encrypted data_bags are indeed a legitimate solution. Adding to this, you can also use a ruby ​​gem, which allows you to encrypt an element of the total summary item using the public keys of the chef's node list. This allows only those chefs to decrypt the encrypted values. Wed https://github.com/Nordstrom/chef-vault

Answer 5

I have never tried databags, but this is probably because I find everything but the chef too complicated. That's why I use chef recipes with the Scalarium service.

So, the problem with passwords or, for example, private keys and all sorts of other credentials are quite complex. I also have a bunch of recipes where passwords need to be created or set correctly.

Usually what I do, I indicate that people in scalar mode call user json. This json is similar to node.json , which some people give to the chef using chef-solo -j node.json .

So, for example, in my Scalarium web user json, I have the following:

 {"super_secure_password":"foobar"} 

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

This works fine while I only use the Scalarium server, but we also use our recipes in local firewalls for a development environment and easier testing. And when I use a stroller (or even a chef on my own), I don't have access to custom json on Scalarium.

This is what I am doing to fix this in my_recipe/attributes/default :

 set_unless[:super_secure_password] = "test123" 

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

Answer 6

A chef might be a good choice. It provides a simple interface for storing encrypted data on the chef-server, access control. Download, edit, update data using knife vault ... commands.

To retrieve data from a recipe, use the command ChefVault::Item.load

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

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

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

Answer 7

I would suggest using the IAM role with chef training

 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 } ) 

Answer 8

Currently, the most widely used approach and in most cases is safe enough to use chef-vault.

It uses a shared secret to encrypt your data (similar to an encrypted encrypted file). This shared secret is encrypted for each client and / or user who will use it (if you allow it to be used).

Benefits:

• in a test environment you can use unencrypted data
• One does not keep a shared secret as plain text
• Only a few servers can be granted access to read and write certain databases.

Example

 export EDITOR=vi #sets your favourite text editor knife vault create secret_data john_doe --admins "admin" --search "*:*" --mode client 

The command above creates in the secret_data databag: john_doe , which can be changed by admin and used by all clients. After that, the EDITOR command will open so that you can enter o insert secret data (in json).

The search query can be: "role:basic" - this means that only these servers with the basic role can read this data knife vault needs additional 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 details 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

Answer 9

Best practice is storing keys and passwords in chef data_bags. The data bag contains database items. A single data_bag element is in json format.

For exmaple:

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

Encrypt data item: The data item can be encrypted using shared secret encryption. This allows each element of the data packet to store confidential information (for example, the database password or ssh keys) or manage it in the original control system (without the text data displayed in the change history). This can be done as follows:

Cretan 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 that will contain the private key

Encrypt data_bag: The data packet element 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 packet, "mysql" is the name of the data packet element, and "/ tmp / my_data_bag_key" is the path to the location where the file containing the private key is located

Check encryption: When the contents of a data packet element are encrypted, they will not be readable until they are decrypted. Encryption can be verified using the knife command, similar to:

 $ knife data bag show passwords mysql 

Decrypt data Bag: The encrypted element of the data bag is decrypted using a knife command similar to:

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