ansible / galaxy

Legacy Galaxy still available as read-only on https://old-galaxy.ansible.com - looking for the new galaxy -> https://github.com/ansible/galaxy_ng
Apache License 2.0
854 stars 328 forks source link

Allow for 'service accounts' or per-project galaxy tokens #2276

Open geerlingguy opened 4 years ago

geerlingguy commented 4 years ago

Feature Request

Use Case

I am trying to automate the publishing of collections to Ansible Galaxy.

Currently I publish some collections to my own namespace (geerlingguy), and others to a shared namespace (community).

If I want to automate the publishing process, I have to insert my own personal Galaxy token into the CI system as a secret, and then make that secret available to the build system.

This presents a risk, as in shared repositories, if someone else were to find a way to extract that secret (there are many ways this can be done, varying by CI system), or to get a build to publish an artifact to my namespace instead of the shared namespace... then someone could impersonate me and publish code to projects they're not supposed to be able to access.

Proposed Solution

Ideally, I could generate a per-project galaxy token. For example, visit 'My Content', navigate to a collection, then click a button to get a token (or have it behind the '...' dropdown menu):

Screen Shot 2020-02-28 at 11 23 40 AM

Alternatively, I can have one galaxy token per organization I'm in.

Alternatives

Not sure of any sane alternatives that wouldn't require more galaxy tokens to be generated.

Implementation

N/A

amarao commented 4 years ago

I got the same issue but between my private repo (with community-style collections) and my current employee where I need to add my token to organization repo CI to publish corporate modules into galaxy.

I think 'token per namespace' is enough.

treezio commented 2 years ago

I was looking for a 'token per namespace' solution as well. Once you leave an organization it makes no sense to use your private token for an organization namespace role in a CI.

lgarber-akamai commented 1 year ago

Bumping this. As an organization we would like to be able to create more granular namespace/project-level tokens as well as create tokens that aren't tied to any particular org member for use in our CI pipeline.