Vault: GitHub Personal Access Tokens Secret Backend

[ekristen]

@jefferai would you be in favor of a secret backend that supports creating and revoking personal access tokens for an account?

[jefferai]

Can you go into some use-cases? This feels a little bit like a solution looking for a problem :-) I also think the configuration/management could be rather tricky UX-wise; you'd have to put in a GitHub API token that itself is tied to your Vault token and it would need permissions to create more tokens, and so on...

[ekristen]

This feels a little bit like a solution looking for a problem

eh, maybe ... hopefully my use-cases can shed some light

I also think the configuration/management could be rather tricky UX-wise; you'd have to put in a GitHub API token that itself is tied to your Vault token and it would need permissions to create more tokens, and so on...

Not sure I agree with this, AWS, Postgres, MySQL backends all require some sort of credential to exist first and then be placed inside vault to be able to generate more credentials, so I think this would follow the same logic.

As a use-case, lets use docker as an example. Docker has GordonTheTurtle who is responsible for any number of tasks on multiple repos, this means personal access tokens are being used. Gordon is responsible for basic issue checking, to doing some checks on code commits etc. Use the same philosophy that vault already exemplifies, how awesome would it be if all those scripts and tools just use vault for the access token management?

At my company, we have a similar account that does a number of tasks related to GitHub repos and their commits. We also have various scripts that use access tokens to perform functions on behalf of this user instead of lets say my account (this makes it so I get only 1000 notifications vs 2000 a day on issues ;) )

The ability to have these scripts and tools and delegate the ability to create tokens to others in the organization on behalf of this user would be beneficial for me, even better if those tokens disappeared if they aren't being used.

Would love to discuss further, maybe I'll change my mind. Thanks @jefferai

[ekristen]

I'm also thinking one mount per account to keep the UX simple. The config would allow for talking to an enterprise instance or the cloud instance and a token for the auth.

[jefferai]

Hi @ekristen

The distinction I was making with the database backends is that GitHub access tokens are "personal", so any such backend is generating more personal tokens for one account. But I get your use-case; even though they're personal, companies and orgs are making the best of the situation and just controlling that personal account carefully.

I'd shy away from limiting to one mount per account. The UX of managing a thousand mounts doesn't end up being any better than managing a thousand individual configurations in one mount (we've seen this problem already with the database backends).

If you're serious about working on this, the best thing you could do would be to draw up a design doc/RFC with proposed behavior, endpoints, etc. Agreeing ahead of time on what should be done will give the max chance that the end result will be merged without requesting a lot of rearchitecture :-)

[ekristen]

That's a fair point and I completely agree organizations are trying to make the best of a best situation.

I'd shy away from limiting to one mount per account. The UX of managing a thousand mounts doesn't end up being any better than managing a thousand individual configurations in one mount (we've seen this problem already with the database backends).

Oh interesting, I mentioned it purely because this was the behavior that I already saw within vault. Are you looking at making it so that database mounts can handle multiple databases in the future?

If you're serious about working on this, the best thing you could do would be to draw up a design doc/RFC with proposed behavior, endpoints, etc. Agreeing ahead of time on what should be done will give the max chance that the end result will be merged without requesting a lot of rearchitecture :-)

You've given me a lot of think about in this. I will say that yes I was serious when we started talking, but you've raised some good points. Let me mull this over a bit more and ensure that this is something I'd like to sink time into.

Either way having an RFC up front makes sense.

[jefferai]

Oh interesting, I mentioned it purely because this was the behavior that I already saw within vault. Are you looking at making it so that database mounts can handle multiple databases in the future?

Yep :-)

[andrewrothstein]

I often launch containers that have my development environment therein, e.g. hub, emacs, sbt, jdk, etc. I want to authorize the root user within the container to access my github account as me for a limited period of time. I'm currently doing gymnastics with ssh key pairs and docker secrets. I certainly could use a github personal access token backend to manage these self destructing secrets.

[thejmazz]

I was thinking it would be nice to have a secrets backend I could send a SSH public key, and it would handle (temporarily) adding it to public keys of the repo on GitHub, GitLab, etc. The role would specify if read only or write key can be added, and which repos/orgs/etc. The credential to power the secrets backend would be an API key that can modify repo’s public keys. The UX of this would be much improved over, for example, created a K8s secret + adding it to repo + volume mounts.

Anyone aware if anything like this is floating around online?

Any examples of past design docs/RFCs to reference?

[llchan]

With gh hitting 1.0.0 I've finally switched over to a terminal-based github workflow. However, the access token is stored in plaintext on disk, which makes me uneasy. I would ideally be able to write a wrapper that fetches a temporary access token from vault and exports it to gh via an env var.

I can fiddle with a plugin but this will be a spare time project so TBD on timeline.