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

Refine vault: config location #488

Closed
mp911de opened this issue Sep 18, 2020 · 4 comments
Closed

Refine vault: config location #488

mp911de opened this issue Sep 18, 2020 · 4 comments

Comments

@mp911de
Copy link
Member

mp911de commented Sep 18, 2020

We should accept vault: and vault:// config locations as default config location that use enabled secret backend discovery. Additionally, we should accept vault:///<context-path (e.g. vault:///secret/my/app/key) to allow mounting individual context paths without pulling the entire set of all property-enabled secret backends.

It does not make sense to accept a hostname since Vault is session-oriented and a custom hostname would conflict with session management.

@acemoo
Copy link

acemoo commented Mar 15, 2021

It seems context paths are supported now. But I do have one problem with this.
Example: vault has 2 sets of credential secrets.

/kafa/secrets/application
/secrets/cassandra/application

Both of the sets are username/password.
So the following doesn't work since one of the two sets of secrets would overwrite the other.

spring:
  config:
    import: vault://kafka/secrets/application, vault://secrets/cassandra/application
kafka.username: ${username}
kafka.password: ${password}
cassandra.username: ${username}
cassandra.password: ${password}

Would it be possible to do something like this?

spring:
  config:
    import: vault://kafka/secrets/application, vault://secrets/cassandra/application
kafka.username: ${kafka.secrets.application.username}
kafka.password: ${kafka.secrets.application.password}
cassandra.username: ${secrets.cassandra.application.username}
cassandra.password: ${secrets.cassandra.application.password}

@mp911de
Copy link
Member Author

mp911de commented Mar 15, 2021

For now, we don't have a possibility to associate a PropertyTransformer when importing individual mounts. Your example above uses a prefix derived from the mount path. Another variant would be to use a static prefix (e.g. vault://secrets/cassandra/application?prefix=cassandra resulting in cassandra.username: ${cassandra.username}).

In the context of Vault, only the context path makes sense for inclusion. Additional URL-like elements such as fragment or the query string cannot be applied for mounting so these could be candidates to pass on additional details. For versioned backends, one could also specify vault://secrets/cassandra/application?version=42.

@acemoo
Copy link

acemoo commented Mar 15, 2021

I think adding support for ?prefixWithPath=true and ?prefix=customPrefix would be nice.
I'd be interested in making a pull request for adding support to this, could you give me some pointers to get started?

@mp911de
Copy link
Member Author

mp911de commented Mar 16, 2021

For start, let's go for prefix=…. You can start with VaultConfigDataLocationResolver as VaultConfigLocation (encapsulating SecretBackendMetadata and PropertyTransformer) are built there.

mp911de pushed a commit that referenced this issue Jun 18, 2021
mp911de added a commit that referenced this issue Jun 18, 2021
Add author tags. Let VaultConfigLocation accept PropertyTransformer. Extract prefix computation into its own method. Tweak documentation wording.

See gh-488
Original pull request: gh-582.
mp911de pushed a commit that referenced this issue Jun 18, 2021
mp911de added a commit that referenced this issue Jun 18, 2021
Add author tags. Let VaultConfigLocation accept PropertyTransformer. Extract prefix computation into its own method. Tweak documentation wording.

See gh-488
Original pull request: gh-582.
mp911de pushed a commit that referenced this issue Jun 18, 2021
mp911de added a commit that referenced this issue Jun 18, 2021
Add author tags. Let VaultConfigLocation accept PropertyTransformer. Extract prefix computation into its own method. Tweak documentation wording.

See gh-488
Original pull request: gh-582.
@mp911de mp911de added this to the 3.0.4 milestone Jun 18, 2021
@mp911de mp911de closed this as completed Jun 18, 2021
spencergibb pushed a commit that referenced this issue Sep 14, 2023
spencergibb pushed a commit that referenced this issue Sep 14, 2023
Add author tags. Let VaultConfigLocation accept PropertyTransformer. Extract prefix computation into its own method. Tweak documentation wording.

See gh-488
Original pull request: gh-582.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants