[SERVER-763] Add allow-header-cert-info authorization support to all Puppet Server service APIs Created: 2015/06/11 Updated: 2015/11/19 Resolved: 2015/10/21
|Affects Version/s:||SERVER 1.1.0, SERVER 2.1.0|
|Fix Version/s:||SERVER 2.2.0|
|Reporter:||Charlie Sharpsteen||Assignee:||Erik Dasher|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Epic Link:||Green: auth.conf replacement|
|Sprint:||Server Emerald 2015-09-30, Server Emerald 2015-10-14, Server Emerald 2015-10-28|
Puppet Server can be configured to with external SSL termination whereby another upstream server, such as Nginx or Apache, handles HTTPS connections and forwards plain HTTP traffic to Puppet Server. This configuration also includes the allow-header-cert-info option which allows Puppet Server to make authorization decisions based on client information forwarded by the upstream server through X-Client-* headers. However, this authorization only applies to API endpoints in the Puppet Master subsystem. Clojure-level Puppet Server APIs, such as the CA and Administrative API endpoints, ignore the certificate headers forwarded by the upstream server.
This is a feature request for allow-header-cert-info support in all Puppet Server APIs.
We've decided that we're going to facilitate this request via the work that we're doing in trapperkeeper-authorization (tk-authz) to provide unified endpoint authorization in Puppet Server.
1) In Puppet Server request-handler-core, attempt to derive authenticated user info from the authorization key in the Ring request map. If the authorization key is not available but the master.allow-header-cert-info setting is set to "true", attempt to derive the authenticated user info from X-Client-* headers on the Ring request map (using supporting Puppet configuration). If the authorization key is not available and the master.allow-header-cert-info setting is not specified or set to "false" (the default), attempt to derive the authenticated user info from the SSL client certificate, ssl-client-cert, on the Ring request map. If authenticated user info cannot be derived by any of the methods above, set the user identity as "unauthenticated".
2) If the master.allow-header-cert-info setting is present in configuration, log an appropriate deprecation warning. If the jruby-puppet.use-legacy-auth-conf setting is set to "false", the warning message should indicate that the master.allow-header-cert-info setting will be ignored in favor of the authorization.allow-header-cert-info setting. If the jruby-puppet.use-legacy-auth-conf setting is set to "true", the warning message should indicate that the user should consider setting the jruby-puppet.use-legacy-auth-conf setting to "false" and using the authorization.allow-header-cert-info setting as a replacement.
|Comment by Jeremy Barlow [ 2015/06/16 ]|
Charlie Sharpsteen, Kaitlin Carter - We do have the ability to turn off client certificate authentication completely for both the administrative API and the certificate-status APIs. See the documentation for the authorization-required key in the http://docs.puppetlabs.com/puppetserver/1.0/configuration.html#puppetserverconf and http://docs.puppetlabs.com/puppetserver/1.0/configuration.html#caconf sections, respectively. Would this approach be sufficient to meet the need for this request or would requests need to have the client-whitelist "authenticated" against the X-Client-* headers?
|Comment by Charlie Sharpsteen [ 2015/06/16 ]|
The user that requested this functionality was trying to control access using a whitelist and the X-Client- headers. I'm not sure whether this logic could be moved up to the Nginx layer or not.
|Comment by Jeremy Barlow [ 2015/08/10 ]|
Per some discussion on https://tickets.puppetlabs.com/browse/SERVER-801?focusedCommentId=204140&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-204140, the current proposal to support this ticket would be to add this logic to the "trapperkeeper-authorization" project. The Ring middleware function in "trapperkeeper-authorization" would be responsible for extracting the user identity from X-Client- headers vs. the subject CN on an SSL client certificate based on whether or not the allow-header-cert-info setting were set.
By keeping this logic in trapperkeeper-authorization, the planned Puppet "auth.conf" replacement which would cover both Clojure-backed and Ruby-backed endpoints that Puppet Server services, all Puppet Server endpoints would be able to utilize this capability - including the CA and Administrative endpoints mentioned in this ticket's description. As part of this, the allow-header-cert-info setting will likely need to migrate from the "master" section of Puppet Server's configuration to the "authorization" section of Trapperkeeper configuration that the "trapperkeeper-authorization" service will manage. This would hopefully make the scope of the setting as covering all "authorization" service controlled endpoints more clear. Note that "trapperkeeper-authorization" may, in the future, be used in a Clojure service stack where Puppet Server's "master" service is not present, so keeping it in the "master" section only would be problematic.
|Comment by Jeremy Barlow [ 2015/09/02 ]|
Eric Sorenson - so my understanding is that we're basically in agreement with the idea of adding an allow-header-cert-info setting to the authorization section that we'll be supporting for trapperkeeper-authorization. So for the case that someone wanted to enable authentication via X-Client headers, an authorization section would look something like:
For the Puppet Server implementation of the X-Client auth feature, we consult puppet.conf settings for the names of the HTTP headers that we use for authentication - ssl_client_header (https://docs.puppetlabs.com/references/latest/configuration.html#sslclientheader) and ssl_client_verify_header (https://docs.puppetlabs.com/references/latest/configuration.html#sslclientverifyheader). This would allow the user to specify a custom name for the HTTP header rather than just using the defaults of X-Client-DN and X-Client-Verify, respectively.
For the trapperkeeper-authorization implementation of this feature, we'll need to avoid having any dependencies on puppet.conf settings - especially since it may eventually be used in an app stack where legacy Puppet is not involved. Do we think we need to preserve the ability for users to customize the client_dn and client_verify headers in the trapperkeeper-authorization implementation? If so, we'd presumably need to add those settings to the authorization configuration as well.
Not that this is a well used part of the feature yet, but I know that when we incorporated support for forwarding a client certificate via the X-Client-Cert header, we chose not to provide a configuration setting for that header and there was no existing setting for this in puppet.conf to draw from. Essentially, the "user" (i.e., load balancer) would be forced to specify the HTTP header as X-Client-Cert. To my knowledge, we haven't had any requests to create a new setting to allow users to change the name of the X-Client-Cert setting. If we think we need to add settings for customizing the client_dn and client_verify headers to trapperkeeper-authorization, though, it probably would make sense for the certificate one to be configurable as well.
Is this the kind of thing where, for trapperkeeper-authorization, it might make sense to do an initial implementation that doesn't allow for the header names to be configurable for now but add on later only when/if needed?
|Comment by Jeremy Barlow [ 2015/09/30 ]|
Merged to puppet-server master branch at 69e80d.
|Comment by Jeremy Barlow [ 2015/09/30 ]|
Full Jenkins acceptance test job passed at http://jenkins-enterprise.delivery.puppetlabs.net/view/puppet-server/view/all/job/enterprise_puppet-server_integration-system_no-conditional_full-master/163/.
Moving to testing.
|Comment by Erik Dasher [ 2015/10/21 ]|
Validated manually with 2015.3.0-rc3-515-g69d6950 on CentOS6. Example here:
Also validated the removing allow-header-cert-info from the configuration made it so the previously working curl command returns HTTP 403 Forbidden.