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.
Related
I have a service account that I need to use to access GitHub.
This service account has two-factor authentication enabled.
I do not have access to the UI.
I do have the password for that service account.
I need to create a personal access token and to accept transfer of a GitHub app to this service account.
Is this possible using the GitHub API v4?
There is a feature request pending using the official GitHub CLI gh
Create/Revoke Personal Access Tokens #2531
Proposed solution
Calling gh token create will create a new token and output the token value
Calling gh token revoke will revoke the token passed in
But there is no obvious existing API to create/revoke a PAT, only SSH keys, which could be a workaround, if you can use SSH URLS: the PAT is only needed for HTTPS URLs.
However, for checking an OAuth App token, you do need indeed a token.
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.
When I try to push anything into my Gitlab repo, I'm being asked for a password, the thing is that I don't know if i'´s asking for my account password or a repository password. In either case I don't have a password for them because I was never prompted to create one.
I created my account by linking a Bitbucket account, which in turn is linked to my Gmail account.
Does Gitlab create a password for me automatically, like the username it creates off my email?
If you create your GitLab account by linking a Bitbucket account, which in turn is linked to your Google account, then your GitLab account's password is the same as your Google password.
This is referred to as Single sign-on (SSO):
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of several related, yet independent, software systems.
You could also use Google SSO to create an account on GitLab instead of using Bitbucket SSO. This has several advantages:
It's directly linked to your Google account, just like the Bitbucket account.
Maintains a 1-1 relationship between Google SSO and third-party Git hosting services.
There is one less SSO service you are dependent upon. By using Bitbucket SSO you are reliant on both Google SSO and Bitbucket SSO when signing into GitLab.
In short, it makes more sense to use a single SSO service rather than multiple services. Partially, that's where the name comes from.
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/
Is there a way with a single app to access Graph, VSTS, and Azure information? It seems access to each of these requires it's own app with origination and callback urls.
For Azure, I'm using NPM's passport-azure-ad in a node js app.
Ideally, I would like to combine VSTS build info, Azure service usage info, and User profile info.
Each of the services you mentioned has their own API:
Azure REST API
Visual Studio Team Services REST API
Microsoft Graph
This does not however mean that they also each need their own "app". When you register your application in Azure AD via the Azure Portal you're able to request access to a number APIs. Each access_token you receive will be tied to one API (called a "resource") but you can use the refresh_token to switch the targeted resource:
The only exception here is the VSTS REST API. While most APIs use the same identity provider, VSTS has their own. So for the purposes of VSTS, you will need to have the user authenticate separately. Obviously, that isn't a great user experience but there is a useful workaround: Personal Access Tokens.
Using a Personal Access Token for VSTS allows you to authenticate the user via Azure AD OAuth and get an access token you can use with Microsoft Graph and the Azure REST API. Once you've authenticated them, you can ask them to provide a Personal Access Token to access VSTS. This allows you to forgot asking the user to authenticate a second time since you'll store their PAT use it for any calls to VSTS.
First, there is Allow scripts to access OAuth token option in the Phase of Build/Release definition, you can check this option and access the token through System.AcessToken variable.
To grant the permission for that user, you need to grant the permission(s) for Project Collection Build Service (xxxx) account.
Secondly, there are some tasks related to Azure (e.g. Azure PowerShell), that can access azure resources (The AAD application is associated to the Azure endpoint)
You can retrieve the necessary information in multiple task, then store the result in the variables through Logging Commands (##vso[task.setvariable]value), then combine them together.