Skip to content

Build API key: scope key to build instead of project #12080

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

Open
stsewd opened this issue Apr 3, 2025 · 1 comment
Open

Build API key: scope key to build instead of project #12080

stsewd opened this issue Apr 3, 2025 · 1 comment

Comments

@stsewd
Copy link
Member

stsewd commented Apr 3, 2025

What's the problem this feature will solve?

We introduced build API keys in order to improve security inside builders, so instead of having one single key with access to all projects via the API, we generate one temporary key valid just for one project for each build.

That's definitely better than one global key, but this key still grants access to any version of that project, since builds are attached to one version, we should scope it just to that version. For example, if a build from a PR manages to leak the build API key, it will be able to interact with all the versions.

Describe the solution you'd like

Instead of attaching build API keys to a project, they should be attached to a build (after all they are named build api keys, not project api key :D).

class BuildAPIKey(AbstractAPIKey):
"""
API key for securely interacting with the API from the builders.
The key is attached to a single project,
it can be used to have write access to the API V2.
"""
project = models.ForeignKey(
Project,
on_delete=models.CASCADE,
related_name="build_api_keys",
help_text=_("Project that this API key grants access to"),
)

We may be tempted to just add a "version" field, but that has the downside of being able to interact with all the builds linked to that version, again, we want that key to be the more scoped possible.

Additional context

I think I decided to link the keys to a project since we make use of some APIs that update or retrieve some information about the project, while that's a valid use case, they should be special cases that only grant limited access to resources of the project.

@humitos
Copy link
Member

humitos commented Apr 7, 2025

This looks like a good idea 👍🏼 . I would say it's low priority for now, tho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants