We have a Generator that generates and pushes code to one of our local Git Repositories with a specific AD account.
Is there a way to push to Azure Repos without having to use a PAT/SSH key linked to a person? Because if that person leaves the company for instance, we have to replace the PAT/SSH keys... We would like to have a solution that is not specific to one person.
Azure DevOps does not allow anonymous pushes into a repository. All of the major Git providers that I'm aware of do this as well for the obvious security reasons.
Your ask is not that uncommon, but at present, there is only one way to achieve this. You basically need to create a user in Azure DevOps that will essentially be a service account. You will want to safely store those credentials and restrict who has access to them. From there, you'll be to create personal access tokens (PAT) or SSH keys as needed for your automation process.
It's worth noting that you will have to pay for a license for the service account.
Similar question/answer can be found here: Is there "Service Account User" concept in AzureDevOps
Related
Just conceptual questions because I apparently doesn't feel the articles already available #google in this topic.
The story:
I have 2 git projects for IaC which create and configure network and create and configure projects. Both of those projects use different service accounts to perform operation on the cloud (different permissions are needed by them and I don't want to have one super account with all permissions). I would like to perform CICD pipeline which will allow to perform in general teraform apply.
The question:
I would like to not store keys for such accounts at GitLab (gitlab variables - I would like to store them in Hashicorp Vault - The goal is to make sure that it will only be avaliable for CICD. No human should be allowed to access those keys. How to make it work? To cloud access keys stored at vault I still need vault key to be stored on runner machine or in gitlab variables both not considered as safe for me, if anyone will get access to vault key it is really easy to access service account keys by Vault Rest API
One way we solve this is by leveraging Gitlab’s identities and Vault’s JWT authentication method.
You can read more about this here: https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/ for Gitlab and https://www.vaultproject.io/docs/auth/jwt for the Vault auth method.
Why would this solve the issue (if I understood your challenge correctly)?
Once you have this setup, you can
create an identity entity in Vault to represent your CI service account
create an alias to bind this identity entity to the identity Gitlab will provide in CI_JOB_JWT
create a policy to allow this identity entity (directly or via a group) to read the secrets)
Hence anyone running the pipeline from another identity won’t be able to read the secrets (because it would map to another identity entity in Vault, so they won’t get a token with that policy)
We provide a library of custom Azure DevOps tasks (Azure DevOps extensions provided through a private Visual Studio Marketplace) to our stakeholders in order to provision resources to Azure. Many times we need to switch an elevated service account to perform operations that are not allowed by the service principal of the Azure service connection, e.g. adding users to groups, or reading secrets from a central key vault.
What is the best way to establish this security context securely? Currently we have the credentials of this elevation service principal hard coded in our task code. Unfortunately this is easily retrieved by our stakeholders because the code is readable within the same Azure DevOps job context, so it is not safe.
Does Azure DevOps provide a special task context that we can utilize to encrypt the service principal credentials somehow? Are there any other routes to securily perform operations from a centralized security principal from within these custom tasks of ours?
If you're using classic Releases you can define variables that you can reference in your steps with the syntax $(variableName). Variables can be made secret, so it's not possible to retrieve them.
Alternatively, if you're using yaml multi-stage pipelines then variables can be defined directly in the yaml. In this case you'll probably what to use a variable group so that you define the secrets either directly in the variable group or link to a key vault.
For the requirement of not allowing new pipelines to be set up to use variable groups you could investigate the Library assets security roles and / or putting your pipelines in a separate Azure Devops project within your organisation.
Depending on what your tasks are doing you might be able to rewrite them to use a task that makes use of the built in Azure Resource Manager service connection, for example the AzurePowerShell#4 task, rather than using your own service principal credentials, as another solution entirely.
First thought is that as soon as pipelines are capable of accessing
the secrets then we are bad.
Not sure if I understand you well. But if you don't want those stakeholders to access the secrets in your task context within some specific pipelines, you can consider combining the Variable Group and Pipeline Security.
1.For Library(Variable Group): Store the secrets here and enable Change variable type to secret. Then manage its security here:
Normally the stackholders can't access the variable group unless you grant access to them. I suggest you create a group to manage the permissions of those stackholders.
2.For pipelines: You can limit the view/edit related permissions in pipelines' security:
For all pipelines:
For one specific pipeline:
You can deny the View/Edit related permissions and only allow Queue build permission so that the stackholders can run your build but not see details about how you define the task context:
Hope it helps :)
I have a couple open source projects hosted on GitHub where I would like to use Azure pipelines for automated testing, building, and deploying. These projects typically involve collaborating with others outside my institution. My Azure account is an Organizational account for the University where I work. If I create an organization on Azure it ends up being "owned" by my University which means that collaborators have to go through some extra hoops to get access to the Azure organization (become a user or project admin). We've also considered having my collaborator create the organization, but their account is also tied to their institution and has even more restrictions.
Apart from making a separate Azure account on a separate email, is there any way that I can make an organization that isn't "owned" by my University?
You could create a new DevOps organization, and disconnect the AAD from Organization Settings -- Azure Active Directory, then you could add the external users in this organization. In this way, external users won't be added in the azure.
We will be building a couple of non-interactive scripts and console applications which will be invoking the Azure DevOps REST API to do various tasks. These apps and scripts will be executed via a job scheduler. What authentication scheme would be the correct one to use for this scenario? It seems like a PAT would work, however, I really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles. Is the correct approach to establish a "fake" Azure Active Directory user and use that user as the owner of the PATs? Is there something else that I am missing here?
Looking at the Authentication Guide, it seems like all of the mechanisms referenced result in some form of interactivity.
Also, we have Conditional Access Policies being enforced in our Azure DevOps organization. One of those policies is the requirement for MFA. If we use a PAT, how will that work? According to this link, it sounds like access may be blocked.
Personal access tokens (PATs) are used for personal authentication. They are alternate passwords that you can use to authenticate into Azure DevOps.
Really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles.
Yes, as you have pointed out. It doesn’t support to create a PAT token with a service account in Azure DevOps Service.
That would be ok to use the public fake MFA account to login Azure DevOps Service. And then use that account to generate PAT token. When request API, others simply use that generated PAT token to authenticate.
With CAP enabled the doc is clear. For Web flows, CAP is honored 100%. That means in most of the situations, Rest API will not be affected.
The limitation is third-party client flow. Some actually due to configuration of third-party. There's nothing we can do in Azure DevOps. You have to follow the policy mentioned in that link. If users do not meet IP range, it will be blocked.
I have an account in VSTS, which have both personal and work account. I have a project named abc.visualstudio.com under my work account. I would like to change this project to my personal account.
Changing ownership to a different person is quiet easy in VSTS. Changing a project from one directory to another of the same person is a bit tricky and I am struggling to get this done.
Make sure that "xyz#hotmail.com" is the current owner of the VSTS account and then disconnect the VSTS account from the linked Azure AD, the owner will switch to the Microsoft Account with "xyz#hotmail.com".
One important thing you need to know is that disconnecting VSTS from AAD will cause the other users who use the work account cannot sign in. So you need to make sure that all the other users also switch to microsoft account.