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 Mapping GCP Secret Name -> Configuration Name #2

Closed
Cooksauce opened this issue Mar 1, 2022 · 3 comments · Fixed by #3
Closed

Support Mapping GCP Secret Name -> Configuration Name #2

Cooksauce opened this issue Mar 1, 2022 · 3 comments · Fixed by #3
Labels
enhancement New feature or request

Comments

@Cooksauce
Copy link

Would you be interested accepting a PR to allow some options to map the GCP secret name to dotnet config name.
Something like:
"my-gcp-secret" -> "My:Dotnet:Value"

This would be helpful in removing the need for the GCP name to match the structure of the project, allow the dotnet app settings to be refactored without affecting the secrets manager, etc.

@Cultti
Copy link
Owner

Cultti commented Mar 1, 2022

Interesting idea. So you have an existing GCP secret manager with existing keys that are used by other projects and would like to reuse those secrets?

My plan is to follow as closely as possible with the Azure Key Vault .Net implementation. So for this feature, we would likely implement something similar to KeyVaultSecretManager (https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-6.0#use-a-key-name-prefix). For default behavior we would need to move the current behaviour that maps two underscores into a single colon into this manager.

@Cultti Cultti added the enhancement New feature or request label Mar 1, 2022
@Cooksauce
Copy link
Author

So you have an existing GCP secret manager with existing keys that are used by other projects and would like to reuse those secrets?

Essentially. Or, for various reasons, want to share a GCP secret between projects without coupling their dotnet configuration structure

So for this feature, we would likely implement something similar to KeyVaultSecretManager

That seems like a good idea to me - looks to be quite extendable.

@Cultti Cultti closed this as completed in #3 Mar 5, 2022
Cultti added a commit that referenced this issue Mar 5, 2022
* Support custom key mapping

* Update README.md

* Make default loader methods virtual so they can be overridden

* Small refactor for tests

* Add tests to verify loader is called from provider

Closes #2
@Cultti
Copy link
Owner

Cultti commented Mar 5, 2022

With version 2.0.0 there is now ISecretManagerConfigurationLoader available that you can reimplement however you like. It exposes two methods: Load and GetKey. Load returns true if the key should be loaded and in the default implementation, it returns always true. GetKey returns mapped configuration value and in the default loader, it formats those two underscores with a colon.

You can also inherit from the default implementation of the interface named DefaultSecretManagerConfigurationLoader in which you may override one of or both those methods. And your implementation can be passed in the options with the Loader property.

Let me know if there are any issues and let's look into those :)

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

Successfully merging a pull request may close this issue.

2 participants