Unused environment attributes/tighter chef-vault integration opportunity?


#1

I have a coworker who has shown me an interesting pattern.

With our current pattern, we have our environment JSON files and the vault item JSON files that accompany that environment sorted by subdirectory. That way the vault items for a specific env (or node) can be easily located and just loaded in when a node is bootstrapped.

My colleague, ever the efficient worker, has decided to merge the two:

{
  "name":        "env_name",
  "description": "Sample Environment",
  "json_class":  "Chef::Environment",
  "chef_type":   "environment",
  "vault_items": {
    ...
  },
  ...
}

I like this idea - for reasons I will mention in later paragraphs - but I want to make sure it’s safe.

From what it seems like, looks like the valut_items key is is ignored by the Chef server, so currently loading this in is safe in the way that it does not cause errors or load bad environment data in. Of course, who knows if this could change, which is the con for me.

The pros, of course, are a simpler code structure - environment data, including all vault items, are now managed in a single file (with the downside of it might not be obvious if only a single node in an environment needs a vault item, as we don’t have node granularity in source control right now).

And then I got this neat idea. What if this was actually supported?

Right now, knife bootstrap supports supplying vault item data via key/value paris on the command line, thru a JSON on the command line, or thru a JSON passed in as a file. It doesn’t seem too far of a stretch to have this fully supported by the Chef server and the bootstrap process, where this data could sit in a role or environment which could be read by knife when needed during the pre-create process. That way, data would not need to be supplied “manually” every time.

So I guess my two questions are:

  1. (The more important one) Is having custom environment data in an environment JSON that is not supported by Chef potentially damaging?
  2. Is there feasibility to having this kind of aforementioned support for chef-vault in the future? I really do think it’s a great product, offers better secret granularity over regular encrypted data bags and would love to see it be more mainline.

#2

We can’t really make statements about future support for things that don’t currently exist. I would recommend putting that values in node attributes even if you don’t use them from Chef. I’ll avoid commenting on #2 because I’ll just start ranting, but there is a really low chance that this is a good idea right now.