[kwlug-disc] npm leak via April's github entry

[Mikalai Birukou]

> ....
>
> Quote from the blog post section "What happened":
>
> """
>
> Using their initial foothold of OAuth user tokens for GitHub.com, the 
> actor was able to exfiltrate a set of private npm repositories, some 
> of which included secrets such as AWS access keys.
>
> Using one of these AWS access keys, the actor was able to gain access 
> to npm’s AWS infrastructure.
>
> """
>
> I wonder whether even guys at npm have put token directly into 
> committed code, or if it was copied from "proper storage of secrets" 
> in github. (Note: gitlab has CI secrets-sorta thing, kept in repo 
> setting, injected via environment variables when ci is run.)
>
> I appreciate single click deployments. Can't imagine life without 
> them, and with only one click the rest of the team is doing the "last 
> but important" step, which is awesome.
>
> But I have the following second thought: some friction might be needed 
> in a form of click and paste token for the deployment op. It adds a 
> burden to have a token just for a particular op, key from a garden's 
> corner instead of the whole kingdom. And it adds "and paste" part on 
> the last step. Am I overly paranoid?
>
> Is there another better approach to keep less access capabilities on 
> ci infrastructure?


Assuming that somehow steps can be simple, is it a good idea to have the 
following set of steps:

1) you get a onetime op-authorizing token via some trust-inspiring 
third/side channel;

2) perform click and paste token deploy step.


Would you like this flow in your CI?

With onetime tokens you may log user+token+job(s) for accountability, 
and retracing those times when you are hacked.