We have evaluated Puppet and Chef during one and a half month and have "almost"
decided to go with Chef !
“Almost” because we have got a “no-go” from the responsable of the
infrastructure due to the lack of security on node informations
I explain:
We will have different VMs for different customers connected to the same Chef
Server.
When a node is connected to the Chef Server, with a properly knife configured
on it, it is possible to retrieve the list of all nodes from the Chef Server,
show the attributes of the different nodes, search the attributes among all the
nodes, and so on…
This is a big issue for us since we must prevent a customer to see any
information about other customer. And I guess we are not the only ones who met
this issue…
We consider as a security threat that, from a node, it is possible to show
information on other nodes.
We have looked for solution, and the only one we have found so far is to modify
the source code of the Chef Server API in order to add restriction such “a node
is able to see only its own information”.
Before we start to look more deeply in this solution, could you please let us
know if you see any other solution to our problem please ?
We have evaluated Puppet and Chef during one and a half month and have "almost"
decided to go with Chef !
"Almost" because we have got a "no-go" from the responsable of the
infrastructure due to the lack of security on node informations
I explain:
We will have different VMs for different customers connected to the same Chef
Server.
When a node is connected to the Chef Server, with a properly knife configured
on it, it is possible to retrieve the list of all nodes from the Chef Server,
show the attributes of the different nodes, search the attributes among all the
nodes, and so on...
This is a big issue for us since we must prevent a customer to see any
information about other customer. And I guess we are not the only ones who met
this issue...
We consider as a security threat that, from a node, it is possible to show
information on other nodes.
We have looked for solution, and the only one we have found so far is to modify
the source code of the Chef Server API in order to add restriction such "a node
is able to see only its own information".
Before we start to look more deeply in this solution, could you please let us
know if you see any other solution to our problem please ?
Thanks in advance for your feedback.
You can use the ACLs system in Hosted Chef to lock down this kind of access to a degree. The search index will still be a problem. Chef server isn't designed for multi-tennancy at the level of the organization (or at the level of the server for FOSS users), to get true isolation you need to create one org (or server) per tenant.
We have evaluated Puppet and Chef during one and a half month and have
"almost"
decided to go with Chef !
"Almost" because we have got a "no-go" from the responsable of the
infrastructure due to the lack of security on node informations
I explain:
We will have different VMs for different customers connected to the same
Chef
Server.
When a node is connected to the Chef Server, with a properly knife
configured
on it, it is possible to retrieve the list of all nodes from the Chef
Server,
show the attributes of the different nodes, search the attributes among
all the
nodes, and so on...
This is a big issue for us since we must prevent a customer to see any
information about other customer. And I guess we are not the only ones who
met
this issue...
We consider as a security threat that, from a node, it is possible to show
information on other nodes.
We have looked for solution, and the only one we have found so far is to
modify
the source code of the Chef Server API in order to add restriction such "a
node
is able to see only its own information".
Before we start to look more deeply in this solution, could you please let
us
know if you see any other solution to our problem please ?
We have looked for solution, and the only one we have found so far is to
modify the source code of the Chef Server API in order to add restriction
such "a node is able to see only its own information".
Before we start to look more deeply in this solution, could you please let
us know if you see any other solution to our problem please ?
You can use the ACLs system in Hosted Chef to lock down this kind of access to
a degree. The search index will still be a problem. Chef server isn't designed
for multi-tennancy at the level of the organization (or at the level of the
server for FOSS users), to get true isolation you need to create one org (or
server) per tenant.
Christoph's security criterion seems to exclude the Chef server entirely -- if
looking up information about other clients concerns them, making dynamic
configuration decisions based on their data would probably also be out of
bounds. If all they want is to build isolated nodes using the Chef language,
chef-solo will do the trick (plus some glue for distributing the Chef repo).
We have evaluated Puppet and Chef during one and a half month and have "almost"
decided to go with Chef !
"Almost" because we have got a "no-go" from the responsable of the
infrastructure due to the lack of security on node informations
I explain:
We will have different VMs for different customers connected to the same Chef
Server.
When a node is connected to the Chef Server, with a properly knife configured
on it, it is possible to retrieve the list of all nodes from the Chef Server,
show the attributes of the different nodes, search the attributes among all the
nodes, and so on...
This is a big issue for us since we must prevent a customer to see any
information about other customer. And I guess we are not the only ones who met
this issue...
We consider as a security threat that, from a node, it is possible to show
information on other nodes.
We have looked for solution, and the only one we have found so far is to modify
the source code of the Chef Server API in order to add restriction such "a node
is able to see only its own information".
Before we start to look more deeply in this solution, could you please let us
know if you see any other solution to our problem please ?
we had faced the exact problem, as we run a large CI grid which serves
multiple clients and everything is maintained via chef. Chef environments
are not first class, i.e. the isolation is only limited to run list and
attributes. Also, a node can rejoin to other environments, theres no easy
way to restrict them or bind them to a particular environment by server
side configuration. We have ended up using multiple chef server. We also
had the requirement of per client network isolation (VLAN) and i think its
just easier to maintain multiple chef api server , solr instances , but you
can re-use the couch db or rabbitmq server.
We have evaluated Puppet and Chef during one and a half month and have
"almost"
decided to go with Chef !
"Almost" because we have got a "no-go" from the responsable of the
infrastructure due to the lack of security on node informations
I explain:
We will have different VMs for different customers connected to the same
Chef
Server.
When a node is connected to the Chef Server, with a properly knife
configured
on it, it is possible to retrieve the list of all nodes from the Chef
Server,
show the attributes of the different nodes, search the attributes among
all the
nodes, and so on...
This is a big issue for us since we must prevent a customer to see any
information about other customer. And I guess we are not the only ones
who met
this issue...
We consider as a security threat that, from a node, it is possible to
show
information on other nodes.
We have looked for solution, and the only one we have found so far is to
modify
the source code of the Chef Server API in order to add restriction such
"a node
is able to see only its own information".
Before we start to look more deeply in this solution, could you please
let us
know if you see any other solution to our problem please ?
