Have 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.
Yes, 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.
OIDC 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.
Versions 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.
Correct 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.)
Seems 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?
Yeah, I think a pending state is probably more ideal here. But I could see that being a little bit of a lift.
(I'm still not 100% clear on the security advantages of requiring MFA for API tokens that are limited in scope -- assuming that NPM's tokens don't serve as full user credentials, I don't think they should enforce MFA on them.)
Anyone 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?
Maybe 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.
To 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.
Yes. 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.
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.
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.
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-shoot...
I would highly encourage HNers to try out his github action.
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.
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.
Advice to use external GitHub actions, especially security actions, should pin to a sha instead.
(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.)
(I'm still not 100% clear on the security advantages of requiring MFA for API tokens that are limited in scope -- assuming that NPM's tokens don't serve as full user credentials, I don't think they should enforce MFA on them.)
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.
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.
I have added an issue to track your idea: 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.