GITHUB_ACCESS_TOKEN should not be an environmental variable?

[cboettig]

A pull request could add the command echo $GITHUB_ACCESS_TOKEN and expose the token. Even if you are only using in private repositories, I don't think it is desirable to so directly expose a private token to collaborators.

Perhaps there's a way to still make the token available to entrypoint.sh without making it visible as an env var on the runner?

[vbersier]

I second this. I had to rotate my token today because of Codecov.io's recent security incident which potentially exposed this token. Would it be sensible to bind a .env file containing the token into the container to get the token from there?

[cboettig]

My current approach has been to comment out the execution of entrypoint.sh in the Dockerfile,

https://github.com/tcardonne/docker-github-runner/blob/21400f71b894946de9b75127ba0353807cde1135/docker/Dockerfile#L88

and avoid providing the secure credentials in an environmental variable at run time. Once the container is up, I docker exec into it, run entrypoint.sh manually with the credentials. This way, these credentials are not stored as env var that could be accidentally exposed.

I'm not a security expert, and there may be other routes which are more streamlined and/or more secure than this, but at least I think it's better than embedding the private token so directly.