Microsoft’s Devops story
Bron: https://www.dotnetcurry.com/devops/1428/microsoft-devops-story
Abstract: Learn how Microsoft built VSTS (now known as Azure DevOps) based on the DevOps learning of its users, and get inspired to implement DevOps in your organization.
Azure DevOps (formerly called VSTS – Visual Studio Team Services) is a cloud-based environment used to build software projects with complete lifecycle from planning, development, testing to deployment.
It is a cloud version of Team Foundation Server (now called as Azure DevOps Server). It provides services like work item tracking, source control (with inbuilt support to TFVC – Team Foundation Version Control as centralized VC – Version Control and Git as distributed VC), build management, test management, release management and many more. It is Azure’s service in the form of SaaS (Software as a Service).
Whenever a team uses these set of services for a complete development cycle, they want to ensure that it should be as secure as possible.
In this tutorial, I will discuss key concepts of Security features for Azure DevOps along with Azure DevOps Server.
As there are a lot of different features available, I will be focusing on some of them like group-based security, database related security for Azure DevOps Server and so on. I will also discuss security with respect to version control, build management, work item queries and access levels with Azure DevOps.
Datadog, a monitoring and analytics platform that integrates with more than 250 technologies, unites metrics, traces, and logs in one platform so you can get full visibility into your infrastructure and applications. With powerful dashboards, anomaly and outlier detection, and distributed tracing, Datadog helps you get a handle on the performance of your .NET applications, as well as their underlying infrastructure.
Click here to try Datadog’s full-stack monitoring for free! (No Credit Card required)
Azure DevOps Server 2019 (formerly called as Visual Studio Team Foundation Server) is the on-premises version of Azure DevOps.
Being the on-premises version, the responsibility of major decisions like where to do the installation of Server (Application Tier) as well as the Database (Data Tier), lies with us.
Normally every organization has an Active Directory (AD) as a security umbrella and all users are within the domain in the AD. Azure DevOps Server follows the recommended practice of using a service account which will work as an impersonation account to access database of Azure DevOps Server 2019.
You can install Azure DevOps Server, SQL Server Database Engine, SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS) as well as SQL Server Reporting Services (SSRS) on one or multiple machines as per the requirement. It is recommended that you configure one service account for accessing Azure DevOps Server (domain\TfsService) and another one for accessing SSRS (domain\TfsReports). The service account for Azure DevOps must be having “Log on as a Service” permission while the one for reports must have “Allow log on locally” permission.
Creating a service account will help any user to connect to Azure DevOps Services in following manner, without having any permissions directly on the SQL Server database.
Figure 1: How Azure DevOps uses Service Account
While configuring the Azure DevOps Server for an organization, it is recommended that you specify the name of the service account which in turn will access the services on behalf of any user. At the application tier level of Azure DevOps Server, the user will get access to only those services for which he or she is given a direct or indirect permission.
Indirect permissions are through membership of a group. I will discuss the groups in detail as the next concept.
It is not recommended to provide the same account with which you are installing Azure DevOps Server (as the services account). For e.g. If I am installing with account domain\Gouri, the user domain\Gouri must not be the service account, hence I mentioned TfsService as a separate account.
The user will have access to various services of Azure DevOps depending upon which group he/she belongs to. There are built-in groups to manage administrative tasks like TFS server administrator group, Team Project administrator group, Project administrator group etc.
Team Foundation Server Administrators Group: Any user belonging to this group will be able to create a new Team Project Collection (TPC) and administer existing TPCs. Figure 2 shows users as a part of this group. We can configure who is a member of this group by using Team Foundation Server Administrative Console (available on the server where Azure DevOps Server is installed).
The user who installs the Azure DevOps Server automatically becomes a member of this group. It is a best practice to add at the least one more user to this group as a backup in case of urgencies and emergencies.
Figure 2: Users in TFS administrators group
Team Project Collection Administrators Group: Any user added to this group cannot create a new TPC but will be able to create new Team Projects in the TPC (for which he/she is administrator). The Team Projects can be based on process like Agile, Scrum or CMMI.
Figure 3: TPC administrators’ group
The users can be added to this group by using the web portal for Azure DevOps Server 2019. In figure 3, there are two TPCs seen in left hand side pane, and the users added to TPC Administrators group in right hand side pane.
Team Project Administrators Group: The users added to this group cannot add a new Team Project but can administer the team project for which they are administrators. Figure 4 shows the Team Project selected from Azure DevOps Server 2019 in the left-hand side pane and the users added to the group of Project Administrators.
Figure 4: Team Project Administrators group
Now that we have seen all the administrator groups, let us view the groups that are for regular non-administrator users.
Contributors Group: the users added to this group can have access to all developer centric activities. These can involve managing work items, checking in or committing code, triggering build or release.
Figure 5: Contributors Group and Users
For configuration of build agent or creating build definition, one needs to be in the group of build administrators.
TFS administrators, TPC administrators, TP administrators, Contributors and Build Administrators are the main groups with which we can configure access to Azure DevOps Server. These restrictions are at the level of the application tier.
The built-in reports can either be based on OLTP database or analysis services. The database for this is called as DataWarehouse. We will have to create a login which can access this database for creating custom reports.
Similarly, we can provide access to TfsWarehouseAdministraor role or TfsWarehouseDataReader role for accessing SSAS. The users in role TfsWarehouseDataReader will be able to view the reports created. This service account will be responsible for accessing SSRS for viewing data. For any additional privileges, add the user to TfsWarehouseAdministrator role.
Figure 6 shows the two service accounts I discussed added to these roles.
Figure 6: Data Tier Security
Let us move to various security measures using Azure DevOps now.
Most security aspects are also available in Azure DevOps Server like Work Item Queries level security, Security for Version Control, build administrators group, Build Service account. Azure DevOps being SaaS, we do not have to worry about installation, configuration and even taking the backup of database.
On the other hand, for on-premises server, the data remains with the organization.
Another difference is with Team Project Collections which are available with on-premises but not with the cloud version.
The main concern which organizations’ have about using Azure DevOps is that the data (code under version control, work items for project management, build management, release management as well as test management) is stored with Microsoft. However one point to note is that this data is secure, as it is stored in encrypted format.
Similar to active directory for any organization (on premises domain) and various user in it, we have AAD (Azure Active Directory) with Azure DevOps. This AD can either be synced with an organization on-premise domain (used with Active Directory Domain Services) or kept separate. This depends on every organization.
Similar to TFS (Azure DevOps Server) we have organization in Azure DevOps. There is no direct similarity with TPC in Azure DevOps, but there can be as many Team Projects as required for the organization.
Access level grants or restricts access to features. This feature works in addition to the security related groups we have already discussed.
Azure DevOps organization once created is free forever up to 5 (Basic) users. The users can be with various Access Levels – Basic, Stakeholders and Visual Studio Subscription.
Figure 7: Access Levels in Azure DevOps
Stakeholder: it is similar to read-only view for Azure DevOps. We can add as many users with this access as required (no restriction to number of users). The users can view the project status, but cannot contribute to code. They can provide feedback for the project
Basic: these users can contribute to code and manage projects
Visual Studio Subscription: the users who already have Visual Studio subscription for Professional, Test Professional or Enterprise. These will get access as per their subscription.
We can setup a granular level security for the queries we create. The queries can be added to the folder and we can restrict the access to those folders as well as to individual queries.
It should be always be kept in the mind that if any permission is denied for a particular user, that takes the precedence over any grant. This means even though a user belongs to Contributors groups, he / she can be denied permission to read a folder as shown in Figure 8.
Figure 8: Deny grant to a user
If a user belongs to two different groups and for one group permission to read is denied, then the user does not get the permission to read although he / she may be in an administrator group otherwise.
Similarly, we can provide security to Iterations and Areas also. We can restrict access to any Iteration or Area. It makes more sense to restrict access to a particular work item since it is logical segregation. Figure 9 shows access to work items from Area “Business Logic” is restricted to the user.
Figure 9: Area level permissions to a user
There are two types of version control with Azure DevOps (cloud version or on premises). They are namely Team Foundation Version Control (TFVC) and Git. TFVS is centralized version control, whereas Git is distributed.
There are two distinct ways for both the version control types. We have security to the file level with TFVC (Team Foundation Version Control), but only to repository and branches for Git. The common permission for both types is at the repository level.
Let’s view git security first. Go to Azure DevOps Team Project > Project Settings > Repositories
Figure 10: Security for repositories
Branch level security can be set similarly by Team Project > Repo > Branches and by clicking on the ellipse button for branch name.
Figure 11: Branch level security
Let’s now view the security in the TFVC model.
TFVC Security: We can have more granular level security for TFVC from Visual Studio. Connect to Source Control Explorer from Visual Studio and select any file or folder to restrict access to it. Select a file from Source Control Explorer, right click > select Advanced and Security.
Figure 12: File check-in access restricted to user but read access allowed with TFVC
in this tutorial, I have discussed various security features for Azure DevOps with cloud functionality, as well as on-premises functionality.
If an organization is interested in having an immediate access to a new feature added with no hassles for server-side management, choose Azure DevOps. On the other hand, if the organization needs the data to be on their network with the back end as SQL Server, they can select Azure DevOps 2019 Server.
This article has been editorially reviewed by Suprotim Agarwal.
