Puppet users - Mar 2011 - slight security problem

Hey,

Just wondering if anyone else has noticed this.

I''m using thin+puppetmasterd+nginx. If i add a host, sign it''s
key,
run puppetd successfully on it all is good, as expected. If i then
revoke/clean the key on the master server, leave the box running,
startup another host set the hostname to be the same as the old,
generate new keys/have them signed. The original box is still able to
access the puppet server.

If i shutdown nginx and run the fetches via puppetmasterd I get
errors, as expected.

Here is my nginx config:

<code>
upstream puppet-production {
  server                        unix:/var/run/puppet/puppetmasterd.
0.sock;
  server                        unix:/var/run/puppet/puppetmasterd.
1.sock;
  server                        unix:/var/run/puppet/puppetmasterd.
2.sock;
  server                        unix:/var/run/puppet/puppetmasterd.
3.sock;
  server                        unix:/var/run/puppet/puppetmasterd.
4.sock;
}

server {
  listen                        8140;
  ssl                           on;
  ssl_certificate               /var/lib/puppet/ssl/certs/
something.pem;
  ssl_certificate_key           /var/lib/puppet/ssl/private_keys/
something.pem;
  ssl_ciphers                   ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-
EXP;
  ssl_client_certificate        /var/lib/puppet/ssl/ca/ca_crt.pem;

  ssl_verify_client             on;

  root                          /var/empty;
  access_log                    /var/log/nginx/access-8140.log;

  proxy_redirect                off;
  proxy_set_header              Host              $host;
  proxy_set_header              X-Real-IP         $remote_addr;
  proxy_set_header              X-Forwarded-For
$proxy_add_x_forwarded_for;
  proxy_set_header              X-Client-Verify  SUCCESS;
  proxy_set_header              X-Client-DN $ssl_client_s_dn;
  proxy_set_header              X-SSL-Subject    $ssl_client_s_dn;
  proxy_set_header              X-SSL-Issuer     $ssl_client_i_dn;
  proxy_read_timeout            65;

  location / {
    proxy_pass                  http://puppet-production;
  }
}
</code>

and here is how i start puppetmasterd:

/usr/bin/thin start -P /var/run/puppet/$ROLE_NAME.pid -e production --
servers 5 --daemonize --socket /var/run/puppet/$ROLE_NAME.sock --
chdir /etc/puppet/ --user puppet --group puppet -R /etc/puppet/
config.ru

With the contents of config.ru being:

<code>
$0 = "puppetmasterd"
ARGV << "--rack"
require ''puppet/application/puppetmasterd''
run Puppet::Application[:puppetmasterd].run
</code>

It''s not that big of a deal as the puppet setup is heavily firewalled,
but i''m still interested.

Thanks

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Mar 14, 2011 at 2:36 AM, Michael Dodwell
<michael.dodwell@gmail.com> wrote:
> Hey,
>
>
> If i shutdown nginx and run the fetches via puppetmasterd I get
> errors, as expected.
>
If you restart nginx, does the old client still work? Am guessing
nginx needs to have access to, and use, an updated revocation list
file, or something like that?

Mohamed.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.