8 ms·
Show HN: Publish from GitHub Actions using multi-factor authentication
The backstory about this GitHub Action:
I discussed with an open-source maintainer why they publish npm packages from their local machine and do not use CI/CD pipelines.
They said publishing should require human intervention and want to continue using multi-factor authentication to publish to the npm registry.
This led to building the wait-for-secrets GitHub Action. It prints a URL in the build log and waits for secrets to be entered using a browser. Once entered, the workflow continues, and secrets can be used in future steps.
The latest release of "eslint-plugin-react" to the npm registry used a one-time password (OTP) from a GitHub Actions workflow!
https://github.com/jsx-eslint/eslint-plugin-react/actions/runs/3498968497/jobs/5860126389#step:9:1 https://github.com/jsx-eslint/eslint-plugin-react/actions/ru...
- ajvpot 4y agoHave you considered adding some kind of encryption of the secrets with a preshared key generated inside the action to make the SaaS zero-knowledge? Currently it appears the service can read all the secrets in plaintext.
- varunsharma07 4y agoAdded an issue to track this: https://github.com/step-security/wait-for-secrets/issues/56 https://github.com/step-security/wait-for-secrets/issues/56 The backend API is open-source, and the secrets are cleared immediately after use from the data store, but I agree this is a good idea.
- thewataccount 4y agoThis is tangential to your comment and not a complaint - That isn't zero-knowledge that is end-to-end encryption. I've been noticing a lot of marketing materials describe themselves as "zero-knowledge" when it's just E2EE. I definitely agree it would be nice to have.
- deleted 4y ago[deleted]
- 0xbadcafebee 4y agoAnyone have recommendations for a server-push authentication thingy similar to Microsoft Authenticator? On sign-in to an Office365 site, MSA will prompt you on your phone's app to authorize the login. I want the same thing but self-hosted & open source. Any suggestions?
- mhio 4y agoMaybe https://ntfy.sh https://ntfy.sh ? It's a generic pub/sub tool that can provide a clickable link on a mobile app back to a service. It's covers the "self-hosted & open source" but it's not specifically an authentication thingy, so you would have to generate the auth factor to push and the service that verifies it, like a web hook.
- gauravphoenix 4y agoCongrats Varun :) Great to see my ex-roommate's post on HN front page. Fun fact- Varun is a super smart engineer, he even won a car in a competition: https://www.oneindia.com/2006/06/29/microsoft-security-shootout-contest-winners.html https://www.oneindia.com/2006/06/29/microsoft-security-shoot... I would highly encourage HNers to try out his github action.
- varunsharma07 4y agoThanks, Gaurav :)!
- toomuchtodo 4y agoTIL GitHub Actions doesn’t have an MFA gating function. Great work with this! Hopefully some Hubbers see this and let a PO know :)
- kevmo314 4y agoIt would be cool to see an oauth extension of this: run a github action permissioned as a user.
- varunsharma07 4y agoTo release the wait-for-secrets Action, I run the workflow using a PAT sent in via the browser. In that sense, it is similar to what you mentioned. I create the PAT during the release process and delete it after the release is done. I have added an issue to track your idea: https://github.com/step-security/wait-for-secrets/issues/57 https://github.com/step-security/wait-for-secrets/issues/57. It would be interesting to run as the current user using OAuth, but it will need more thinking.
- lloeki 4y agoI wish there were more work done in that area. I seem to recall someone using ephemeral Tailscale nodes in CI to respond to a hardware token challenge locally but I can't find where that was.
- anomaliy 4y agoThis is super sweet! I dig that you can do this from the workflow itself
- varunsharma07 4y agoYes. The workflow blocks and prints a URL every 10 seconds. The developer can click on the link and enter secrets in the browser. The workflow then continues, and secrets can be used in future steps.
- woodruffw 4y agoCorrect me if I'm wrong, but: doesn't this involve sharing your credentials with a third-party service? I have no reason to doubt Step Security's motives here, but one of the examples involves plumbing a TOTP code through their webservice, which isn't ideal. (Manual intervention seems like a very reasonable thing to want! But perhaps it makes sense to leave the package index's secrets out of the round-trip, and limit the secret to something known by only the publisher and the "gatekeeping" service.)
- crazysim 4y agoMaybe there's a way to have a secret in GitHub actions that can decrypt the browser-side-encrypted code.
- woodruffw 4y agoThey could probably do something like that, but you'd still be putting your credential into an input form on a third-party service and counting on that service to encrypt it. The more concerning part to me is that, even with the best of intentions, this flow is completely indistinguishable from the TOTP phishing flow that we try to train users to avoid.
- varunsharma07 4y agow.r.t phishing: a maintainer intends to publish a release, will go to their GitHub Actions build log, and will click the link in the build log. So it is not a typical phishing scenario where one gets an email without context and clicks the link. Please let me know if I am missing something. There are also ideas about using a phone app and/or a CLI related to end-to-end encryption https://github.com/step-security/wait-for-secrets/issues/56 https://github.com/step-security/wait-for-secrets/issues/56.
- hk1337 4y agoSeems like there could be better options than requiring MFA for publishing. Like, maybe publish it to a pending state so CI can automate it then require a human to login and approve it?
- hk1337 4y agoIsn’t this what OAuth and OIDC supposed to handle? Thank you for not wrapping this up in docker image. Unless there’s a specific purpose for it, those kind of actions are annoying to use. EDIT also, kudos to putting a version on it. An action dealing with authentication and telling you to use it with “@master” is suspect, IMO.
- woodruffw 4y agoYes, pretty much. The advantage to something like OIDC is that it requires virtually no trust except the trust already established: you trust GitHub to host your code and NPM (or whoever) to publish it; OIDC allows GitHub to share a machine identity that NPM can verify and grant publishing rights to (e.g. via a temporary API token). The downside to that approach is that it requires the consuming side (NPM in this case) to understand and verify OIDC tokens (which are really just JWTs). But we're currently working on exactly that on PyPI, and hopefully other package ecosystems will follow our progress there.
- ljharb 4y agonpm doesn’t offer these things, so it’s not a useful comparison.
- GauntletWizard 4y agoVersions don't matter in GitHub actions; it takes "Tags" as the highest priority, which maintainers can update at will. Yes, they have to delete the tag first, but there's a UI button for that. Yes, anyone who's cloned the repo will receive a warning, but have you ever cloned an external GitHub actions repo? Advice to use external GitHub actions, especially security actions, should pin to a sha instead.
- hk1337 4y agoThat's good advice. My biggest issue were when examples show using the action as `my-action@master`.
- varunsharma07 4y agoOIDC that is a good alternative. This GitHub Action uses OIDC to authenticate the workflow to confirm secrets are only given to the authorized job. The differences between OIDC and MFA for publishing credentials are: 1) More control: each release gets gated by human intervention, requiring MFA to publish. 2) Separation of duties: Just because one has "write" access to the code/ workflow does not automatically permit them to publish. 3) Less management overhead: With MFA, there is no need to set up OIDC trust policies (which need to be configured accurately). This removes the need to manage a separate set of deployment credentials/ policies.
- deleted 4y ago[deleted]
- ngcc_hk 4y agoWow.