Different data_bags in production and test-kitchen


#1

Hi, I’m using test-kitchen with vagrant, and having trouble with the users
cookbook from opscode.

Suppose we have a bunch of ‘users’ data bag items and some of them have 'sudo’
in the array of groups. If we have a recipe that has users_manage “sudo”,
kitchen converge removes the vagrant user from sudo group because we don’t have
the vagrant user in our data_bags.

I could come up with a few work arounds:

A. Add vagrant user in our data_bags
B. Modify our cookbook so that users_manage “sudo” runs if it’s not in Vagrant

Neigher of them is great because:

  • We definitely wouldn’t like to create vagrant user in production.
  • Conditional runs make cookbooks complicated/error-prone.

I thought if .kitchen.yml supported an array of paths in data_bags_path, we
could have mycookbook/data_bags and mycookbook/data_bags_for_vagrant which has
vagrant user with sudo included in the groups. But it doesn’t seem to support
arrays at this moment.

Does anyone have the same issue? Any suggestions?

Thanks,

Mitsutoshi Aoe
maoe@foldr.in


#2

Possibly unhelpful suggestion: stop using data bags. See https://github.com/balanced-cookbooks/balanced-user for an example of a better way :slight_smile:

–Noah

maoe@foldr.in wrote:

Hi, I’m using test-kitchen with vagrant, and having trouble with the
users
cookbook from opscode.

Suppose we have a bunch of ‘users’ data bag items and some of them have
’sudo’
in the array of groups. If we have a recipe that has users_manage
"sudo",
kitchen converge removes the vagrant user from sudo group because we
don’t have
the vagrant user in our data_bags.

I could come up with a few work arounds:

A. Add vagrant user in our data_bags
B. Modify our cookbook so that users_manage “sudo” runs if it’s not in
Vagrant

Neigher of them is great because:

  • We definitely wouldn’t like to create vagrant user in production.
  • Conditional runs make cookbooks complicated/error-prone.

I thought if .kitchen.yml supported an array of paths in
data_bags_path, we
could have mycookbook/data_bags and mycookbook/data_bags_for_vagrant
which has
vagrant user with sudo included in the groups. But it doesn’t seem to
support
arrays at this moment.

Does anyone have the same issue? Any suggestions?

Thanks,

Mitsutoshi Aoe
maoe@foldr.in


#3

Hi Noah,

Fair enough. I’m actually not a big fan of data bags. It’d be nice if
there is a general purpose LWRP cookbook that could manage users and
also groups.

Thanks,

Mitsutoshi Aoe
maoe@foldr.in

2014-02-20 14:52 GMT+09:00 Noah Kantrowitz noah@coderanger.net:

Possibly unhelpful suggestion: stop using data bags. See
https://github.com/balanced-cookbooks/balanced-user for an example of a
better way :slight_smile:

–Noah

maoe@foldr.in wrote:

Hi, I’m using test-kitchen with vagrant, and having trouble with the users
cookbook from opscode.

Suppose we have a bunch of ‘users’ data bag items and some of them have
’sudo’
in the array of groups. If we have a recipe that has users_manage “sudo”,
kitchen converge removes the vagrant user from sudo group because we don’t
have
the vagrant user in our data_bags.

I could come up with a few work arounds:

A. Add vagrant user in our data_bags
B. Modify our cookbook so that users_manage “sudo” runs if it’s not in
Vagrant

Neigher of them is great because:

  • We definitely wouldn’t like to create vagrant user in production.
  • Conditional runs make cookbooks complicated/error-prone.

I thought if .kitchen.yml supported an array of paths in data_bags_path,
we
could have mycookbook/data_bags and mycookbook/data_bags_for_vagrant which
has
vagrant user with sudo in
cluded
in the groups. But it doesn’t seem to support
arrays at this moment.

Does anyone have the same issue? Any suggestions?

Thanks,

Mitsutoshi Aoe
maoe@foldr.in


#4

On 2/19/14 9:47 PM, maoe@foldr.in wrote:

Hi, I’m using test-kitchen with vagrant, and having trouble with the users
cookbook from opscode.

Suppose we have a bunch of ‘users’ data bag items and some of them have 'sudo’
in the array of groups. If we have a recipe that has users_manage “sudo”,
kitchen converge removes the vagrant user from sudo group because we don’t have
the vagrant user in our data_bags.

I could come up with a few work arounds:

A. Add vagrant user in our data_bags
B. Modify our cookbook so that users_manage “sudo” runs if it’s not in Vagrant

you can ‘detect’ running on vagrant by looking for the presence of the
vagrant user:

sudo “vagrant” do
user "vagrant"
only_if { Etc.getpwent(“vagrant”) }
end

this kind of arbitrary-probe-state-and-then-take-action pattern is one
of the reasons why
pushing ruby code down to the server under management is really powerful.


#5

Hi Lamont,

The sudo cookbook worked. I ended up having to specify existing
privileged users and groups like this:

include_recipe “sudo”

sudo “root” do
user "root"
runas “ALL:ALL” # instead of just ALL
end

sudo “sudo” do
group "sudo"
runas "ALL:ALL"
end

sudo “vagrant” do
user "vagrant"
nopasswd true
only_if { Etc.getpwnam(‘vagrant’) }
end

I was rather opposed to writing vagrant-aware recipes. Probably I was
just too paranoid in this case.

Thanks,

Mitsutoshi Aoe
maoe@foldr.in

2014-02-21 3:49 GMT+09:00 Lamont Granquist lamont@opscode.com:

On 2/19/14 9:47 PM, maoe@foldr.in wrote:

Hi, I’m using test-kitchen with vagrant, and having trouble with the users
cookbook from opscode.

Suppose we have a bunch of ‘users’ data bag items and some of them have
’sudo’
in the array of groups. If we have a recipe that has users_manage “sudo”,
kitchen converge removes the vagrant user from sudo group because we don’t
have
the vagrant user in our data_bags.

I could come up with a few work arounds:

A. Add vagrant user in our data_bags
B. Modify our cookbook so that users_manage “sudo” runs if it’s not in
Vagrant

you can ‘detect’ running on vagrant by looking for the presence of the
vagrant user:

sudo “vagrant” do
user "vagrant"
only_if { Etc.getpwent(“vagrant”) }
end

this kind of arbitrary-probe-state-and-then-take-action pattern is one of
the reasons why
pushing ruby code down to the server under management is really powerful.


#6

On 2/20/14 4:47 PM, Mitsutoshi Aoe wrote:

sudo “vagrant” do
user "vagrant"
nopasswd true
only_if { Etc.getpwnam(‘vagrant’) }
end

I was rather opposed to writing vagrant-aware recipes. Probably I was
just too paranoid in this case.

It does have a bit of “code smell” but its pretty much the thing that
you want. You could try for better precision and look in ohai
information to find out if you were running virtualized under vagrant,
but that detection code may not be as reliable (false negatives).

I just noticed a security edge case which is that if someone can create
an arbitrary new user on your production servers and login as it, then
they could name that ‘vagrant’ and their new account would also gain
root-access (a false positive). That assumes a lot of capabilities on
the part of the attacker, though, but you might want to mitigate that
with a chef_environment != “production” check or something along those
lines…


#7

Good point. I’ll add some checks.

Thanks,

Mitsutoshi Aoe
maoe@foldr.in

2014-02-21 10:20 GMT+09:00 Lamont Granquist lamont@opscode.com:

On 2/20/14 4:47 PM, Mitsutoshi Aoe wrote:

sudo “vagrant” do
user "vagrant"
nopasswd true
only_if { Etc.getpwnam(‘vagrant’) }
end

I was rather opposed to writing vagrant-aware recipes. Probably I was
just too paranoid in this case.

It does have a bit of “code smell” but its pretty much the thing that you
want. You could try for better precision and look in ohai information to
find out if you were running virtualized under vagrant, but that detection
code may not be as reliable (false negatives).

I just noticed a security edge case which is that if someone can create an
arbitrary new user on your production servers and login as it, then they
could name that ‘vagrant’ and their new account would also gain root-access
(a false positive). That assumes a lot of capabilities on the part of the
attacker, though, but you might want to mitigate that with a
chef_environment != “production” check or something along those lines…


#8

On Thu, Feb 20, 2014 at 3:49 PM, Lamont Granquist lamont@opscode.comwrote:

you can ‘detect’ running on vagrant by looking for the presence of the
vagrant user:

sudo “vagrant” do
user "vagrant"
only_if { Etc.getpwent(“vagrant”) }
end

Worth noting that while this is the default on for example VirtualBox
boxes, the username is configurable. Especially with cloud providers like
vagrant-aws the odds are that the login user is something else.

Unfortunately I don’t know any reliable way to detect when running on
Vagrant. Earlier versions set node[“instance_role”] to “vagrant” but I
don’t know why that was removed in Vagrant 1.1.


Cheers,

  • Teemu

#9

Hi Teemu,

We now see introducing container-aware recipes made things
complicated. The getpwnam trick works fine as long as I stick to the
current test environment which is Vagrant, though.

Ideally, we should be able to write container-agnostic cookbooks only
and should be able to inject a configuration for Vagrant using
test-kitchen or whatever tools we use for testing.

Cheers,

Mitsutoshi