The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #5020

Prefer URI over certname when compiling node catalog

Added by Brice Figureau over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:10/16/2010
Priority:NormalDue date:
Assignee:Brice Figureau% Done:

0%

Category:compiler
Target version:2.6.3
Affected Puppet version:2.6.2 Branch:http://github.com/masterzen/puppet/tree/tickets/2.6.x/5020
Keywords:communitypatch

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

As discussed here: http://groups.google.com/group/puppet-dev/browse_thread/thread/45e287d5a0fb8585/e60645baa81b1a96

Since auth.conf (and default inserted rules when no auth.conf exists) provide enough security, it would be great to use the provided compiling URI key as the node name to compile, instead of using the provided SSL certname. It would allow monitoring or puppet-load to simulate any client with only one certificate by changing auth.conf:

path ~ ^/catalog/([^/]+)$ 
method find 
allow $1 
allow puppet-load.domain.com 
allow monitoring.domain.com

History

#1 Updated by Brice Figureau over 5 years ago

  • Branch set to http://github.com/masterzen/puppet/tree/tickets/2.6.x/5020

Sent for review to the puppet-dev list.

#2 Updated by James Turnbull over 5 years ago

  • Status changed from Unreviewed to In Topic Branch Pending Review
  • Target version set to 69

#3 Updated by Matt Robinson over 5 years ago

  • Keywords set to communitypatch

#4 Updated by Matt Robinson over 5 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient

Brice, this does allow you to do what you want, but for some reason it breaks security. You say

This is safe because the default auth.conf (and default inserted rules when no auth.conf is present) only allow the given connected node to compile its own catalog.

However, when I tested this with the default auth.conf I was able to get catalogs other than the one for the connecting node. Not sure why. Without the patch:

err: Forbidden request: localhost(127.0.0.1) access to /catalog/othernodename [find] at line 93

#5 Updated by Matt Robinson over 5 years ago

  • Status changed from Code Insufficient to Ready For Checkin

Looks like I messed up testing the #5020 patch because the helper script I was using to start the puppetmaster was copying an overly permissive auth.conf in. This was a relic of when I was documenting the REST API and wanted to not have to worry about security rules. I was testing the 2.6.x branch without this auth.conf on a different machine, so that’s why it looked like your branch introduced the permission problem.

So +1 to this patch.

On Tue, Oct 26, 2010 at 3:13 AM, Brice Figureau brice-puppet@daysofwonder.com wrote:

This is strange because this authorization check is done way before the catalog compilation terminus is involved (where my modification is).

This is confused me too. I should’ve followed code to see how it could have gotten by the early authorization.

How did you perform your tests?

Using curl to do the requests Using a script to start the puppetmaster (this is where my problem was)

#6 Updated by James Turnbull over 5 years ago

  • Target version changed from 69 to 2.6.3

#7 Updated by James Turnbull over 5 years ago

  • Status changed from Ready For Checkin to Closed

Pushed in commit:ea435a43dc97487d054271a9efb208f361408339 in branch 2.6.x

Also available in: Atom PDF