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

ability to manage a default secret that would be always injected in services #760

Open
fcomte opened this issue Feb 23, 2024 · 6 comments
Open

Comments

@fcomte
Copy link
Contributor

fcomte commented Feb 23, 2024

Secrets are not often use by users because it's quite complex to use it.
One idea would be to manage a default secret (a list of secrets) that would be always injected without any effort from the user

@fcomte fcomte added this to the Vault improvements milestone Feb 23, 2024
@fcomte
Copy link
Contributor Author

fcomte commented Feb 23, 2024

One implementation could be to maintain a list of all paths that should be automatycally injected.
A user can then opt-in very quickly for each secret.

@qgau
Copy link
Contributor

qgau commented Feb 23, 2024

Thanks for creating this issue.

On my side, I was actually thinking about a more straitforward/naive experience: by default, all the user secrets are injected in the services environment as environment variables.
With, of course, a big banner to warn the users in the service configuration view, which would contain a direct link to vault configuration tab for example.

But then there is the question of secret variables with the same name, but in different secrets and/or directories. For these cases, I think we could actually not care about it and just overwrite variables previously defined in the environment, because this "default" behavior would be only for onboarding/newcomers users. Advanced users with plenty of secrets won't use this option anyway: they will care about what service has access to what secret.

That being said, a default secret at the root, called "default" and containing a "SECRET_EXAMPLE" variable could do the job perfectly.

BTW, reading @fcomte 's previous comment makes me think maybe the user uptake is difficult also because there is no auto-completion for the secret paths in the vault tab. I don't how difficult it is to implement that though.

My two cents!

@fcomte
Copy link
Contributor Author

fcomte commented Feb 23, 2024

my idea is quite simple :

image

When a user write a secret he has the possibility to enable it by default for all services.

Behind the scene we maintain this path (somewhere in vault but silently)
And when we start vscode we create all the en var based on this secret list of path

I would prefer this kind of implementation in comparaison to the "one big default secret" because it's more maintenable by the user.

@fcomte
Copy link
Contributor Author

fcomte commented Feb 23, 2024

we can also add a new icon here :

image

to let the user know that this specific secret is always put in services.

@qgau
Copy link
Contributor

qgau commented Feb 23, 2024

Oh I see it now! This is really better than my idea 👍

@fcomte
Copy link
Contributor Author

fcomte commented Feb 23, 2024

This is all your idea.. I think it can greatly improve the UX on the secret usage. thank you 🙏

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