Skip to content

arindam0310018/20-Nov-2022-DevOps__Service-Principal-Service-Connection-Schema

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 

Repository files navigation

SERVICE PRINCIPAL AND DEVOPS SERVICE CONNECTION: SCHEMA

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:-
Image description
Service Connection(s) for DevOps Project A:-
Image description
Service Connection(s) for DevOps Project B:-
Image description
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:-
Image description
Service Connection(s) for DevOps Project A:-
Image description
Service Connection(s) for DevOps Project B:-
Image description
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:-
Image description
One Service Principal, Multiple Secrets Per Projects and Environments
Image description
Service Connection(s) for DevOps Project A:-
Image description
Service Connection(s) for DevOps Project B:-
Image description
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