Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Certmgr as an in-process supervisor #40

Open
andrewplunk opened this issue Apr 23, 2018 · 5 comments
Open

Feature: Certmgr as an in-process supervisor #40

andrewplunk opened this issue Apr 23, 2018 · 5 comments

Comments

@andrewplunk
Copy link

Problem:
Currently it's difficult to use certmgr as an in-process supervisor.

Use case:
I am a go library that doesn't want to require my customers to configure Certmgr with cert.Spec JSON files, instead letting them pass in configuration via function parameters.

Potential Solution:

  1. Remove the checked-in vendor directory. This causes type issues when using certmgr as a library.
  2. Expose the svcmgr.Manager interface on Manager (either within the Manager struct or via a constructor). This will enable users of certmgr to pass in their own svcmgr.Manager implementations, enabling users to restart/reload their process as needed.
  3. Don't require cert.Spec to exist on the filesystem. Currently the Load() function initializes the renew channel. This makes it impossible to configure certmgr without writing a Spec to the filesystem, which is cumbersome from a library perspective.
@kisom
Copy link
Contributor

kisom commented Apr 23, 2018

This is really interesting --- I'd never really considered the use case where certmgr was a library.

To address the points:

  1. Easy enough. The only thing I really worry about it is dependencies disappearing from Github, but the risk is low because only the prometheus library and cobra/viper packages are the external dependencies.
  2. This should also be relatively straightforward.
  3. This could be done by having a different function to return an initialised manager.

letting them pass in configuration via function parameters.

What does that look like?

@cbroglie
Copy link
Contributor

Could you just migrate to dep for 1?

@kisom
Copy link
Contributor

kisom commented Apr 23, 2018

@cbroglie Indeed.

@kisom
Copy link
Contributor

kisom commented Apr 23, 2018

@andrewplunk One thing that occurs to me, have you tried using the CFSSL transport package? certmgr is essentially a UI on top of this, so it might be useful, too.

@andrewplunk
Copy link
Author

@kisom

letting them pass in configuration via function parameters.

What does that look like?
I would like my clients to provide my library with the CA label and auth key required to provision certs from the transport. I would then configure certmgr with my own svcmgr.Manager implementation to handle reloading the tls.GetClientCertificate/tls.GetCertificate's caches as necessary.

@andrewplunk One thing that occurs to me, have you tried using the CFSSL transport package? certmgr is essentially a UI on top of this, so it might be useful, too.

You're totally right I could build this on top of the CFSSL transport package. I will do so if you don't think that certmgr makes sense as a library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants