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 idea & discussion: sql integration #29

Open
cannadayr opened this issue May 6, 2018 · 2 comments
Open

Feature idea & discussion: sql integration #29

cannadayr opened this issue May 6, 2018 · 2 comments

Comments

@cannadayr
Copy link

It would be useful to store signed certificates in a sql database. This could be used for generating revocations, as well as auditing.

Would there be any interest in this?

@bobveznat
Copy link
Member

I spent some time thinking about this and I'm not convinced that a SQL backend is the right approach.

Generally I think the next major feature for the project should be something to enable high availability. And to enable that, the daemon should probably become stateless with an HA backend.

We could use ~any major SQL backend and achieve this goal.

However, the next problem is trying to keep it safe. For most of the installations I'm aware of the ssh-cert-authority is a root of trust in the environment. If we stick a database behind this with a simple username & password the new root of trust is the network-accessible database server and that doesn't feel like a strong authentication mechanism.

I'm also not entirely sure how practical it is to ask that for users to achieve HA they need to deploy an HA RDBMS, which isn't exactly a trivial exercise.

I don't have a great suggestion, but I think we can find a better keeper of state.

@cannadayr
Copy link
Author

Yea, I totally get that.

basically, my current use case is to use the signing daemon to secure my infrastructure. No democratic request signing (NumberSignersRequired = -1).

I plan to use stunnel w/ a pre-shared-key to secure transportation. Future idea is to maybe use kerberos. Something w/ a one-time key that is immediately void after using. Future signed certificates can be done over SSH.

I was actually just testing this out, and it works great, albeit theres a few code paths I had to comment out to prevent having to know the "AuthorizedUsers" in advance.

My next idea was to either save each issued certificate on the filesystem, or add the record to a sqlite database as it happens. This is important to me so I can audit issued certificates.

if any of these changes sound useful, I would be interested in maybe figuring out a way they can be upstreamed without altering the fundamental behavior. No idea when I'll get them to a reasonable place hah.

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

No branches or pull requests

2 participants