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.
|
| 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. |
| 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 |
| 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
Oldest comments (0)