Greetings my fellow Technology Advocates and Specialists.
In this Session, I will provide you real-time insights including food for thoughts on Service Principal and DevOps Service Connection Schema.
| IMPORTANT TO NOTE:- |
|---|
| Here in this reference blog, we talk only about __Service Principal(s) which are created with the sole purpose of Creating DevOps Service Connection(s) used for Running Pipelines for Infrastructure Deployment (IaC). |
| In most establishment(s), every project which is onboarded to cloud has its own Subscription (Per Environment - NonProd and Prod) and DevOps Project. |
| The DevOps Project will then have its own Service Connections for below - 1) Running Pipelines for Infrastructure Deployment (IaC), and 2) Running Pipelines for Application Deployment on the deployed Azure Services (by IaC). |
| QUESTION HERE IS:- |
|---|
| Should we have - 1) One Service Principal Per Project & Environment (NonProd and Prod), or 2) One Service Principal Per Project 3) One Service Principal for All Projects. |
| SCHEMA #1:- |
|---|
| ONE SERVICE PRINCIPAL PER PROJECT AND ENVIRONMENT APPROACH:- |
|---|
| PROJECT NAME | ENVIRONMENT | SERVICE PRINCIPAL NAME | DEVOPS SERVICE CONNECTION NAME |
|---|---|---|---|
| Project A | NONPROD (Dev) | am-projectA-nonprod-dev-infra-spi | am-projectA-nonprod-dev-infra-spi |
| Project A | NONPROD (UAT) | am-projectA-nonprod-uat-infra-spi | am-projectA-nonprod-uat-infra-spi |
| Project A | PROD | am-projectA-prod-infra-spi | am-projectA-prod-infra-spi |
| Project B | PROD | am-projectB-prod-infra-spi | am-projectB-prod-infra-spi |
| NOTE:- |
|---|
| Below is the Naming Convention for Service Principal and Azure DevOps Service Connection used in the Reference Example. Both have Same Name. |
| Establishment Name_Project Name_Environment Name_Category_Type_ |
| RELEVANT SCREENSHOTS:- |
|---|
| All Service Principals relevant for Schema #1:- |
 |
| Service Connection(s) for DevOps Project A:- |
 |
| Service Connection(s) for DevOps Project B:- |
 |
| PROS:- |
|---|
| If Service Principal is accidently deleted, only One Project and One Environment is affected. |
| CONS:- |
|---|
| Multiple Individual Service Principal Management Per Environment - 1) Secret Expiry, 2) Key Vault Update Post Secret Renewal (Create a New Version, Disable Previous Version). |
| Inventory Management. |
| Similar and Repetitive Microsoft Graph API rights (With Admin Consent) needs to be configured and applied to Service Principal Per Project and Environment. |
| SCHEMA #2:- |
|---|
| ONE SERVICE PRINCIPAL PER PROJECT APPROACH:- |
|---|
| PROJECT NAME | ENVIRONMENT | SERVICE PRINCIPAL NAME | DEVOPS SERVICE CONNECTION NAME | NOTES |
|---|---|---|---|---|
| Project A | NONPROD (Dev) | am-projectA-infra-spi | am-projectA-nonprod-dev-infra-spi | Secret is same for all environments (Dev, UAT and Prod) for each project. |
| Project A | NONPROD (UAT) | am-projectA-infra-spi | am-projectA-nonprod-uat-infra-spi | Secret is same for all environments (Dev, UAT and Prod) for each project. |
| Project A | PROD | am-projectA-infra-spi | am-projectA-prod-infra-spi | Secret is same for all environments (Dev, UAT and Prod) for each project. |
| Project B | PROD | am-projectB-infra-spi | am-projectB-prod-infra-spi | Secret is same for all environments (Dev, UAT and Prod) for each project. |
| NOTE:- |
|---|
| Below is the Naming Convention for Service Principal and Azure DevOps Service Connection used in the Reference Example.__ |
| Service Principal Name = Establishment Name_Project Name_Category_Type |
| DevOps Service Connection Name = Establishment Name_Project Name_Environment Name_Category_Type |
| RELEVANT SCREENSHOTS:- |
|---|
| All Service Principals relevant for Schema #2:- |
 |
| Service Connection(s) for DevOps Project A:- |
 |
| Service Connection(s) for DevOps Project B:- |
 |
| PROS:- |
|---|
| If Service Principal is accidently deleted, only One Project (All Environments - Dev, UAT and PROD) is affected. |
| IMPORTANT FACT:- |
|---|
| Risk is Higher as compared to Pros of Schema #1 |
| CONS:- |
|---|
| Multiple Individual Service Principal Management Per Environment - 1) Secret Expiry, 2) Key Vault Update Post Secret Renewal (Create a New Version, Disable Previous Version). |
| Inventory Management. |
| Similar and Repetitive Microsoft Graph API rights (With Admin Consent) needs to be configured and applied to Service Principal Per Project. |
| IMPORTANT FACT:- |
|---|
| Effort is Little less as compared to cons of Schema #1 |
| SCHEMA #3:- |
|---|
| ONE SERVICE PRINCIPAL FOR ALL PROJECT APPROACH:- |
|---|
| PROJECT NAME | ENVIRONMENT | SERVICE PRINCIPAL NAME | DEVOPS SERVICE CONNECTION NAME | NOTES |
|---|---|---|---|---|
| Project A | NONPROD (Dev) | am-infra-spi | am-projectA-nonprod-dev-infra-spi | Individual Secret is Per Project and environments (Dev, UAT and Prod) within the Same Service Principal. |
| Project A | NONPROD (UAT) | am-infra-spi | am-projectA-nonprod-uat-infra-spi | Individual Secret is Per Project and environments (Dev, UAT and Prod) within the Same Service Principal. |
| Project A | PROD | am-infra-spi | am-projectA-prod-infra-spi | Individual Secret is Per Project and environments (Dev, UAT and Prod) within the Same Service Principal. |
| Project B | PROD | am-infra-spi | am-projectB-prod-infra-spi | Individual Secret is Per Project and environments (Dev, UAT and Prod) within the Same Service Principal. |
| NOTE:- |
|---|
| Below is the Naming Convention for Service Principal and Azure DevOps Service Connection used in the Reference Example.__ |
| Service Principal Name = Establishment Name_Category_Type |
| DevOps Service Connection Name = Establishment Name_Project Name_Environment Name_Category_Type |
| RELEVANT SCREENSHOTS:- |
|---|
| All Service Principals relevant for Schema #3:- |
 |
| One Service Principal, Multiple Secrets Per Projects and Environments |
 |
| Service Connection(s) for DevOps Project A:- |
 |
| Service Connection(s) for DevOps Project B:- |
 |
| PROS:- |
|---|
| Service Principal Management (Secret Expiry) is much easier as all resides under the Same Service Principal. |
| No Overhead of Inventory Management. |
| No Similar and Repetitive Microsoft Graph API rights (With Admin Consent) needs to be configured and applied as there is only one Service Principal for all Projects. |
| IMPORTANT FACT:- |
|---|
| Effort is Much less as compared to cons of Schema #1 |
| CONS:- |
|---|
| If Service Principal is accidently deleted, All Projects and All Environments (Dev, UAT and PROD) in Each Project gets impacted at once. |
| IMPORTANT FACT:- |
|---|
| Risk is Much Higher as compared to Pros of Schema #1 and Schema #2 |
So, in conclusion, it completely depends upon Azure Solutions and DevOps Architects of the Establishment which Schema/Schemas they would like to implement for Project(s) or across Project(s).
Hope You Enjoyed the Session!!!
Stay Safe | Keep Learning | Spread Knowledge