I don't think option 2) would be able to support all the cases
we need. Think about, for example custom (commercial) CA for
https. It's pretty complicated even now, and if every puppet
module handled it on its own, one would need to pass the arguments
about the custom CA for all the modules that are dealing with running
https or verifying the remote server.
I agree that puppet-certs is unnecessary complex (it has its own history)
although some of the issues are mostly usability problems. But the principle
works pretty well: the module is responsible for generating and deploying the
certificates.
There still needs however to be some logic on other modules part: I think
it makes sense here to use some defined types that the modules could use
to declare what certs they need. The certs module would generate the certs
and put it on right place, and the modules could count on the fact that the
certs are then there. The puppet-certs uses custom types, which is probably not
the best to do with Puppet 4. But I think we could get similar behavior with defined
types as well.
With this approach, all the cert implementation logic would be in the certs module
(including support for different CAs, revocation/renewal etc.) and all other foreman's
puppet modules would use the same approach to the certs.
Also, I would recommend to research how hard would then be to employ FreeIPA
to the certs generation/distribution process. Ideally, the only change that would
be needed would be on the certs module part, while all the other modules would
stay the same.
– Ivan
> What you are describing would be a spin of puppet-certs but as you say,
> making each module dependent on it and using it's defined certificate setup
> for that service instead of a single orchestrating module. If we take the
> case of needing a root CA and server certificates, you can see that in [1]
> we generate a CA (this would be adopted to generate or use Puppet's) and
> then in [2] we have all the logic needed to generate certificates for the
> server (i.e. Apache). You can see these being orchestrated at [3]. The
> other thing our puppet-certs module does today is break this process down
> into generation, deployment and regeneration of certificates.
>
> So option 3/1 would be some changes, but a large re-use of the existing
> puppet-certs paradigm and code we have today.
>
> [1] https://github.com/Katello/puppet-certs/blob/master/manifests/init.pp
> [2] https://github.com/Katello/puppet-certs/blob/master/manifests/apache.pp
> [3]
> https://github.com/Katello/puppet-katello/blob/master/manifests/init.pp#L63-L64
>
>
>
> > > All,
> > >
> > > As part of the work to make changes such that Katello can be added to an
> > > existing Foreman, we have to deal with the certificate setup required by
> > > Katello and that of existing Foremans. The goal of this thread is to get
> > > feedback on possible design changes to the way we handle certificates
> > > before I go too far down a particular path.
> > >
> > > Background
> > > -----------------
> > >
> > > The strategy that Katello takes today is to use a single puppet module
> > [1]
> > > that contains classes for each service that requires certificates. Each
> > of
> > > these classes assumes knowledge of the init.pp that creates a root CA.
> > > These certificate classes are then orchestrated within the puppet-katello
> > > module [2]. For those curious, the diagram at [3] shows a near complete
> > > list of SSL communication that has to occur today. Further, for a general
> > > idea of all the certificates we generate and services that use them see
> > [4].
> > >
> > > Requirements
> > > --------------------
> > >
> > > Looking ahead to scenarios we have to support, there are:
> > >
> > > 1) Existing Foreman with Puppet certificates as the root CA
> > > 2) Existing Katello+Foreman with puppet-certs custom self-signed
> > > certificates
> > > 3) New installs that want to use Puppet CA as the root CA
> > > 4) New installs that want to use custom certificates (similar to what
> > > Katello does today)
> > > 5) Existing Foreman installs changed over to custom certificates
> > > 6) User provided webserver certificates
> > >
> > > Design Proposals
> > > -------------------------
> > >
> > > 1) puppet-certs approach
> > > pros:
> > > - centralized certificate management into a single module
> > > - allows orchestrating large certificate changes (such as user
> > provided
> > > certificates or certificate regeneration)
> > > cons:
> > > - requires an orchestration/wrapper module to ensure certificates and
> > > other services get done in the right order
> > > - requires every module that needs certificates to have a dependency
> > on
> > > puppet-certs
> > > - requires puppet-certs to have knowledge of every "service"
> > requiring
> > > certs
> > >
> > > 2) Modules control their own certificates
> > > pros:
> > > - modules remain independent
> > > - no orchestration module needed
> > > - can be in charge of generating certificates or being handed
> > > certificates to use
> > > - follows same model as other things like configuration files,
> > service
> > > objects or datastores
> > > cons:
> > > - every module needs to know how to generate and/or sign certificates
> > > - orchestrating regeneration or addition of user certificates might
> > be
> > > difficult
> > >
> > > 3) ??? - there are other possible design ideas that we have not thought
> > of
> > >
> > >
> > > As I said at the beginning, I'd appreciate some feedback and debate in
> > this
> > > area from those who have had experience with Katello certificate
> > management
> > > and the installer (especially @inecas) and those who are outsiders to the
> > > process that might see some fundamentals we are missing. Along with the
> > > requirements above, my goals are:
> > >
> > > 1) Enable the aforementioned requirement scenarios
> > > 2) Simplify certificate management where possible
> > > 3) Enable ease of adoption of Katello with respect to certificates
> > > 4) Provide benefits to Foreman community where possible (such as using
> > non
> > > Puppet CA certificates in an easy to use manner)
> > >
> > >
> > > Thanks,
> > > Eric
> > >
> > >
> > > [1] https://github.com/Katello/puppet-certs
> > > [2]
> > >
> > https://github.com/Katello/puppet-katello/blob/master/manifests/init.pp#L63
> > > [3]
> > >
> > https://raw.githubusercontent.com/ehelms/connection_diagram/master/katello.png
> > > [4]
> > >
> > https://docs.google.com/drawings/d/121tMce_neRowWG8nkDh6BVZCxxjRMGyzFjV1T0jmo2I/edit?usp=sharing
> >
> > Disclaimer: I have not looked at puppet-certs so this is mostly from a
> > foreman perspective. This is sort an option 3 / variation on option 1.
> >
> > I know the current foreman installer is tied to puppet certs, both
> > implicit or explicit causing odd failures if puppet is disabled that are
> > non-obvious for users. That means I'm leaning to a puppet-certs
> > approach. My suggestion would be to create a new module based on
> > puppet-certs with a more specific name (foreman-certs?) that can handle
> > both Puppet CA and custom certs. This would be a benefit for Foreman
> > users who want SSL but not puppet, but also align nicely with Katellos
> > needs.
> >
> > I think the module could be written without a need for
> > orchestration/wrapper module if we have proper dependencies in all
> > modules. It would become a hard dependency in all modules and possibly
> > require major version bumps in modules, but I think it will be cleaner.
> > Of course the module would be optional if the user chooses insecure
> > setups.
> >
> > The hardest part might be to decouple certificate generation from
> > puppet-puppet but puppet-foreman-certs relies on puppet-puppet to
> > install the tools. This screams circular dependencies if you're not
> > careful.
> >
> > What I would want from the module is a way to get the certificates and
> > the result should be paths that the respective modules could use. So a
> > main class that configures Puppet CA / custom CA, then a class for
> > foreman itself. foreman::config would require that class and then use
> > $::foreman_certs::foreman::cert_path / …::key_path / …::ca_path.
The problem here is, the certs class needs to be initialized before we could
use the params. And if we want to have some class params on the certs module,
(such sa CA configuration), we would need to make sure we initialize the class first.
Kafo can handle this, but puppet-master environment AFAIK we can't influence what gets
loaded first.
– Ivan
···
----- Original Message -----
> On Thu, Sep 24, 2015 at 8:48 AM, Ewoud Kohl van Wijngaarden < > ewoud@kohlvanwijngaarden.nl> wrote:
> > On Wed, Sep 23, 2015 at 09:29:49PM -0400, Eric D Helms wrote:
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
