search

lemurheavy / coveralls-public

The public issue tracker for coveralls.io
http://coveralls.io
124 stars 7 forks source link

Authentication with OIDC token? #1698

Open jonasfj opened 1 year ago

jonasfj commented 1 year ago

Documentation on coveralls-github-action suggests that it authenticates with GITHUB_TOKEN.

image

Is this safe? If coveralls accidentally leaks this token it could be used for unpleasant things.

It's even unclear to me that GITHUB_TOKEN is suitable for authentication against external services.

Would it not be safer and more reasonable to use the OIDC token support github recently added:

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect

If you create an OIDC token with audience=https//coveralls.io then any accidental leaks of the token would be fairly harmless.

afinetooth commented 1 year ago

@jonasfj Thanks for your input. I have passed this on to our engineering team for review / consideration.

mrexox commented 1 year ago

Hey @jonasfj! Github docs say that these tokens live only until the job finishes:

The GITHUB_TOKEN expires when a job finishes or after a maximum of 24 hours.

They are unique across all workflow runs, so their leakage is time-limited. They can't be used after the job is finished. Also these tokens can be limited with permissions. Coveralls only needs a permission to read repositories.

Of course this is not 100% safe but you can control the safety via default read permissions or you can specify permissions in a workflow file. I will consider using OIDC for this purpose but I think Github token fits pretty good here. Also there is a Coveralls-specific token which can be used instead of a Github token.

I understand that there is a possibility that using Github token with write access it is possible to do bad things in Github even if it lives for 1 min. We will discuss this issue with the team. We will at least provide a recommendation for more secure configuration.

jonasfj commented 1 year ago

Yeah, it's probably not a huge issue. The fact that the token is short-lived, makes it a lot better than the hardcoded coveralls-token. But in general it seems unwise to use the GITHUB_TOKEN for authenticating with non-GitHub APIs.

Suppose another service, let's call it serviceB, also used the GITHUB_TOKEN for authentication, then coveralls would get a token that can be used for authentication with serviceB. And serviceB would get a token that can be used for authentication with coveralls.

Given that it's just coverage data, it's probably not a huge issue :see_no_evil:

But when talking to coveralls it's probably preferable to use a short-lived token that is intended for use with coveralls. That'd be the OIDC token with audience=https://coveralls.io.

It's just about security hardening, each token should ideally only be used for one purpose.

I do see that you probably wouldn't want to migrate existing projects. So it'd probably have to be merely an option for new projects, and then perhaps someday a config option to enable GITHUB_TOKEN authentication -- which would be disabled, if an OIDC token is used. Or some migration path like that.

Best wishes,

As a side benefit the OIDC token embeds information like revision/branch, etc. so you could prevent a development branch from sending coverage data for the main branch. This is probably not a huge security concern, but a good way to prevent accidental mistakes that would cause garbled coverage reports :D