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

Add mixin (?) for managing a secrets-backed private key #1328

Open
sed-i opened this issue Aug 22, 2024 · 6 comments
Open

Add mixin (?) for managing a secrets-backed private key #1328

sed-i opened this issue Aug 22, 2024 · 6 comments
Labels

Comments

@sed-i
Copy link
Contributor

sed-i commented Aug 22, 2024

Most server apps need a private key. Vault/manual or not, it is probably going to be mediated via juju secrets.
Since the lifecycle of secrets/privkey is probably closer to the hearts and minds of OF folk, and since we probably want some uniformity in this basic feature, I wonder if something like an ops-provided mixin could work.

from ops.mixins import PrivateKey

class MyCharm(PrivateKey, CharmBase):
    ...

Getting, rotating etc. workflows should probably be the same across charms, so it would be great if ops provided a building block like that.

The main advantage I see over a charm-lib is that users won't need to deal with manually observing custom events. I'm imagining a "plug and play" ux similar to rust traits. Not sure if it's feasible but wanted to share the general idea with you.

@dimaqq
Copy link
Contributor

dimaqq commented Aug 26, 2024

Are you're thinking some helper methods and some @abstractmethod's that the charm has to implement?

@sed-i
Copy link
Contributor Author

sed-i commented Aug 26, 2024

@abstractmethod's that the charm has to implement

Experience wise I was hoping that ops would implement everything. Or as much as possible. Privkey mgmt seems pretty basic need for the vast majority of charms. That's why something like a mixin came to mind.

@tonyandrewmeyer
Copy link
Contributor

@jdkandersson I'm curious what your thoughts are on this, particularly given canonical/paas-app-charmer#46

@jdkandersson
Copy link

I think it is true that private key management is a common requirement across charms and there should be some common library or shared code for it. It would also probably fit in quite well into the charm tech team as a home

I'm not sure if it 100% fits into the ops library since how to implement key rotation seems like it would be something the charm should implement. So perhaps it should be located in some other library? The ops library seems to be most focussed on managing interactions between the charm and juju

I'm also curios about what the requirements of this kind of private management keys would look like?

@benhoyt
Copy link
Collaborator

benhoyt commented Sep 27, 2024

We'd like to give this some thought as part of our charm libraries work in 25.04.

@benhoyt benhoyt added needs design needs more thought or spec 25.04 labels Sep 27, 2024
@benhoyt
Copy link
Collaborator

benhoyt commented Sep 27, 2024

@sed-i If you can comment on specific requirements, that'd be great to seed the discussion.

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

No branches or pull requests

5 participants