Concerns about Access to Secrets in Workflows

[landongrindheim]

🖼️ Context

Recently, an issue was opened in dependabot-core about Dependabot losing access to secrets. It seems that the conversation stemmed from a recent change that surprised users. The conversation in the issue covers several topics, including:

• The difference between Dependabot secrets and GitHub Actions secrets
• Whom should be given access to secrets
• Whom the actor should be when workflows are re-run

The conversation has been productive in brining out concerns. However, since dependabot-core is an open-source project that tries to stay agnostic of customer secrets, I think it's better suited to this product-specific forum.

Originating issue: dependabot/dependabot-core#5464

🤞 Intended Outcome

It's my hope that we'll be able to share an understanding of what to expect from workflow runs, and that concerns that users may have re: code security can be fully understood by both the Dependabot and Actions teams 😄

---

Note: Apologies to anyone whose perspective/statements I may not be representing correctly. Please feel free to state them in a more accurate way if I've done this 🙂

[ShockwaveNN]

I would like a propose an idea - as I said in the original issue - it's ok for me to give access to Dependabot to my secrets

What is not ok for - that I need to configure the same secret twice - one for usual PRs of real users with Github Actions and the second time - for Dependabot

Maybe there should some way to share same secrets between Github Actions/Dependabot

[nomdal]

I think it would make sense to set the UI up as a single passwords page that then allows you to toggle on access for Dependabot / Actions / Codespaces, as opposed to breaking those out separately. Because having to duplicate passwords between different pages is not ideal.

[rhofschn]

I'd also propose that there is some visual indication what user an Action is being run under.

Now that Actions triggered by a Dependabot PR are always run in the Dependabot context, and not by the user re-running the job, the user listed in the job summary drop-down is not as definitive.

[sullimander]

One thing I really liked about the old way that dependabot + GitHub Actions worked is that the initial PR would fail because it didn't have access to the secrets. That gave us the opportunity to review the changes dependabot was trying to make before any code ran. Then when we were comfortable that the change was safe, we could manually re-run and it would pass.

We could put a manual approval step in all our workflows if the actor is dependabot, but the old way basically had that on by default.

[gustaff-weldon]

I will chime in and repeat what I said in the original issue.

Security is important for us, therefore we applauded the change made in dependabot/dependabot-core#3253 (comment) where bots lost access to secrets by default to prevent eg. npm based attacks.

We have a lot (and I mean a lot) of secrets that we do not give access to bots (dependabot, renovate) and our workflow for all PRs opened by those, was (up until recently) to review PR and re-run their build by someone from the team.

This behaviour is now broken and no-longer works. A solution suggested in dependabot/dependabot-core#5464 (comment) would suffice.

TLDR;

We do not want dependabot to have access to any secrets.
We want to review the dependabot PR before rerunning the workflow with a more elevated permissions of a team member.
Give ability to re-run workflow as triggering actor

[adambirds]

@gustaff-weldon do you know has this been implemented yet or?

[gustaff-weldon]

@adambirds I do not believe it was, we are still rebasing dependabot PRs manually to have full control over them as before, this sucks a lot as "Rerun as" would be so much easier

[minecrawler]

Just ran into the same problem. We're using secrets to connect to our custom actions runner, but don't want to copy the secrets for every bot. It would be great to toggle secrets visibility inside the secrets page for different bots, or at least set the secrets context when (re-)running a job.

What's the status?

[radiomix]

Same problem: no answer ❓ Seems GHA-team got a looooot of time ⌛.

By the way: How do I find out some one is GHA-team member: by clicking on GH-user-name ? The outcome of this depends on the time I do that clicking: Maybe still/not-yet/not-any-more stuff member.

And what is Solutions Engineer at GitHub UI/BE/GHA . . . or just some kind of closed source engineering?

Lot of guessing . . . as in the old MS-:window: days . . . :disappointed_relieved:

[radiomix]

Re-running manually two times solved the problem: GHA could see/access the secrets! ❔
Is this a good or rather a bad sign ❓

Not knowing why things work is worse than knowing why things don't work!

[carogalvin]

Hello, PM for Dependabot here! Thanks for your continued feedback on this issue! I understand that this problem makes it difficult to use Dependabot with your workflows. We don't have this work prioritized on our roadmap at this time, but we will update this discussion thread whenever that changes. If you have any other feedback for Dependabot, you can feel free to open new issues in dependabot-core or email me at carogalvin github.com.

[truh]

There already was an issue for this in the dependabot repo which was closed in favor for this discussion. It's linked in the original post.

[persocon]

this problem still happening, wtf is going on guys?! the thing has been a problem for years and not solutions?

[persocon]

this seems to be the solution: dependabot/dependabot-core#5464 (comment) to add a clone of the same key 🙄 to dependabot itself, so dumb

[ckpearson]

We have a repo that utilises subrepos, for which checkout has to be fed a PAT because the GITHUB_TOKEN only has pull rights on the repo itself. This is a system that requires PCI compliance, so Github Advanced Security & Dependabot are huge parts of that.

As it stands the autogen security updates are entirely useless for us, as they cannot be built using our actions and then verified using the vulnerability scanning present in the pipeline.

The only workaround so far is to manually trigger that action on the branch that Dependabot created, which sure, isn't the most difficult thing in the world to do, but it is pretty frustrating.

The intuition that something opened a PR and therefore it ought to behave just like all the other PRs (which work) is pretty obvious, and it's jarring that this is not the case for Dependabot-created PRs.

[truh]

Is there a way to have a Dependabot push commits and open PRs as a regular user by giving it a Personal Authentication Token?

This is how the update-flake-lock action addresses a similar problem with Github Actions https://github.com/DeterminateSystems/update-flake-lock?tab=readme-ov-file#with-a-personal-authentication-token.

[samwreason]

One workaround that might help some people: converting the dependabot PR to draft and then marking it ready for review again re-runs the checks as your user. With the gh cli you can do this with gh pr ready <num> --undo && gh pr ready <num>

[j3p0uk]

@samwreason trying this today and none of our actions reran.