Creating a node list

[erutherford]

I'd like to extend the provider on this to support an array of nodes that is evaluated when creating users. This would allow me to limit creation of the user accounts to the nodes that are identified in the data bag entry for that user.

My motivation here is that we have two main groups of nodes, client development and internal development/production. Some users (ops) should have accounts on every single node, while others (dev) should only have user accounts on a specific node or subset of nodes. I'm still extremely new to chef so I could be completely off base here, but this idea seemed logical to me. My proposed change would be to evaluate an array of nodes in the users databag entry to determine whether or not the user account should be created or deleted on a given node.

I understand that I could create recipes following the sysadmin model provided and map specific groups to hosts, but my thought here is that instead of managing a large number of groups, we could treat the groups more like roles and map users with those roles to specific nodes. I believe that this would also make user access more auditable, because you'd be to able easily determine which hosts someone was associated with.

Before I start working on this, is there a reason this shouldn't be done or is there a better way to do this?

[bacrossland]

:+1:

[iennae]

Hi erutherford!

Apologies for the delay in responding to this, but here's my thoughts.

The TL;DR; would be 'Using environments to do this would be great; nodes attribute for the data bag not so much'.

I'm not sure if you have worked on this at all, or what your progress with Chef is at this point so I'm going to write this with the assumption of minimal knowledge for anyone who might read this at some point.

A key abstraction available to Chef users is environments, https://docs.chef.io/environments.html. Every node belongs to exactly 1 environment. If no environment is created, then it's just the _default environment. Now you describe grouping of nodes "Development" and "Production" and that is exactly what environments are for. So what could be done is to have an environment key in the data bag, and then a check whether the user should be added to a node based on the node's environment. This key would be an array, because you might have users that should be added to multiple environments. This I think would be really useful.

Now if we take a look at your original proposal, to add node information to a key in the user data bag. In small environments this would work, but for large environments the node addition would become unwieldy requiring more and more logic around management. We wouldn't add that feature to the community cookbook because it would add complexity and limit usefulness.

Let me know what you think.

Thanks,

Jennifer Community Engineer, Chef

[majormoses]

@iennae what about the lwrp supporting an environment key which can then be evaluated?

an example for someone in ops:

{
  "id": "opsdude",
  "ssh_keys": [
    "valid_ssh_key"
  ],
  "groups": [
    "sysadmin",
  ],
  "environments": [
    "dev",
    "qa",
    "prod"
  ],
  "shell": "\/bin\/bash",
  "comment": "Ops Dude"
}

where an application developer this may be more appropriate:

{
  "id": "appdude",
  "ssh_keys": [
    "valid_ssh_key"
  ],
  "groups": [
    "sysadmin",
  ],
  "environments": [
    "dev",
    "qa"
  ],
  "shell": "\/bin\/bash",
  "comment": "App Dude"
}

Then in the lwrp you could do something like this:

1. do chef search to get a list of users from data bags
2. if the environments key is specified: 2a. check if the currently selected chef environment is in the array if not do nothing with the user resource

[majormoses]

my other thought was to have it support a key which contained a chef search and basically evaluated it and only created the user if it evaluated true

[tas50]

This would need to be achieved via a search that would conditionally include the recipe if the node itself was within the search params (or a list from a data bag). This is really out of the scope of this particular cookbook though since this would be very organization specific. It's totally doable though with a bit of extra work in a wrapper.