Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-763

Add allow-header-cert-info authorization support to all Puppet Server service APIs

    Details

    • Template:
    • Sub-team:
    • Story Points:
      3
    • Sprint:
      Server Emerald 2015-09-30, Server Emerald 2015-10-14, Server Emerald 2015-10-28
    • CS Priority:
      Reviewed

      Description

      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.

      Implementation Notes

      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. TK-282 would add support for the allow-header-cert-info feature to tk-authz, via a new authorization Trapperkeeper configuration section. When that lands, we'll need to update Puppet Server to be able to defer to / utilize authenticated user info from tk-authz, when available, while not breaking the allow-header-cert-info option in Puppet Server's master section. I'm envisioning the following implementation around Puppet Server's request-handler-service, where the allow-header-cert-info work is currently done:

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                erik Erik Dasher
                Reporter:
                chuck Charlie Sharpsteen
                QA Contact:
                Erik Dasher
              • Votes:
                1 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support