Open TJM opened 6 months ago
likely because the rotate is hard-coded to create an admin token
@TJM I can certainly add rotation to user_token
. It's logical next step.
We could, but it also breaks the dynamic usernames. Honestly using a "user" token is a workaround IMO :)
However, its the best I could come up with given the current constraints.
Is your feature request related to a problem? Please describe.
We have a multi-tenant artifactory, each tenant has their own Vault cluster. We setup the vault-artifactory-secrets-engine, but we have to give it an "admin" token. This would allow anyone to create a role with group=admin and obtain an admin token to artifactory. (their pipelines have administrative access to Vault so that they can setup GKE authentication and policies)
Describe the solution you'd like
I would like to be able to use a token for something less than platform admin. Maybe a project admin token? This may require support form JFAC as well.
Describe alternatives you've considered
We tried using a "user" level token in
MOUNT/config/admin
(using a non-admin token)Using a separate (shared) vault, but then we need to grant them the ability to link their GKE clusters in... but maybe we could be more restrictive about what they have access to do since it is not "their" vault cluster
Google Artifact Registry :p
Additional context
What we need is a folder or "namespace" in artifactory. We thought that is what "Projects" provided. WIth the GCP Secrets Engine, we can grant "owner" level access to a specific sub-folder of the organization, they can do whatever they want within that sub-folder (within org policy of course). We would like to figure out a way to provide similar functionality.
We also created a JFrog Support ticket for this - 288012