Password is saved as a node attribute!

[bradenwright]

Passwords and sensitive data should not be saved as a node attribute. This is a security issue, I've tried using node.run_state but that won't work. There needs to be an option to use an encrypted data bag (or chef vault), since that is where sensitive data in chef should live.

[majormoses]

agree that there should be better mechanism put in place, what I have been doing to ensure that a password is not in cookbooks I have been setting a random normal attribute doing something like this:

if node['uchiwa']['settings']['pass'] == 'supersecret' || node['uchiwa']['settings']['pass'].empty?
  Chef::Log.info 'uchiwa password was default; setting it to something random'
  Chef::Log.info "view it by querying chef: knife node show #{node.name} -a 'uchiwa.settings.pass'"
  node.normal['uchiwa']['settings']['pass'] = SecureRandom.urlsafe_base64(node.cc.uchiwa.settings.pass.len.to_i)
else
  Chef::Log.info 'uchiwa password was set to something other than the default'
end

[luckymike]

@majormoses that doesn't address @bradenwright's concern here, as that will still save the (random) password to the node, where anyone with a client key can read it.

I agree this cookbook could benefit from an update to remove this behavior, but you can also write your own configuration snippets to /etc/sensu/dashboard.d/ which uchiwa loads by default after the config file.

Something like this would allow you to keep secrets out of the attributes:

user = {
  'uchiwa' => {
    'user' => 'admin',  #or something better ;)
    'password' => 'very_secure_password' #from chef-vault or something else secure
  }
}

file '/etc/sensu/dashboard.d/users.json' do
  content JSON.pretty_generate(user)
end

[luckymike]

NB: the benefit of having this as default behavior is that it allows someone to spin up uchiwa with very little effort to give it a try and provides a sane, functioning default for tests and such.

[majormoses]

@luckymike agree that its not ideal and only partially addresses his concern as still makes them accessible with a chef key but at least it avoids being stored in scm. Unless you use something like hashivault (which I don't think the community cookbook should assume) you will pretty much always be able to read the secret with the appropriate chef permissions and secret keys (in the case of say an encrypted data bag vs attribute) as by nature chef needs to be able to read it it to write it to a file.

[majormoses]

I just merged #51 which allows it to be stored in an encrypted data bag. Would also be nice if someone wanted to add optional chef vault support as well.