-
Notifications
You must be signed in to change notification settings - Fork 20
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
non-admin token #156
Labels
enhancement
New feature or request
Comments
@TJM I can certainly add rotation to |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: