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

Provisioners and DB engines registry #358

Open
maraino opened this issue Aug 20, 2020 · 0 comments
Open

Provisioners and DB engines registry #358

maraino opened this issue Aug 20, 2020 · 0 comments

Comments

@maraino
Copy link
Contributor

maraino commented Aug 20, 2020

Description

Currently, KMSs are registered in certificates when the file is imported using the apiv1.Register method, for example, cloudkms is registered using this:

func init() {
apiv1.Register(apiv1.CloudKMS, func(ctx context.Context, opts apiv1.Options) (apiv1.KeyManager, error) {
return New(ctx, opts)
})
}

Then we import the supported kms engines in main.go:

// Enabled kms interfaces.
_ "github.com/smallstep/certificates/kms/awskms"
_ "github.com/smallstep/certificates/kms/cloudkms"
_ "github.com/smallstep/certificates/kms/softkms"
// Experimental kms interfaces.
_ "github.com/smallstep/certificates/kms/yubikey"

This allows third-party packages to import some of our stuff without the need to import extra libraries or unused functionality.

We should do the same for provisioners and DB engines. Doing this, it will make it easier to extend step-ca with new provisioners, and new DB engines. It would be also possible to create specific builds that enable only specific things.

@maraino maraino added enhancement needs triage Waiting for discussion / prioritization by team labels Aug 20, 2020
@dopey dopey removed the needs triage Waiting for discussion / prioritization by team label Jun 8, 2021
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

2 participants