1
00:00:00,000 --> 00:00:02,280
You already know how your own work account works.

2
00:00:02,280 --> 00:00:04,440
You sign in with a password or maybe Windows Hello,

3
00:00:04,440 --> 00:00:06,640
approve an MFA prompt and if you forget your password,

4
00:00:06,640 --> 00:00:07,480
you reset it.

5
00:00:07,480 --> 00:00:09,960
But software needs access too and nobody sits at a keyboard

6
00:00:09,960 --> 00:00:11,800
to approve a prompt for a running app.

7
00:00:11,800 --> 00:00:13,600
So a logic app might need to read a mailbox

8
00:00:13,600 --> 00:00:16,520
at two in the morning or an app might need to reach a database

9
00:00:16,520 --> 00:00:18,520
or a backup job might need to save files

10
00:00:18,520 --> 00:00:19,520
while everyone is asleep.

11
00:00:19,520 --> 00:00:20,360
So who is signing in?

12
00:00:20,360 --> 00:00:23,520
And that brings us to Microsoft Entra Workload Identities.

13
00:00:23,520 --> 00:00:24,600
By the end of this episode,

14
00:00:24,600 --> 00:00:27,640
you'll have a plain English map of user identities,

15
00:00:27,640 --> 00:00:31,000
workload identities, app registrations, service principles,

16
00:00:31,000 --> 00:00:32,400
and managed identities.

17
00:00:32,400 --> 00:00:34,600
This matters because old apps often hide passwords

18
00:00:34,600 --> 00:00:36,840
in code, config files, or build pipelines.

19
00:00:36,840 --> 00:00:39,720
Some have broad access, some have no clear owner at all.

20
00:00:39,720 --> 00:00:40,920
And the safer choice often means

21
00:00:40,920 --> 00:00:43,360
the developer never handles a password in the first place.

22
00:00:43,360 --> 00:00:45,880
Let's start with the identity you already use every day

23
00:00:45,880 --> 00:00:48,240
then compare it with the one that software uses.

24
00:00:48,240 --> 00:00:50,480
User identities and workload identities.

25
00:00:50,480 --> 00:00:52,480
People and software both need access

26
00:00:52,480 --> 00:00:54,800
but they prove who they are in very different ways.

27
00:00:54,800 --> 00:00:56,800
Your user identity is your digital badge.

28
00:00:56,800 --> 00:00:58,800
It connects to your name, your work account,

29
00:00:58,800 --> 00:01:00,480
your groups, and the job you do.

30
00:01:00,480 --> 00:01:02,440
When you sign into Outlook Teams, SharePoint,

31
00:01:02,440 --> 00:01:05,320
or another Work app, Microsoft Entra checks that badge.

32
00:01:05,320 --> 00:01:06,920
You might use a password, your phone,

33
00:01:06,920 --> 00:01:08,680
a security key, or Windows Hello.

34
00:01:08,680 --> 00:01:10,160
Then MFA adds another check.

35
00:01:10,160 --> 00:01:12,640
Entra asks, "Is this really Mirko or someone pretending

36
00:01:12,640 --> 00:01:13,560
to be Mirko?"

37
00:01:13,560 --> 00:01:15,480
That works because there is a person at the other end

38
00:01:15,480 --> 00:01:17,840
who can type a code, tap approve, or use a fingerprint,

39
00:01:17,840 --> 00:01:18,640
or face.

40
00:01:18,640 --> 00:01:20,200
A workload identity is different.

41
00:01:20,200 --> 00:01:22,040
It's a digital badge for software.

42
00:01:22,040 --> 00:01:23,760
That software could be an app your team built

43
00:01:23,760 --> 00:01:25,400
an automation that runs on a schedule,

44
00:01:25,400 --> 00:01:27,680
a background service, or even an AI agent

45
00:01:27,680 --> 00:01:30,400
that needs access to company data for a defined job.

46
00:01:30,400 --> 00:01:30,920
Here's the thing.

47
00:01:30,920 --> 00:01:33,480
Think of Microsoft Entra ID as the reception desk

48
00:01:33,480 --> 00:01:35,080
in a modern office building.

49
00:01:35,080 --> 00:01:37,360
When you enter the building, you show your personal badge

50
00:01:37,360 --> 00:01:40,520
so reception can see who you are, which teams you belong to,

51
00:01:40,520 --> 00:01:42,640
and which rooms you may enter.

52
00:01:42,640 --> 00:01:44,960
A workload enters with a badge assigned to its job,

53
00:01:44,960 --> 00:01:46,840
not to a person.

54
00:01:46,840 --> 00:01:49,120
The logic app badge might say, "I send an alert

55
00:01:49,120 --> 00:01:50,880
when a support request arrives."

56
00:01:50,880 --> 00:01:52,440
A virtual machine badge might say,

57
00:01:52,440 --> 00:01:54,960
"I can read one secret from the company vault."

58
00:01:54,960 --> 00:01:56,400
A backup service badge might say,

59
00:01:56,400 --> 00:01:58,440
"I can write backup files to this location."

60
00:01:58,440 --> 00:02:00,280
And a GitHub pipeline badge might say,

61
00:02:00,280 --> 00:02:02,120
"I can deploy this approved piece of code

62
00:02:02,120 --> 00:02:04,080
into this Azure resource group."

63
00:02:04,080 --> 00:02:06,480
Each workload needs access for a reason.

64
00:02:06,480 --> 00:02:08,040
Giving each one its own identity,

65
00:02:08,040 --> 00:02:10,520
let's enter check that reason, recorded silence,

66
00:02:10,520 --> 00:02:11,960
and control what it can reach.

67
00:02:11,960 --> 00:02:13,440
You've probably seen the older approach,

68
00:02:13,440 --> 00:02:15,120
someone creates a normal user account

69
00:02:15,120 --> 00:02:16,880
like service account at company.

70
00:02:16,880 --> 00:02:18,960
Come gives it a password, maybe a mailbox,

71
00:02:18,960 --> 00:02:21,240
maybe brought permissions, and then several apps share it.

72
00:02:21,240 --> 00:02:23,840
That creates a mess, which app used the account last night

73
00:02:23,840 --> 00:02:26,400
who owns the password, what breaks if you disable it?

74
00:02:26,400 --> 00:02:27,920
And if someone copies that password,

75
00:02:27,920 --> 00:02:29,840
can they act as every app that shares it?

76
00:02:29,840 --> 00:02:31,560
A workload identity fixes that model.

77
00:02:31,560 --> 00:02:32,960
It doesn't pretend to be a person,

78
00:02:32,960 --> 00:02:35,800
it gets its own permissions and its own sign-in records.

79
00:02:35,800 --> 00:02:37,760
That separation gives you a much clearer answer

80
00:02:37,760 --> 00:02:38,880
when something goes wrong.

81
00:02:38,880 --> 00:02:41,240
Now, there is one limit you need to keep in mind.

82
00:02:41,240 --> 00:02:43,560
A workload identity can't complete an MFA prompt

83
00:02:43,560 --> 00:02:45,720
because an app can't pull out a phone and tap approve.

84
00:02:45,720 --> 00:02:47,000
So you protect it in other ways,

85
00:02:47,000 --> 00:02:48,840
like controlling what it can access,

86
00:02:48,840 --> 00:02:51,560
how it proves its identity, and where its silence come from.

87
00:02:51,560 --> 00:02:52,640
People use personal badges

88
00:02:52,640 --> 00:02:54,880
because people work in many places and make choices.

89
00:02:54,880 --> 00:02:56,360
Software uses job badges

90
00:02:56,360 --> 00:02:58,960
because software should perform a narrow task repeatedly

91
00:02:58,960 --> 00:03:00,720
without borrowing a human account.

92
00:03:00,720 --> 00:03:02,520
Once you give software its own badge though,

93
00:03:02,520 --> 00:03:03,880
Enter starts using several names

94
00:03:03,880 --> 00:03:05,560
that sound almost identical.

95
00:03:05,560 --> 00:03:08,240
And that's where most beginners get stuck.

96
00:03:08,240 --> 00:03:10,360
The three names that confuse everyone.

97
00:03:10,360 --> 00:03:12,760
You'll see three names in Enter over and over.

98
00:03:12,760 --> 00:03:15,400
Application registration, service principle,

99
00:03:15,400 --> 00:03:16,800
and managed identity.

100
00:03:16,800 --> 00:03:18,680
They all connect, but they're not the same thing.

101
00:03:18,680 --> 00:03:20,480
Let's start with application registration.

102
00:03:20,480 --> 00:03:22,000
Think of an application registration

103
00:03:22,000 --> 00:03:23,880
as the master record for an app.

104
00:03:23,880 --> 00:03:25,400
It's like the design sheet created

105
00:03:25,400 --> 00:03:27,280
before the app ever enters a company.

106
00:03:27,280 --> 00:03:28,640
It describes the app's name,

107
00:03:28,640 --> 00:03:30,320
where it sends people after sign in,

108
00:03:30,320 --> 00:03:32,960
and what kind of tokens it can ask to enter to issue.

109
00:03:32,960 --> 00:03:35,080
A token is a short-lived digital pass

110
00:03:35,080 --> 00:03:37,640
that lets software ask another service for access.

111
00:03:37,640 --> 00:03:39,280
The application registration also lists

112
00:03:39,280 --> 00:03:41,000
the permissions the app might want.

113
00:03:41,000 --> 00:03:43,520
For example, an app can ask to read calendar data,

114
00:03:43,520 --> 00:03:46,400
call Microsoft Graph, or access a business API.

115
00:03:46,400 --> 00:03:48,600
Microsoft Graph is Microsoft's main doorway for apps

116
00:03:48,600 --> 00:03:51,560
that need to work with Microsoft 365 data and services.

117
00:03:51,560 --> 00:03:52,560
But here's the key.

118
00:03:52,560 --> 00:03:54,840
The registration doesn't mean the app automatically

119
00:03:54,840 --> 00:03:56,880
gets every permission it asks for.

120
00:03:56,880 --> 00:03:59,640
It only describes the app and its possible requests.

121
00:03:59,640 --> 00:04:02,000
Picture a software company building a meeting app.

122
00:04:02,000 --> 00:04:04,680
They create one application registration for that app.

123
00:04:04,680 --> 00:04:06,480
Then many customer organizations can choose

124
00:04:06,480 --> 00:04:08,640
whether they trusted and allowed into their own

125
00:04:08,640 --> 00:04:09,480
entry directory.

126
00:04:09,480 --> 00:04:11,440
One app design can travel to many companies,

127
00:04:11,440 --> 00:04:12,720
but each company still decides

128
00:04:12,720 --> 00:04:14,800
what that app can do inside its own walls.

129
00:04:14,800 --> 00:04:16,960
That local decision happens through the service principle.

130
00:04:16,960 --> 00:04:19,280
A service principle is the app's local identity

131
00:04:19,280 --> 00:04:20,920
inside one entry directory.

132
00:04:20,920 --> 00:04:23,240
It's the record that receives permissions in your company

133
00:04:23,240 --> 00:04:25,880
and signs in as the app when the app works on its own.

134
00:04:25,880 --> 00:04:27,920
The filing cabinet comparison helps here.

135
00:04:27,920 --> 00:04:30,520
The application registration is the blank form design.

136
00:04:30,520 --> 00:04:33,360
It lists the fields and tells you what the form is for.

137
00:04:33,360 --> 00:04:35,240
The service principle is the completed folder

138
00:04:35,240 --> 00:04:37,200
inside your company's filing cabinet.

139
00:04:37,200 --> 00:04:39,640
Your company's details sit in that folder.

140
00:04:39,640 --> 00:04:42,360
Whether the app is allowed, which permissions it received,

141
00:04:42,360 --> 00:04:43,920
and which roles it can use.

142
00:04:43,920 --> 00:04:46,440
So a vendor can create one application registration

143
00:04:46,440 --> 00:04:49,040
for its software while your company gets its own service

144
00:04:49,040 --> 00:04:50,360
principle for that software.

145
00:04:50,360 --> 00:04:52,760
Another company gets a different service principle.

146
00:04:52,760 --> 00:04:54,520
Your decision doesn't give the app access

147
00:04:54,520 --> 00:04:56,200
in every company that uses it.

148
00:04:56,200 --> 00:04:58,400
Each organization controls its own local copy.

149
00:04:58,400 --> 00:04:59,960
That's the part people often miss.

150
00:04:59,960 --> 00:05:01,960
Say an app needs to read a shared mailbox.

151
00:05:01,960 --> 00:05:04,320
In your entry directory, its service principle

152
00:05:04,320 --> 00:05:06,280
can receive permission for that task.

153
00:05:06,280 --> 00:05:09,480
Or it may need to call Microsoft Graph to read a set of data.

154
00:05:09,480 --> 00:05:11,040
Or perhaps it needs an Azure role

155
00:05:11,040 --> 00:05:13,000
that lets it read from one storage account.

156
00:05:13,000 --> 00:05:14,960
Those permissions attach to the service principle

157
00:05:14,960 --> 00:05:16,120
in your organization.

158
00:05:16,120 --> 00:05:17,760
The app registration describes the app.

159
00:05:17,760 --> 00:05:19,800
The service principle does the work locally.

160
00:05:19,800 --> 00:05:22,120
Now let's add the third name, Managed Identity.

161
00:05:22,120 --> 00:05:24,680
A Managed Identity is a special type of service

162
00:05:24,680 --> 00:05:28,720
principle created and looked after by Azure for an Azure resource.

163
00:05:28,720 --> 00:05:31,240
That resource could be a virtual machine, an app service,

164
00:05:31,240 --> 00:05:32,920
an Azure Function or a logic app.

165
00:05:32,920 --> 00:05:35,280
Instead of your team creating an app registration,

166
00:05:35,280 --> 00:05:38,160
creating a secret, storing that secret, rotating it later,

167
00:05:38,160 --> 00:05:40,680
and hoping nobody copied it into the wrong place,

168
00:05:40,680 --> 00:05:43,600
Azure handles the identity credentials behind the scenes.

169
00:05:43,600 --> 00:05:45,880
Your Azure resource still gets an identity in entry.

170
00:05:45,880 --> 00:05:47,120
It can still receive permissions.

171
00:05:47,120 --> 00:05:49,920
But your developers don't need to carry around a password for it.

172
00:05:49,920 --> 00:05:52,240
There are two common Managed Identity patterns.

173
00:05:52,240 --> 00:05:55,880
A system assigned Managed Identity belongs to one Azure resource.

174
00:05:55,880 --> 00:05:57,840
Turn it on for a logic app, for example.

175
00:05:57,840 --> 00:06:00,400
An Azure creates an identity tied to that logic app.

176
00:06:00,400 --> 00:06:03,560
Delete the logic app and Azure removes that identity with it.

177
00:06:03,560 --> 00:06:06,440
That works well when one resource needs one identity.

178
00:06:06,440 --> 00:06:09,200
A user assigned Managed Identity has its own life

179
00:06:09,200 --> 00:06:10,720
outside a single resource.

180
00:06:10,720 --> 00:06:14,120
You create it, then attach it to the Azure resources

181
00:06:14,120 --> 00:06:15,200
that need to use it.

182
00:06:15,200 --> 00:06:18,400
For example, several app services might need the same approved access.

183
00:06:18,400 --> 00:06:21,000
Rather than setting up a separate identity for each one,

184
00:06:21,000 --> 00:06:23,800
you can attach the same user assigned Managed Identity

185
00:06:23,800 --> 00:06:25,160
to those chosen services.

186
00:06:25,160 --> 00:06:26,480
The difference is simple.

187
00:06:26,480 --> 00:06:30,600
System assigned means one resource, one identity linked together.

188
00:06:30,600 --> 00:06:32,760
User assigned means one identity that you can attach

189
00:06:32,760 --> 00:06:34,600
to more than one chosen Azure resource.

190
00:06:34,600 --> 00:06:36,800
So when you hear these names keep this map in your head,

191
00:06:36,800 --> 00:06:39,480
the application registration is the app's master design.

192
00:06:39,480 --> 00:06:42,520
The service principle is its working identity inside your company.

193
00:06:42,520 --> 00:06:44,640
A Managed Identity is a service principle

194
00:06:44,640 --> 00:06:47,400
that Azure creates and looks after for an Azure resource.

195
00:06:47,400 --> 00:06:49,400
It can sound like harmless naming detail

196
00:06:49,400 --> 00:06:51,440
until an app needs a database password.

197
00:06:51,440 --> 00:06:53,440
Then these differences decide whether that password

198
00:06:53,440 --> 00:06:57,240
ends up in a code file, a pipeline setting, or nowhere at all.

199
00:06:57,240 --> 00:07:00,080
Let's follow one normal request from an Azure workload

200
00:07:00,080 --> 00:07:02,840
asking for access to the service it needs.

201
00:07:02,840 --> 00:07:05,400
What a workload identity does during a request.

202
00:07:05,400 --> 00:07:07,360
Imagine a logic app that runs every morning

203
00:07:07,360 --> 00:07:09,640
and needs a password stored in Azure Key Vault.

204
00:07:09,640 --> 00:07:11,320
That password might belong to a database,

205
00:07:11,320 --> 00:07:13,040
a partner system, or an older service

206
00:07:13,040 --> 00:07:14,320
that still needs a password.

207
00:07:14,320 --> 00:07:16,520
The logic app needs the password to do its job.

208
00:07:16,520 --> 00:07:18,360
The old way creates an awkward problem.

209
00:07:18,360 --> 00:07:21,760
You put the database password inside the logic app workflow

210
00:07:21,760 --> 00:07:23,120
or in a connection setting.

211
00:07:23,120 --> 00:07:25,280
But now the workflow needs its own secret protected.

212
00:07:25,280 --> 00:07:28,200
Someone has to create it, copy it, store it, rotate it,

213
00:07:28,200 --> 00:07:31,480
and make sure it never lands in a code repository or a screenshot.

214
00:07:31,480 --> 00:07:33,880
You end up protecting a password with another password.

215
00:07:33,880 --> 00:07:35,840
A Managed Identity changes that path.

216
00:07:35,840 --> 00:07:38,040
The logic app starts and asks Entra ID

217
00:07:38,040 --> 00:07:39,800
for a short-lived access token.

218
00:07:39,800 --> 00:07:40,960
It doesn't type a password.

219
00:07:40,960 --> 00:07:42,640
It doesn't look up a client secret.

220
00:07:42,640 --> 00:07:44,360
Azure recognizes the Managed Identity

221
00:07:44,360 --> 00:07:47,320
connected to that logic app and handles the proof behind the scenes.

222
00:07:47,320 --> 00:07:48,920
Entra ID then checks two things.

223
00:07:48,920 --> 00:07:50,480
First, it checks the identity.

224
00:07:50,480 --> 00:07:53,120
Is this request really coming from the Managed Identity

225
00:07:53,120 --> 00:07:54,760
attached to this logic app?

226
00:07:54,760 --> 00:07:57,800
Second, it checks what that identity may request.

227
00:07:57,800 --> 00:08:00,080
Has the logic app received access to Key Vault?

228
00:08:00,080 --> 00:08:02,120
If the request passes those checks,

229
00:08:02,120 --> 00:08:04,520
Entra issues an access token for Key Vault.

230
00:08:04,520 --> 00:08:06,760
Think of that token as a temporary access pass

231
00:08:06,760 --> 00:08:08,280
created for a specific destination

232
00:08:08,280 --> 00:08:10,480
rather than a general pass that opens everything.

233
00:08:10,480 --> 00:08:12,400
The logic app sends that token to Key Vault.

234
00:08:12,400 --> 00:08:15,480
Key Vault reads the token and checks its own access rules.

235
00:08:15,480 --> 00:08:16,880
It asks a narrower question.

236
00:08:16,880 --> 00:08:19,480
May this identity read this specific secret?

237
00:08:19,480 --> 00:08:22,480
If the answer is yes, Key Vault returns the secret.

238
00:08:22,480 --> 00:08:24,600
If the answer is no, Key Vault blocks the request.

239
00:08:24,600 --> 00:08:26,520
That gives us two words that sound technical,

240
00:08:26,520 --> 00:08:29,040
but are easy once you separate them.

241
00:08:29,040 --> 00:08:31,240
Authentication answers, who is this?

242
00:08:31,240 --> 00:08:32,880
In our example, Authentication proves

243
00:08:32,880 --> 00:08:34,520
that the request comes from the logic apps

244
00:08:34,520 --> 00:08:35,760
managed identity.

245
00:08:35,760 --> 00:08:37,800
Authorization answers, what may it do?

246
00:08:37,800 --> 00:08:39,840
Authorization decides whether that logic app

247
00:08:39,840 --> 00:08:42,000
may read that particular secret from Key Vault.

248
00:08:42,000 --> 00:08:44,440
Those are separate checks and they need to stay separate.

249
00:08:44,440 --> 00:08:46,720
A workload can prove its identity perfectly

250
00:08:46,720 --> 00:08:48,320
and still get denied access.

251
00:08:48,320 --> 00:08:49,080
That isn't a fault.

252
00:08:49,080 --> 00:08:50,560
It means the boundaries work.

253
00:08:50,560 --> 00:08:52,760
This is where beginners often get tripped up.

254
00:08:52,760 --> 00:08:55,640
They turn on a managed identity, see that Azure created it,

255
00:08:55,640 --> 00:08:58,240
and expect the app to reach every service immediately.

256
00:08:58,240 --> 00:09:00,200
But an identity alone doesn't grant access.

257
00:09:00,200 --> 00:09:02,400
The logic app still needs a role or permission.

258
00:09:02,400 --> 00:09:05,520
Someone must allow that identity to read the required secret,

259
00:09:05,520 --> 00:09:08,320
use the required API or reach the required resource.

260
00:09:08,320 --> 00:09:10,120
Azure creates the badge, but you still decide

261
00:09:10,120 --> 00:09:11,720
which doors that badge opens.

262
00:09:11,720 --> 00:09:13,200
Compare that with the older setup.

263
00:09:13,200 --> 00:09:14,800
You may have a connection string that contains

264
00:09:14,800 --> 00:09:17,760
a server name, database name, user name, and password.

265
00:09:17,760 --> 00:09:20,320
You may have a client secret copied into an app setting.

266
00:09:20,320 --> 00:09:21,960
You may have a certificate stored somewhere

267
00:09:21,960 --> 00:09:23,720
that a build pipeline can reach.

268
00:09:23,720 --> 00:09:25,160
You may have the same password copied

269
00:09:25,160 --> 00:09:28,120
across several config files because one app talks to another.

270
00:09:28,120 --> 00:09:31,400
Each copy becomes another place to lose control.

271
00:09:31,400 --> 00:09:34,400
Someone changes the password and an overnight job stops working.

272
00:09:34,400 --> 00:09:36,200
Someone leaves a secret in a test file

273
00:09:36,200 --> 00:09:37,720
and it reaches source control.

274
00:09:37,720 --> 00:09:40,000
Someone finds a credential in an old pipeline

275
00:09:40,000 --> 00:09:41,840
and nobody knows whether it still works.

276
00:09:41,840 --> 00:09:43,560
With a managed identity, the logic app

277
00:09:43,560 --> 00:09:45,600
asks for a token when it needs one.

278
00:09:45,600 --> 00:09:47,640
The token expires after a short time.

279
00:09:47,640 --> 00:09:49,440
The logic app doesn't need to pose as a user

280
00:09:49,440 --> 00:09:51,720
and the developer doesn't need to keep a long-lived password

281
00:09:51,720 --> 00:09:52,960
beside the workflow.

282
00:09:52,960 --> 00:09:55,520
That doesn't mean the token carries unlimited power.

283
00:09:55,520 --> 00:09:58,280
A token only helps the workload reach the service

284
00:09:58,280 --> 00:10:00,720
it was issued for, and the service still checks

285
00:10:00,720 --> 00:10:02,880
the permissions assigned to that identity.

286
00:10:02,880 --> 00:10:04,640
A temporary pass with a narrow purpose

287
00:10:04,640 --> 00:10:07,480
is very different from handing out one permanent master password.

288
00:10:07,480 --> 00:10:10,120
So the modern flow solves a very practical problem.

289
00:10:10,120 --> 00:10:12,040
Software can access the right service

290
00:10:12,040 --> 00:10:14,240
without borrowing a human account or keeping a password

291
00:10:14,240 --> 00:10:17,920
in its own files, but that same access path can become dangerous

292
00:10:17,920 --> 00:10:19,840
when the identity has too much permission

293
00:10:19,840 --> 00:10:23,440
or when someone steals the way it proves who it is.

294
00:10:23,440 --> 00:10:26,080
Why workload identities need their own security rules?

295
00:10:26,080 --> 00:10:28,360
Now, tokens are cleaner than sharing passwords,

296
00:10:28,360 --> 00:10:31,320
but a workload identity still needs serious protection.

297
00:10:31,320 --> 00:10:33,480
Think of it like a robot that works in your office.

298
00:10:33,480 --> 00:10:36,200
It can't tap a proof on a phone or type a code.

299
00:10:36,200 --> 00:10:38,760
Some workloads run all day long, calling services,

300
00:10:38,760 --> 00:10:41,440
moving files, reading data, and deploying code

301
00:10:41,440 --> 00:10:43,080
while nobody watches the screen.

302
00:10:43,080 --> 00:10:45,480
In some cases, one app has access to more systems

303
00:10:45,480 --> 00:10:47,400
than a single employee ever needs.

304
00:10:47,400 --> 00:10:49,000
That creates a different kind of risk.

305
00:10:49,000 --> 00:10:51,240
You can ask a person to approve an MFA prompt

306
00:10:51,240 --> 00:10:54,000
or use a security key, an app can't do either.

307
00:10:54,000 --> 00:10:56,880
So an attacker doesn't try to trick the app into tapping a proof.

308
00:10:56,880 --> 00:10:58,600
They look for what the app uses instead

309
00:10:58,600 --> 00:11:00,800
that might be a client secret, it might be a certificate,

310
00:11:00,800 --> 00:11:02,760
it could be a stolen token or permissions

311
00:11:02,760 --> 00:11:05,040
that were far too broad from the start.

312
00:11:05,040 --> 00:11:07,080
Picture a developer setting up a new app registration

313
00:11:07,080 --> 00:11:08,680
for a small internal tool.

314
00:11:08,680 --> 00:11:11,680
They create a client secret, paste it into a config file,

315
00:11:11,680 --> 00:11:13,800
and add the same secret to a build pipeline

316
00:11:13,800 --> 00:11:15,600
so the app can deploy automatically.

317
00:11:15,600 --> 00:11:17,840
The tool works and everyone moves on.

318
00:11:17,840 --> 00:11:19,600
Months later, that config file ends up

319
00:11:19,600 --> 00:11:21,920
in a source code repository, or someone copies

320
00:11:21,920 --> 00:11:23,960
the pipeline settings into another project.

321
00:11:23,960 --> 00:11:26,200
Anyone who gets that secret can sign in as the app,

322
00:11:26,200 --> 00:11:30,160
not as themselves, until the secret expires or an admin removes it.

323
00:11:30,160 --> 00:11:31,760
Entrassies the request as the app.

324
00:11:31,760 --> 00:11:33,280
That's why a client secret deserves

325
00:11:33,280 --> 00:11:35,040
the same care as a powerful password,

326
00:11:35,040 --> 00:11:36,920
and why it should be the last choice

327
00:11:36,920 --> 00:11:38,800
when a better sign-in method exists.

328
00:11:38,800 --> 00:11:40,960
For a workload that runs inside Azure,

329
00:11:40,960 --> 00:11:44,000
start with a managed identity when the service supports it.

330
00:11:44,000 --> 00:11:47,200
For code that runs outside Azure like a GitHub actions pipeline,

331
00:11:47,200 --> 00:11:49,520
look at workload identity federation.

332
00:11:49,520 --> 00:11:52,280
That phrase sounds complicated, but the idea is simple.

333
00:11:52,280 --> 00:11:54,400
GitHub can prove which workflow is running,

334
00:11:54,400 --> 00:11:55,960
which repository it came from,

335
00:11:55,960 --> 00:11:57,880
and under what conditions it started.

336
00:11:57,880 --> 00:12:00,120
Entrassed that proof for a defined setup,

337
00:12:00,120 --> 00:12:02,600
then issues a short-lived token to the pipeline.

338
00:12:02,600 --> 00:12:06,800
No long-lived entry secret needs to sit in GitHub waiting to be copied.

339
00:12:06,800 --> 00:12:08,280
If neither managed identity,

340
00:12:08,280 --> 00:12:10,040
no federation works for your app,

341
00:12:10,040 --> 00:12:12,880
a certificate is usually a better choice than a client secret.

342
00:12:12,880 --> 00:12:15,960
Certificates still need safe storage and planned renewal,

343
00:12:15,960 --> 00:12:19,400
but they're harder to casually copy and use than a plain-text secret.

344
00:12:19,400 --> 00:12:22,160
Client secrets still exist because some older apps need them.

345
00:12:22,160 --> 00:12:24,360
Treat them as an exception, not the default.

346
00:12:24,360 --> 00:12:25,760
The next control is permission.

347
00:12:25,760 --> 00:12:28,720
An identity should receive only what its job requires.

348
00:12:28,720 --> 00:12:30,960
If a reporting app needs one SharePoint folder,

349
00:12:30,960 --> 00:12:32,560
don't give it access to every site.

350
00:12:32,560 --> 00:12:34,760
If a workload needs one secret from Key Vault,

351
00:12:34,760 --> 00:12:36,880
don't give it permission to read every secret.

352
00:12:36,880 --> 00:12:39,360
If a pipeline deploys to one Azure resource group,

353
00:12:39,360 --> 00:12:42,120
don't hand it owner access across the whole subscription.

354
00:12:42,120 --> 00:12:43,920
Broad access feels easy during setup,

355
00:12:43,920 --> 00:12:47,320
but it also turns one stolen identity into a much larger incident.

356
00:12:47,320 --> 00:12:49,640
Microsoft Entra can apply conditional access

357
00:12:49,640 --> 00:12:51,120
to workload identities too.

358
00:12:51,120 --> 00:12:53,520
These are rules, Entra checks when it issues a token.

359
00:12:53,520 --> 00:12:55,840
For example, a policy can limit a workload

360
00:12:55,840 --> 00:12:58,440
to expected locations or respond to risk signals.

361
00:12:58,440 --> 00:13:00,200
The app won't get an MFA prompt,

362
00:13:00,200 --> 00:13:02,240
but Entra can still decide whether the conditions

363
00:13:02,240 --> 00:13:04,240
around that request look acceptable.

364
00:13:04,240 --> 00:13:05,560
Logs matter just as much.

365
00:13:05,560 --> 00:13:08,600
Review workload sign-ins, watch for repeated failures,

366
00:13:08,600 --> 00:13:10,600
access from an unexpected location,

367
00:13:10,600 --> 00:13:12,320
sudden activity at odd times,

368
00:13:12,320 --> 00:13:15,480
or an app calling services it normally never touches.

369
00:13:15,480 --> 00:13:17,520
Microsoft Entra ID protection can help surface

370
00:13:17,520 --> 00:13:19,000
risky workload activity,

371
00:13:19,000 --> 00:13:20,880
but a tool can't decide whether an old app

372
00:13:20,880 --> 00:13:22,280
still has a business purpose.

373
00:13:22,280 --> 00:13:23,680
A person needs to own that answer.

374
00:13:23,680 --> 00:13:26,160
Every workload identity needs a named owner.

375
00:13:26,160 --> 00:13:27,800
That owner should know why it exists,

376
00:13:27,800 --> 00:13:29,440
what it can access, how it signs in,

377
00:13:29,440 --> 00:13:31,320
and when somebody will review it again.

378
00:13:31,320 --> 00:13:32,360
When the app disappears,

379
00:13:32,360 --> 00:13:34,760
its identity and permissions should disappear too.

380
00:13:34,760 --> 00:13:37,880
Many companies treat app security as a one time setup task,

381
00:13:37,880 --> 00:13:40,160
create the service principle, grant access,

382
00:13:40,160 --> 00:13:42,480
confirm the app works, and forget about it.

383
00:13:42,480 --> 00:13:44,200
But old projects don't clean themselves up,

384
00:13:44,200 --> 00:13:47,160
an unused service principle can keep permissions for years.

385
00:13:47,160 --> 00:13:49,600
A forgotten certificate can remain valid.

386
00:13:49,600 --> 00:13:51,240
A former team may leave behind automation

387
00:13:51,240 --> 00:13:52,200
that nobody can explain,

388
00:13:52,200 --> 00:13:54,680
yet nobody wants to disable because something might break.

389
00:13:54,680 --> 00:13:56,080
That uncertainty is the risk,

390
00:13:56,080 --> 00:13:58,120
so you don't need to memorize every enter setting.

391
00:13:58,120 --> 00:14:00,080
You need a simple way to choose the right pattern

392
00:14:00,080 --> 00:14:03,200
then check access before a workload goes live.

393
00:14:03,200 --> 00:14:05,400
Picking the right pattern without overthinking it,

394
00:14:05,400 --> 00:14:07,960
you don't need to turn this into a big architecture project.

395
00:14:07,960 --> 00:14:10,640
Start with one question, where does the workload run?

396
00:14:10,640 --> 00:14:12,120
If it runs inside Azure,

397
00:14:12,120 --> 00:14:15,040
on a virtual machine app service, function, or logic app,

398
00:14:15,040 --> 00:14:17,160
start by checking for a managed identity.

399
00:14:17,160 --> 00:14:18,840
Turn it on, then give that identity

400
00:14:18,840 --> 00:14:21,840
the smallest role or permission the workload needs.

401
00:14:21,840 --> 00:14:24,760
A function that only reads blobs from one storage account

402
00:14:24,760 --> 00:14:26,800
should get access to that storage account,

403
00:14:26,800 --> 00:14:29,680
not every storage account in the subscription.

404
00:14:29,680 --> 00:14:32,240
A logic app that needs one key vault secret

405
00:14:32,240 --> 00:14:34,840
should receive access to that secret, not the whole vault.

406
00:14:34,840 --> 00:14:36,520
The location of the code tells you a lot.

407
00:14:36,520 --> 00:14:38,160
If the code runs outside Azure,

408
00:14:38,160 --> 00:14:40,800
perhaps in GitHub Actions or another Cloud Platform,

409
00:14:40,800 --> 00:14:42,800
look for workload identity federation.

410
00:14:42,800 --> 00:14:44,520
The outside platform proves what it is

411
00:14:44,520 --> 00:14:46,040
using its own trusted token.

412
00:14:46,040 --> 00:14:47,080
Entra checks that trust,

413
00:14:47,080 --> 00:14:49,400
then gives the workload a short-lived enter token.

414
00:14:49,400 --> 00:14:50,760
That lets a pipeline deploy

415
00:14:50,760 --> 00:14:54,200
without keeping a long-lived secret in the pipeline settings.

416
00:14:54,200 --> 00:14:56,120
The third question applies to custom apps.

417
00:14:56,120 --> 00:14:58,120
Does the app need to sign in as itself,

418
00:14:58,120 --> 00:15:00,160
work across more than one organization,

419
00:15:00,160 --> 00:15:03,000
or request app permissions for Microsoft 365,

420
00:15:03,000 --> 00:15:04,840
or another Entra protected service?

421
00:15:04,840 --> 00:15:07,240
If yes, you'll usually use an application registration

422
00:15:07,240 --> 00:15:08,560
and a service principal.

423
00:15:08,560 --> 00:15:10,480
The application registration describes the app.

424
00:15:10,480 --> 00:15:13,600
The service principal receives access inside each organization,

425
00:15:13,600 --> 00:15:14,720
where the app runs.

426
00:15:14,720 --> 00:15:16,200
When that app needs a credential,

427
00:15:16,200 --> 00:15:19,200
choose a certificate over a client secret where you can.

428
00:15:19,200 --> 00:15:21,360
A certificate still needs careful handling,

429
00:15:21,360 --> 00:15:22,680
but it gives you a stronger option

430
00:15:22,680 --> 00:15:25,800
than a plain text secret copied between people and systems.

431
00:15:25,800 --> 00:15:27,400
Think about a simple file scenario.

432
00:15:27,400 --> 00:15:30,080
Your personal work files usually begin in one drive.

433
00:15:30,080 --> 00:15:31,720
Team files usually live in SharePoint,

434
00:15:31,720 --> 00:15:33,240
that tells you where the files belong,

435
00:15:33,240 --> 00:15:35,760
but it doesn't give an app access to either place.

436
00:15:35,760 --> 00:15:38,080
The app still needs its own Entra identity.

437
00:15:38,080 --> 00:15:39,800
Then you decide whether it can read a folder,

438
00:15:39,800 --> 00:15:41,680
upload a file, or do nothing at all.

439
00:15:41,680 --> 00:15:44,520
File location and app access are separate decisions.

440
00:15:44,520 --> 00:15:46,000
Before any workload goes live,

441
00:15:46,000 --> 00:15:48,360
ask five plain questions, who owns this identity,

442
00:15:48,360 --> 00:15:50,040
what can it access, how does it sign in,

443
00:15:50,040 --> 00:15:51,560
where will someone review its logs,

444
00:15:51,560 --> 00:15:53,160
and when will its access be removed?

445
00:15:53,160 --> 00:15:54,880
Those questions work for a brand new app,

446
00:15:54,880 --> 00:15:57,360
but they also expose risk in apps already sitting

447
00:15:57,360 --> 00:15:58,280
in your directory.

448
00:15:58,280 --> 00:16:00,160
An old service principle with no owner,

449
00:16:00,160 --> 00:16:01,920
a client secret nobody remembers,

450
00:16:01,920 --> 00:16:04,200
and broad permissions nobody can explain should not stay

451
00:16:04,200 --> 00:16:05,960
invisible just because the app still exists.

452
00:16:05,960 --> 00:16:08,240
You don't need an admin deep dive to begin,

453
00:16:08,240 --> 00:16:09,520
you need an inventory,

454
00:16:09,520 --> 00:16:12,600
and a willingness to ask what each workload is doing.

455
00:16:12,600 --> 00:16:15,320
So how do you do a workload identity check?

456
00:16:15,320 --> 00:16:17,160
Start by listing all your applications,

457
00:16:17,160 --> 00:16:19,600
service principles, and managed identities,

458
00:16:19,600 --> 00:16:21,560
then attach a real owner to every single one.

459
00:16:21,560 --> 00:16:22,480
That's step one.

460
00:16:22,480 --> 00:16:24,720
Next, hunt for client secrets hiding in code,

461
00:16:24,720 --> 00:16:26,560
config files, and build pipelines.

462
00:16:26,560 --> 00:16:28,880
If an Azure workload can use a managed identity,

463
00:16:28,880 --> 00:16:31,560
move it in that direction, then review permissions,

464
00:16:31,560 --> 00:16:33,720
remove any identities nobody uses,

465
00:16:33,720 --> 00:16:35,640
and watch the sign in logs for activity

466
00:16:35,640 --> 00:16:36,880
that doesn't fit the job.

467
00:16:36,880 --> 00:16:39,880
An unattended app can still open doors across your company,

468
00:16:39,880 --> 00:16:41,120
treated with the same care,

469
00:16:41,120 --> 00:16:42,840
you'd give a highly privileged account.