Is there a way to make an access token that is only usable for one project? It seems there are only personal access tokens, which gives access to all of my projects.
Yes!
See GitLab 13.3 (August 2020)
Project access tokens
Project level access tokens allow access to a project without the need to provision a new GitLab user.
Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API.
Project access tokens will be authorized as Maintainers.
This new functionality will make programmatic access to GitLab easier, more secure, and less cost prohibitive.
See Documentation and Issue.
See also GitLab 13.5 (October 2020)
Project access tokens for GitLab.com
In GitLab 13.3, we introduced project-level access tokens for self-managed instances, allowing access to a project without the need to provision a new user.
We are now making project-level access tokens available in GitLab.com! Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API and Git. Project access tokens will not increase the licensed seat count and are authorized as Maintainers. This new functionality will make programmatic access to GitLab easier, more secure, and less cost prohibitive.
See Documentation and Epic.
See GitLab 14.1 (July 2021)
Select project access token role
Select project access token role
Users can now specify the level of access that a project token should have on the project level upon creation and can view existing project access token roles.
Prior to this release, project access tokens had the Maintainer role. For some users, this role included elevated permissions that were not required.
To avoid abuse, this feature is available for all users except for free GitLab SaaS accounts. All self-managed users as well as Premium and Gold SaaS customers can now easily select and view the appropriate role for their project access tokens.
See Documentation and Issue.
And don't forget about group access token, that you now can create with API or UI since GitLab 14.7 (Jan. 2022).
Deploy keys allow read-only or read-write (if enabled) access to one or multiple repository. Deploy keys can be used for CI, staging or production servers. You can create a deploy key or add an existing one.
Docs: https://docs.gitlab.com/ee/user/project/deploy_tokens/
Related
I am wondering if it is a way to automatically assign a role to a user for a specific group in GitLab when using SAML?
We are using Keycloak as our IdP together with the community edition of GitLab. We have been able to configure GitLab so that we can authenticate the user through Keycloak. Although we want to automatically assign the user to GitLab groups and roles, based on roles in Keycloak. Is this possible?
This feature is only available in Enterprise Edition of Gitlab. For community edition you can only specify if the user is external (Freelancer) or not.
Is it possible in Azure DevOps to create a "ReadOnly Deploy Token" for a repository?
Practically, to access the repository in a "ReadOnly" mode with a url, eg:
https://deploy:myDeployToken#dev.azure.com/myCompany/myProject/_git/main
We want to link a Private Azure DevOps Repository as a composer repository.
GitLab has such a feature that looks like this:
You'd need to create a personal access token with Code (Read) scope that only has access to that specific repository.
Or register an ssh key for a user that only has read access to that repository.
There are no repository scoped tokens in Azure DevOps that you can easily generate.
What you can do, is kick off a pipeline and steal its token (for the duration of the pipeline), you can set the desired permissions for those. But that's an OAuth token that will expire after a short time.
There should be an API to generate such OAuth tokens, but that's no available from any UI and those tokens have a relatively short life.
There's a documentation for Azure Pipelines that elaborates what kind of authentications can be done to access GitHub repositories: GitHub App, OAuth and Personal Access Token. (https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#github-app-authentication)
The documentation says that the GitHub App authentication is the "recommended" one but later it does not really turn out why this is the case... E.g. there is one interesting thing that worked with GitHub App authentication: Creating a yaml pipeline where you define a container ACR resource with a "latest" trigger. With the correct ARM Service Connection from the yaml somehow Azure DevOps is creating an Webhook for the specific ACR however if you use PAT it is not the case.
Is there an actual best practice for the authentication type? Or generally a good argument why one is better than the other?
A personal Access Token and an OAuth token link Azure Pipelines to GitHub with your user account. Your access token will be used to download the repo and the pipeline could access the token to access any repository your user has access to. While often convenient, it's a problem since you may not be the only person using the integration, so others could use your credentials by changing the pipeline.
The user bound tokens also have the problem that the owner of that user account may leave the company, breaking all pipelines, or worst, requiring quite a bit of reconfiguration to make sure that user loses all the access to the repositories the pipeline has access to.
The GitHub App will allow you to configure exactly what repositories should be allowed to be accessed by Azure Pipelines. It's decoupled from your user account and the access can be limited to just the repositories you want.
2FA authentication is enabled in our organization, meaning any user who logs into GitLab is prompted with 2FA. Recently, we had to create a Service Account for various business reasons. How could we disable 2FA only for the Service Account user.
Instead of trying to deactivate 2FA for a user, make sure that user has a PAT (Personal Access Token)
As explained in "Use personal access tokens with two-factor authentication"
When 2FA is enabled, you can’t use your password to authenticate with Git over HTTPS or the GitLab API.
You can use a personal access token instead.
Using the PAT as password allows the user to bypass the 2FA step.
Considering GitLab, and the access to npm registry, as per issue 9140, this (using a PAT) is not yet supported (Apr. 2022).
That meant (before issue resolution) you has to use a dedicated account without 2FA, possibly from a different organization which would exist solely for:
hosting service accounts
without 2FA (since 2FA would not be mandatory in that second organization)
That was certainly a workaround, but one which would allow you to wait for the resolution of the aforementioned GitLab issue.
However, the issue was resolved for GitLab 12.2 (Aug. 20219).
See "npm packages in the Package Registry / Authenticate with a personal access token or deploy token".
Furthermore, with GitLab 15.2 (July 2022), you can make sure everybody does have 2FA.
Audit events when two-factor authentication is disabled
GitLab now records an audit event when a user disables their two-factor authentication (2FA) settings.
This audit event helps you ensure that all the users in your instance are properly using
2FA (and identify when the security of a user’s account has been lowered),
so that you can investigate and take action.
See Documentation and Issue.
Settings
I'm creating an Azure Logic Apps (which is one of the recommended tool from Microsoft for integration purposes) to fetch all "work items" and "projects" from Azure DevOps.
As I said, it is to integrate with other data sources in a Cosmos DB database.
I already integrated some of our internal cloud hosted software to the Cosmos database and I therefore have a working workflow which is, querying -> parsing -> formating -> publishing.
Issue and question
I would like to use the best authentication method so that it is not linked to a single user, but more on the organization level. (If the "admin" employees leaves the company, I wouldn't want to have to regenerate a new token with the credentials of the new admin, etc)
I would like to know which are the best avenues for this kind of project.
Would associating the fictive Azure AD admin to the DevOps admin rights and using his account with an API Connection to DevOps be a good idea?
It seems messy to me and I was hoping something else would work.
The results to the queries would be integrated with other data sources from our other internal softwares to do BI reporting. As a mater of facts, all our other cloud hosted softwares had REST API in which you could create a permanent token not associated with a user, but instead with our license, and had all read-write rights. Why is this not a thing with DevOps?
Things that did not work for me
I have already tried generating a token with my own account. I also asked our admin to generate a private access token, but they have expiry date and this is a problem to have our integration set-up.
I have also looked in this documentation, but all the methods seem to use user-related authentication, no full-scale, or organization-scale authentication.
Expected Workflow
This is the desired workflow
Like you've already researched, I believe authentication is always in the context of a user.
The only solution I see is to create a new user in AAD which you control and use a token for that user in your Logic App.