github/branch-deploy

Configuring `admins` and `admins_pat`

daczarne opened this issue · 4 comments

Details

This is just a question regarding how to configure the admins and admins_pat fields. In a repo I work with we would like to have this but we are unsure on how to configure it. While the admin key is clear enough (just add the org/team), it is not clear how to add the admins_pat. Our understanding is that PATs are personal (i.e. each user can create PATs). Does this mean that each user would need to create one for their account and add it to the repo secrets? If so, let's assume we create a secret with PAT1;PAT2;PAT3;etc will the runner/action be able to tell which PAT belongs to which person??

Thanks

👋 Hey there @daczarne! It looks like you have a good understanding of the admins field. However, in order to use a team you are correct that you have to use a GitHub PAT that has the read:org scope.

What I have done in a few open source projects that I work on this the following:

  1. Create a new "bot account" (sometimes people call these service accounts). Here is an example of one. A bot account is essentially just a GitHub account that represent a "bot" instead of a "human". You would use this because at work, employees may come and go so you don't want a PAT for deployments tied to a single human because if they leave the company, their PAT will cease to work.
  2. Mint a new PAT via this new bot account with the read:org scope. It might not be ideal, but you would use a "classic PAT" as the tokens that you can mint for classic PATs can have infinite expirations. This means that you don't have to worry about rotating the token every X days.
  3. Add the PAT you minted in step 2 to the admins_pat field of this Action.

If you want to greatly enhance your security, and not have long lived tokens, I would suggest looking into GitHub Apps + this workflow GitHub Action to create short-lived tokens to pass into the admins_pat field instead -> create-github-app-token

@GrantBirki thank you very much for your quick response. One small follow up.

However, in order to use a team you are correct that you have to use a GitHub PAT that has the read:org scope.

My personal PAT that I create in my developer settings you mean?? Would that work for the other people in my team?? Even if we (my team and I) use a PAT from a bot that the company has, under the hood this bot would still be just a normal user account as far as GitHub is concerned.

What I have done in a few open source projects that I work on this the following:

  1. Create a new "bot account" (sometimes people call these service accounts). Here is an example of one. A bot account is essentially just a GitHub account that represent a "bot" instead of a "human". You would use this because at work, employees may come and go so you don't want a PAT for deployments tied to a single human because if they leave the company, their PAT will cease to work.
  2. Mint a new PAT via this new bot account with the read:org scope. It might not be ideal, but you would use a "classic PAT" as the tokens that you can mint for classic PATs can have infinite expirations. This means that you don't have to worry about rotating the token every X days.
  3. Add the PAT you minted in step 2 to the admins_pat field of this Action.

If you want to greatly enhance your security, and not have long lived tokens, I would suggest looking into GitHub Apps + this workflow GitHub Action to create short-lived tokens to pass into the admins_pat field instead -> create-github-app-token

These are very good tips on how to set it up. Really appreciated. I will look into using them.

My personal PAT that I create in my developer settings you mean?? Would that work for the other people in my team?? Even if we (my team and I) use a PAT from a bot that the company has, under the hood this bot would still be just a normal user account as far as GitHub is concerned.

Yep that is correct! Here is an example:

Image

Please note that if your organization requires SSO, you will need to "SSO authorize" your PAT after you create it to access resources in your org.

Ok. That clarifies it. Thanks. Appreciate the help 😄

Closing the ticket now as I believe this clarifies/answers all questions.