I have set up a gitlab project and we authenticate via ldap.
I set up our repo and assumed that everyone who authenticated via ldap would be able to access it but that does not seem to be the case. I am having to add each user individually.
The project is now set to public but that has not helped.
Is there a way to bulk add users to a project in gitlab?
I found the issue.
Apparently my licence had not gone through so I was using a basic version which does not support this!
I am developing a utility where I need to validate the user by taking username and validate it with a specific gitlab private repository members. If the user exists in that repository members then only the executable will run. As this utility will be used by many users,I do not want to use my personal access token.
I am new to Gitlab, would be great help if you can show possible options here.
I want any user in our Group that created a new repository to automatically have maintainer rights for that repo.
I can't find any administrative settings on Gitlab.com that would imply the ability to do this automatically.
I have all users in the group set to "Developer" privileges on all repos but I'd like to have the user that created the repo to be set as "Maintainer" upon repo creation.
I haven't tried this, but here is the idea.
Setup a System Hook for project_create event:
https://docs.gitlab.com/ce/api/system_hooks.html
https://docs.gitlab.com/ce/system_hooks/system_hooks.html
In hook body owner_name is hopefully the creator.
So in your script you can then make an API call to promote user:
https://docs.gitlab.com/ee/api/members.html#add-a-member-to-a-group-or-project
I have a project with a Node dependency on a private Git repository. I need to be able to run npm install without being prompted to enter a password or allow an SSH connection, so I'm using an access token that I created on GitHub in my package.json:
"dependencies": {
"sass-theme": "git+https://[token]:x-oauth-basic#github.com/MyOrg/sass-theme.git#v1.0.2",
"node-sass": "^4.5.0"
}
This project is shared with dozens of other people, so obviously I don't want to keep my token in source control. I know I can create a read-only deployment key on GitHub, but I believe that would require other developers to import the SSH key to build the project locally.
Is it possible to create an access token that can be shared but that has read-only access to clone the repository?
The most straightforward way I can think of to create a token that provides read-only access to a private repo is to:
Have a user who has read-only access to the given private repo
(and ideally, not much else)
As that user create a Personal Access Token with the "repo" scope
It would be best if they didn't have access to other orgs/repos, since the "repo" scope grants the user total control over any repos that user has write access to.
I know in an Enterprise solution we would do that with a System ID, but on GitHub you can instead create a Machine User.
Deploy keys are the way to go. By default they don't allow write access and they are scoped to the specific repository (unlike the GitHub personal access token). So you can now generate a private/public key pair, set one as read/pull only deploy key on a single repository in GitHub and use the private key in your CI.
For instance run a bash script:
eval "$(ssh-agent -s)";
ssh-add <your private deploy key>;
Now your CI has rights to access private repo's during the build.
You can add a Deploy key by going to your repository on Github and then clicking Settings > Deploy keys > Add deploy key
If you think it's a bad idea to put your credentials in your source code (as you should!) then you have few options:
Keep it hosted in a private GitHub repo but add those dozens of other people as collaborators to this repo (with read only access).
Keep it hosted in a private GitHub repo but owned as an organization and add those people to the organization.
Publish it as a private npm module.
Publish it in a private npm registry.
Include the dependency in the source code of the program that needs it.
The last one is basically like including the node_modules in the original code that uses that module so of course it's not pretty. Hosting your own npm registry is not trivial but you can automate adding users that way. Publishing private npm module is not free. Maintaining an organization full of people who should be able to access your repo is annoying.
Keep in mind one thing: if you share your credentials with more than one person, expect everyone to eventually have access to it, it's just a matter of time. The credentials could have a limited scope, it can be a read only deploy key or a machine user with restricted access, but if it is distributed it will leak eventually as it always does, especially when you share it with dozens of people. It's much better to keep a list of people who can access the code, and you can automate keeping that list up to date using the GitHub API.
I would never recommend distributing credentials in the source code of the project, no matter how limited access those credentials provide.
It's ugly that there are no scope for Read-only access to private repo.
What I suggest is to create a new token even with read/write as a Temporary token. Then pull/fetch the changes and delete the Token directly.
Apparently, GitHub has heard you and added a new beta feature called "Fine-Grained Tokens"!
https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/
"Create a fine-grained, repository-scoped token suitable for personal API use and for using Git over HTTPS"
Go to setting/developer settings/Personal Access Tokens/Fine grained token
I have a project which our research lab is working, but only a few members can have access to the codes. We are using Git and BitBucket, but we want to use the server lab as our main repository. I have the following constraints:
We don't have admin rights;
Only a few members can have access to the files;
Every lab member already has its own login in the server.
How can I make this work?
I was thinking to ask the admin to add a group in the server, which would have read/write rights in our Git repository folder. Does it work? Is there a better way to manage these Git repositories with these constraints?
In addition to what Borealid wrote in his answer, you could also use gitolite. It allows you to have much more fine-grained access control (e.g. you can prevent users from deleting your repositories or prevent (some of) them from pushing to certain branches). It doesn't require root access.
Having a POSIX group which is granted access to the repository directory is a fine way to do things.
Just be aware that you have to trust the other group members - they could delete the directory entirely, without using the git client.