[Puppet Users] MCollective security
Hi! Not long ago we started using MCollective to trigger Puppet runs and execute maintenance shell commands on our servers. Everything looks good so far. But I'm concerned about MC security model. For the middleware we are using RabbitMQ. We authenticate MCollective servers against RabbitMQ with username/password pair. Also we have Stunnel for middleware SSL termination. We use Puppet CA signed certificates to verify MCollective servers. However I noticed that an attacker can easily change a hostname on a compromised server. And after that the server will get registered with that hostname. When I execute mco find I see it displayed with the hostname that was recently set. And the hostname can be equal to any of the existing servers. That means that if I execute a shell command via mco shell run -I "/existinghostnamemask/" "command" it will be also executed on the compromised server. The server can get sensitive data that it is not supposed to have. I hope I explained everything correctly :) So my question is - is there a way to avoid situations like the one I described? For example if I use SSH to connect to a host, I get its public key, and if the host changes, I receive an error. But probably there is something like this for MCollective? Thanks! Regards, Sergey -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/856E0B90-FE48-43EE-96EA-6378867B4DBA%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] MCollective security
On Fri, 7 Sep 2018, at 10:58, Sergey Arlashin wrote: > Hi! > > Not long ago we started using MCollective to trigger Puppet runs and > execute maintenance shell commands on our servers. Everything looks good > so far. But I'm concerned about MC security model. > > For the middleware we are using RabbitMQ. We authenticate MCollective > servers against RabbitMQ with username/password pair. Also we have > Stunnel for middleware SSL termination. We use Puppet CA signed > certificates to verify MCollective servers. > > However I noticed that an attacker can easily change a hostname on a > compromised server. And after that the server will get registered with > that hostname. When I execute > > mco find > > I see it displayed with the hostname that was recently set. And the > hostname can be equal to any of the existing servers. > > That means that if I execute a shell command via > > mco shell run -I "/existinghostnamemask/" "command" > > it will be also executed on the compromised server. The server can get > sensitive data that it is not supposed to have. > > I hope I explained everything correctly :) > > So my question is - is there a way to avoid situations like the one I > described? For example if I use SSH to connect to a host, I get its > public key, and if the host changes, I receive an error. But probably > there is something like this for MCollective? You should use choria.io to deploy mcollective, mcollective as you deployed do have ways to restrict access and harden the security model - but its a LOT of work to setup. Choria does all of this for you, nodes use their puppet certificates. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1536311776.908972.1499976648.3FEAE11E%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Duplicate declaration
Hi,
I have made a module, a long time ago, that allows me to create directories
and httpd config files.
My pattern is /var/www/dev/$devuser/$clientname/$appname/
It worked perfectly until I ended up having more than one $appname for the
same $clientname. Here's the error message I get:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: File[/var/www/dev/user1/client1] is already declared
in file /etc/puppet/modules/atqapache/manifests/vhost.pp:146; cannot
redeclare at /etc/puppet/modules/myapache/manifests/vhost.pp:146 on node
server1.example.com
The directive responsible for the creation of the folder is this one:
file { [ "$client_base", ]:
ensure => 'directory',
owner => "$owner",
group => "$group",
mode=> 0744,
}
This line defines the variable:
$vhost_base =
"${atqapache::params::home}/$envstage/$client-${application}"
Here's my declaration:
atqapache::vhost { 'client1-user1app1dev1' :
client => 'client1',
envstage => 'dev',
application=> 'app1',
devuser=> 'user1',
}
atqapache::vhost { 'client1-user1app2dev11' :
client => 'clien1',
envstage => 'dev',
application=> 'app2',
devuser=> 'user1',
}
Does anyone know how I could modify my code so that I can have more than
one app per client?
Thanks,
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/6a2b9af3-0fb9-4c38-b0a1-7245b2762d38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Duplicate declaration
Separate the client base directory resource from the application directory
resource.
When declaring each application directory, add a “require” parameter with a
value of the client base directory.
"Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us."
Bill Waterson (Calvin & Hobbes)
> On Sep 7, 2018, at 5:05 PM, Ugo Bellavance wrote:
>
> Hi,
>
> I have made a module, a long time ago, that allows me to create directories
> and httpd config files.
>
> My pattern is /var/www/dev/$devuser/$clientname/$appname/
>
> It worked perfectly until I ended up having more than one $appname for the
> same $clientname. Here's the error message I get:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Duplicate declaration: File[/var/www/dev/user1/client1] is already declared
> in file /etc/puppet/modules/atqapache/manifests/vhost.pp:146; cannot
> redeclare at /etc/puppet/modules/myapache/manifests/vhost.pp:146 on node
> server1.example.com
>
> The directive responsible for the creation of the folder is this one:
>
> file { [ "$client_base", ]:
> ensure => 'directory',
> owner => "$owner",
> group => "$group",
> mode=> 0744,
> }
>
> This line defines the variable:
>
> $vhost_base =
> "${atqapache::params::home}/$envstage/$client-${application}"
>
> Here's my declaration:
>
> atqapache::vhost { 'client1-user1app1dev1' :
> client => 'client1',
> envstage => 'dev',
> application=> 'app1',
> devuser=> 'user1',
> }
>
> atqapache::vhost { 'client1-user1app2dev11' :
> client => 'clien1',
> envstage => 'dev',
> application=> 'app2',
> devuser=> 'user1',
> }
>
> Does anyone know how I could modify my code so that I can have more than one
> app per client?
>
> Thanks,
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/6a2b9af3-0fb9-4c38-b0a1-7245b2762d38%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4F07EDE9-211A-4D02-855D-4FDE3E731732%40icloud.com.
For more options, visit https://groups.google.com/d/optout.
