Naming convention of generated tokens

[cm3brian]

First, thank you for this project, it was exactly what we needed to backend vault-secrets-operator and fix the impact of the 16.x 1 year max token expiry that caught us out a few weeks back.

Now we have scaled up using this plugin with vault-secrets-operator, we are finding it difficult to easily understand the origin of all the tokens that have been generated. We find the naming convention far too generic to even understand how/where the tokens are in use.

This is an example of just one isolated area (single group) in our setup:

We feel that there should be more options and/or a better default for this. Currently, it seems to be using the token_type property for naming which is honestly already known; as I am in that specific area already (project, group, user) looking at the token(s), so it's quite redundant.

We feel an immediate improvement here would be using the role's path-slug/name instead of the role's type. So instead of vault-generated-group-access-token-* A token generated from a role such as gitlab/roles/group-api with a prop of name=group-api-role could either output vault-generated-group-api-access-token-* or vault-generated-group-api-role-access-token-*

Further, the ability to inject either a partially or wholly custom name at the time of creation would be great. In our specific use case, we can pass in params to the request (see: https://developer.hashicorp.com/vault/docs/platform/k8s/vso/api-reference#vaultdynamicsecretspec:~:text=be%20set%20to.-,params,-object%20(keys%3Astring) so it's not beyond us just giving a custom name from our IaC setup (this may be a niche use-case though).

[ilijamt]

The name property was supposed to be used for that purpose. The original plan was to base it on text/template, just never got around to it.

[ilijamt]

I’ll have some time to look at this next week.