Using Github Enterprise, I have a service/bot account where I'd like to generate a number of Personal Access tokens and provide to a number of teams.
Is there any limit in how many Personal Access Tokens can be generated per user?
As far as I'm aware, there is no limit, but if you want to be sure, you should ask either the GitHub support team or on the GitHub community forums.
GitHub itself has such a bot account and PATs are frequently used there, but do be aware that the UI may be a little (or, depending on how many tokens you issue, very) slow, since it isn't designed for people to have huge numbers of PATs.
You may find it more desirable to use deploy keys if you're accessing a repo, since these have a smaller scope (one repository) and won't have the UI problems mentioned above, but of course that won't work for the API.
Related
I recently started a position at a new team. Their version control and programming best practices are non-existent. I'm trying to set up some infrastructure not only for myself and the one other computational researcher on my team, but also for future potential computational scientists who may join the team in the future.
To that end, I would like to create a GitHub organization to centralize all of our version-controlled code. However, one thing that is giving me pause is the wording of the organization creation page on GitHub:
The "This Organization belongs to:" menu is a bit unclear to me.
If I specify my employer, what does that mean functionally about the use and control of the organization settings? There is no one else in my team who is interested in or even wants to be the "head" of this organization on GitHub, it's just me, but I do not want to "own" this organization; I want it to exist for others after I potentially leave. It's not mine; it's my employer's. I am creating this GitHub organization on my institute's behalf.
If I type my employer's name, is that just a legal designation or will I be abdicating power over this GitHub to an account that doesn't even exist?
There was a Github discussion about this topic.
If in the future you (Owner) leave repositories and no one takes them, the company or institution can legally initiate a formal request to Github to retrieve the repositories.
In addition, the account is under the Github Corporate Terms of Service, instead of the Standard Service terms, see:
github-terms-of-service
github-corporate-terms-of-service
I have signed up my organization to a GitHub Teams free plan, and we are considering pushing our code to private repositories on GitHub. Our projects consist of decades old legacy code and there are lots of hard-coded credentials (not only in the code, but also in comments) for various servers and databases.
I do not want to make my team change all this code to store credentials in config files, I am not 100% sure our various tech stacks support this. It would also be very time consuming, and there is no guarantee we can find every single reference of credentials. I’m just wondering if it is safe to push the code with all these credentials even if the repositories we create are not public?
Storing your code on GitHub is no less secure than storing it anywhere else. For example, GitHub generally takes significant effort to secure repositories, and staff are not permitted to look at the contents of private repositories without the consent of the repository owner. Pushing this code to GitHub will not intrinsically expose it any more than storing it on any other server.
However, having said that, storing credentials in your repository is a security problem regardless of where you host that code. It is easy for a repository to accidentally leak for many reasons, due to server misconfiguration, laptop theft, or various other situations. You would be well served to put at least a modicum of effort into using a more secure practice for storing credentials, if for no other reason than that you will have them stored in a single, secure place where you can find them all. For example, rotating credentials is much easier when they all live in a tool like Vault and you can easily rotate a compromised credential across all systems.
So, in general, what you are doing is not very secure, but using or not using GitHub will not change that.
There is nothing in the GitHub guidelines, as far as I can see, that prevents people from making multiple personal accounts. I would like to create a "more serious" account and move my serious projects there, and keep the trash on a side-account.
The problem is that I used to have two accounts a few years ago, and GitHub actually banned both accounts due to that. They told me that "you are only allowed to have 1 account". I had to petition their support to reopen my main account. But it seems like they've changed their stance now, because I can't find any wording that prevents multiple accounts anymore.
I am Googling for the term multiple accounts site:help.github.com and the pages that come up seem to indicate that it's allowed these days.
For example, https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/merging-multiple-user-accounts says "We recommend using only one user account to manage both personal and professional repositories", which sounds like they accept multiple accounts too.
Does anyone know? Perhaps some of you have multiple accounts successfully!
It would be better to create an Organization instead and keep your important projects there. It's always much easier to have a single account in terms on maintainability.
For instance: in BitBucket you cannot have your single public key attached to two different accounts.
I found the actual answer in the Terms of Service:
https://help.github.com/en/github/site-policy/github-terms-of-service
"One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine)."
So that's why they banned me all those years ago. You're only allowed to have 1 account if you aren't a paying user.
But I will accept #emix answer, since he was the first to suggest the smart solution of making an Organization for my serious projects!
You can create New organisations linked to your main personal account.
We're having a lot of developers just sign up for Azure DevOps, create their own Org, and use the five free licenses. This creates big problems if they were to leave. Is there a way to stop this or at least be notified when this happens?
There's no way to prevent it that I'm aware of. You should definitely ensure that everyone is using organization accounts ("work or school" as opposed to "personal" accounts) and that your Azure DevOps organization is backed by Azure Active Directory, so that at the very least you can retain access to any accounts created by others.
However, there's nothing wrong with creating an account to use as a sandbox. In fact, it's very common, as it can be useful to have an unrestricted place to try out features.
If people are creating additional accounts and then using them for real work on an ongoing basis, it sounds like you have a "people problem" in your organization that needs to be addressed, not a tooling problem.
Are people not being given appropriate access to the place they should be working in a timely fashion? This points to a problem with on-boarding.
Are people unaware of where they should be working? This is a training/documentation problem.
How are they working in a personal account without other collaborators (such as managers, teammates, or business users who are managing the backlog) being aware of it? If their manager/technical lead is aware of it, why is their manager/technical lead not redirecting them to an appropriate location? This represents a communication problem (specifically, lack of communication).
Is there any GitHub SSH Deploy key limit. Let's say I would need 2000 or even 4000 deploy keys added to the git repository. Is that possible or will I hit the limit at some point?
The reason for this is that we would have 4000 devices that would need to be provisioned. And we want to have control which device can access repository and if necessary disable it. Another option is indeed access tokens, but as far I understand they are linked to the account, not repository.
https://help.github.com/articles/git-automation-with-oauth-tokens/
And that would also mean that we would need to manage the permissions separately to which repository they have access to.
First of all, why would you need up to 4000 deploy keys? This is a pretty large number and I think you should explain why you need such a large amount of deploy keys for one single repository.
However: I contacted the GitHub support, after I couldn't find anything about this in the GitHub documentation and got the following response:
I don't believe we have a fixed limit on SSH keys or deploy keys
although as the settings pages weren't designed with this sort of
usage in mind, I think it would be rather difficult to manage.
When someone needs to control access to such a large number of
machines, we'd usually recommend creating personal access
tokens instead,
as these can be automated and will provide similar access. If
the huge number of keys was necessary and causing problems, we'd do
our best to help.