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

Support Juju's User Secrets for supplying confidential material #112

Open
jameinel opened this issue Apr 3, 2024 · 1 comment
Open

Support Juju's User Secrets for supplying confidential material #112

jameinel opened this issue Apr 3, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jameinel
Copy link
Member

jameinel commented Apr 3, 2024

Describe the bug

Currently the way to provide things like passwords is via charm configuration. Juju 3.3 and beyond has implemented support for User Secrets, that allows you to supply content that you consider sensitive (passwords, private keys, etc)

To Reproduce

Configuring your httprequest-lego-k8s-operator currently expects you to pass a couple of things that might be considered sensitive as standard charm config. eg:

juju config httprequest-lego-k8s \
    email='my-email@example.com' \
    httpreq_endpoint='https://lego-certs.example.com' \
    httpreq_password='${YOUR-PASSWORD}' \
    httpreq_propagation_timeout=600 \
    httpreq_username='${YOUR-USERNAME}'

While the visibility of that content is restricted to users and the application in question (other applications cannot ask for the config of an app that is not theirs), it is still content that would show up in juju config, and is stored in plain text inside juju.

With secrets, at least there is the option to store them in something like vault, and by default the content isn't shown unless you explicitly ask for the secret content, and it is only available to users with Write permission on a model (vs anyone with Read).

Expected behavior

It does complicate the workflow a bit, because you have to have a secret in order to grant and share it to an application, but you also have to have the application in order to have a target to grant.
So the steps become:

juju deploy httprequest-lego-k8s
SECRET_ID=`juju add-secret NAME_FOR_ME password=XXXX username=YYY`
juju grant-secret NAME_FOR_ME httprequest-lego-k8s
juju config httprequest-lego-k8s httpreq_secret=$SECRET_ID

You also need to add a config entry (httpreq_secret) with type "secret" to the charm, and then respond to the config-changed event that happens in step 4 above. You would also need to handle secret-changed events in the case that a user decides to juju update-secret NAME_FOR_ME.)

@jameinel jameinel added the bug Something isn't working label Apr 3, 2024
@gruyaume
Copy link
Contributor

gruyaume commented Apr 4, 2024

Thank you @jameinel for opening this. This applies to all the LEGO K8s operators. We will specify this and include it into our 24.10 roadmap.

@gruyaume gruyaume added enhancement New feature or request and removed bug Something isn't working labels Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants