You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 28, 2020. It is now read-only.
Also, we should be really careful here when considering migration, see this comment by Seth Vargo:
I'd also like to suggest/plea. Please don't force the use of a data bag in a public cookbook. This is a mistake that we've learned from in the past. Instead of forcing people to use a certain schema, I recommend using a hybrid model, like described in the new Jenkins cookbook.
Requiring a certain data bag structure forces people to manage their infrastructure in a certain manner. This is a violation of one of the guiding principles of Chef: you know your infrastructure best. The users cookbook is a big culprit here. It forces users to conform to a certain data structure, which rarely meets the ever-changing and unique demands of an organization.
Alternatively, I recommend using attribute-driven cookbooks and then encourage users to populate those attributes how they see fit. In the case of the users cookbook, users could chose to populate an attribute by specifying it manually, loading it from a data bag, or using a third-party service (like LDAP).
Might be useful for future consideration. TBH, I don't know how to approach this, need to check other public cookbooks/research more how it's usually done and what's preferred, so this Issue is open for discussions.
SSH keys, auth-related
username:password
, DB credentials should be stored in encrypted data bags.Refactor it to use data bags where possible to make the Cookbook more secure and production-ready.
Good request by @shortdudey123 馃憤
The text was updated successfully, but these errors were encountered: