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-*
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 asgitlab/roles/group-api
with a prop ofname=group-api-role
could either outputvault-generated-group-api-access-token-*
orvault-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).