<p>Storing sensitive data in attributes is definitely not a good practice. I once used a strategy of a chef-vault per environment (dev,stg,prod), and it worked well. If you use the sensitive data within templates you can set the <code>sensitive</code> property on the template resource to true to keep the password in plain text form from showing up in the run logs and associated template file diffs </p>

<p>We eventually moved to Hashicorp vault, and while it took more time upfront to learn and get up and running, it was definitely a better long term solution for secrets management and automation around managing sensitive data</p>

CC BY-SA 4.0
2018-06-18T15:12:45.657Z
2018-06-18T15:12:45.657Z
TechDawg270
<p>Storing secrets in node attributes is usually not a good practice as all nodes attributes are readable by all nodes in an organization.</p>

<p>There's multiple way to store secrets, Hashicorp's vault, chef-vault (a kind of more secure encrypted databag) or home made system.</p>

<p>You don't say a word about what are those username/passwords for, so it's not really possible to give any advice on a solution for you case.</p>

<p>For general perspective you can check Coderanger's talk about it <a href="https://coderanger.net/talks/secrets/" rel="nofollow noreferrer">here</a></p>

CC BY-SA 4.0
2018-06-18T11:18:57.203Z
2018-06-18T11:18:57.203Z
Tensibai
<p>I've been playing around with Chef to evaluate it as a potential CD tool for the company I work for. </p>

<p>So far I've been using it with Vagrant to provision a VM. In my recipes I've been retrieving the username/password from data bags.</p>

<p>I'm now looking to re-use these recipes across multiple nodes which all have different credentials so pointing to one data bag for credentials is no longer sufficient.</p>

<p>The only way I can see to get around the issue is to store the username and password in the node attributes, however is this best practice/secure?</p>

<p>I've done some googling around this and can't get a clear answer...</p>

<chef>
Chef username/passwords best practice for multiple nodes
Caledonia91
# Chef username/passwords best practice for multiple nodes

(Asked by: username_0 on 2018-06-18)

I've been playing around with Chef to evaluate it as a potential CD tool for the company I work for.

So far I've been using it with Vagrant to provision a VM. In my recipes I've been retrieving the username/password from data bags.

I'm now looking to re-use these recipes across multiple nodes which all have different credentials so pointing to one data bag for credentials is no longer sufficient.

The only way I can see to get around the issue is to store the username and password in the node attributes, however is this best practice/secure?

I've done some googling around this and can't get a clear answer...

**Tags:** chef


---

## 2 answers

### Answer by username_1 on 2018-06-18. Score: 4

Storing sensitive data in attributes is definitely not a good practice. I once used a strategy of a chef-vault per environment (dev,stg,prod), and it worked well. If you use the sensitive data within templates you can set the `sensitive` property on the template resource to true to keep the password in plain text form from showing up in the run logs and associated template file diffs

We eventually moved to Hashicorp vault, and while it took more time upfront to learn and get up and running, it was definitely a better long term solution for secrets management and automation around managing sensitive data


---

### Answer by username_2 on 2018-06-18. Score: 3

Storing secrets in node attributes is usually not a good practice as all nodes attributes are readable by all nodes in an organization.

There's multiple way to store secrets, Hashicorp's vault, chef-vault (a kind of more secure encrypted databag) or home made system.

You don't say a word about what are those username/passwords for, so it's not really possible to give any advice on a solution for you case.

For general perspective you can check Coderanger's talk about it [here](https://coderanger.net/talks/secrets/)


---

