Should OAuth tokens be available to pipeline steps?

Ideas
1

This query relates to the OAuth integration between Drone and Gitea.
When a user logs into Drone they are prompted to authorise access via the standard OAuth exchange.
When drone executes pipelines for activated Gitea repositories it injects the OAuth token into each container (~/.netrc). This is how an alpine/git container is able to interact with the repository.

I’m wondering whether this token should be exposed to the pipeline containers? The token provides access to all the originating user’s repositories on Gitea. This may be useful if one is cloning other repositories during a build pipeline, but it could also be misused to access other private repositories.

For example, Alice has access to repositories A, B, C. Bob only has access to repository A. If the Drone pipeline is activated under Alices account, then Bob could manipulate the build pipeline for A to extract repositories B & C.

Is there any way to limit the scope of the OAuth token to just the repostitory being processed? I suspect that this would require a modification to both Drone and Gitea, but I’m hoping that I’ve missed something.

Alternatively, is it possible to run a pipeline in a mode where the clone happens (presumably with fetches against branches/tags for semantic processing) and then .netrc withheld from subsequent containers?

2

I’m wondering whether this token should be exposed to the pipeline containers? The token provides access to all the originating user’s repositories on Gitea. This may be useful if one is cloning other repositories during a build pipeline, but it could also be misused to access other private repositories.

the netrc file is available to your pipeline so that you can execute npm install or go get or run other commands to fetch private dependencies. Back in 2014, problems downloading private dependencies was our most common issue, and solving this was our most requested feature. This was solved by providing the netrc file, and has been used ever since.

Was this the best design? At the time it seemed like the best option, but over the years I have come up with ideas and alternate designs that I think would have been better. The problem is that changing this behavior would break thousands of existing installations, so we are stuck with the current behavior until we are ready to make a major breaking release. Perhaps that is something we can consider in a year or two when we are planning such a release.

Is there any way to limit the scope of the OAuth token to just the repostitory being processed? I suspect that this would require a modification to both Drone and Gitea, but I’m hoping that I’ve missed something.

Unfortunately there is not. It would be great if source control management systems (Gitea, GitHub, etc) provided an endpoint to generate temporary clone credentials, but such a capability does not currently exist.

Alternatively, is it possible to run a pipeline in a mode where the clone happens (presumably with fetches against branches/tags for semantic processing) and then .netrc withheld from subsequent containers?

Yes, you can restrict the netrc to your clone container by passing the following environment variable to your docker runner:

DRONE_NETRC_CLONE_ONLY=true

Note this only works for the Docker runner. It has not been ported to the Kubernetes runner, however, I would definitely accept a pull request.

3

Thanks for the quick and thorough reply.

I recognise the benefit of being able to interact with other repositories as part of a pipeline. I suspect that the risks associated with a pipeline inheriting access to all a user’s private git repositories is manageable (for example by compartmentalising user accounts to specific security domains).

The problem is not limited to git repository access. It feels like a pipeline should be using a ticket based system for secure interaction with various private resources (git, docker, pypi, etc…).