[MUSIC].
>> Welcome to this week's episode of The DevOps Lab.
I have a very special guest with us,
Christos Matskas.
Welcome, Christos.
>> Nice to be here.
>> Good to have you here.
>> Thank you. Finally.
>> I know. We're finally back in the studio.
Very exciting episode and we're kicking off
a whole new series on identity for developers.
In this first episode, we're going to talk
about identity and why we
should care about it as
a developer and how we're going integrate into DevOps.
Christos, tell us why as
a developer I need to be concerned about identity.
>> Developer Ops, IT Admin,
everyone needs to be concerned with security because it's
such an important topic and it's hard to get. It's not exciting.
Not many people get excited about security and
unfortunately what we see
is people making the news for the wrong reasons.
We want to make sure that everyone falls in the pit of
success when it comes to building secure apps that run everywhere.
>> It's that whole thing of
shifting security left doing things early and often.
As a developer, what do I need to be thinking about?
I hear this thing called Azure AD,
I have Ops teams telling me I need it,
but they usually do it for me,
so how do we navigate that?
>> It depends on the size of the team, obviously,
because in some teams, developers do everything.
In other bigger organizations,
you have Ops teams and clear separation of concerns,
but everybody has to work together.
Shifting left is all about bringing
security earlier in the developer process,
part of the planning experience and making sure that developers
don't do silly things like putting secrets in the code,
or trying to access resources that are not secured,
or leaving storage accounts open to everyone with public access.
Then sometimes Ops will do that.
They will create a storage account and forget to
lock it down and everybody can access it.
>> I've done it.
I know we've all kind of done it.
I've left a secret in plain text file on
a server because I was doing something like
rushing and I'm going to get done and I left the secret out.
We need to get rid of that definitely and
eradicate that behavior because we know
about 95 percent of Cloud breaches are due to human error.
>> Correct.
>> And stuff like that. Plain text passwords.
>> We're making everyone's lives easier by, sorry,
we're making the bad people's lives easier by being easy.
>> We leaving them open doors.
>> Yeah.
>> Can you kick off and tell us what is Azure AD?
I think there's a few different types and I'm
always a little fuzzy on
the different types. Can you walk us through those?
>> Azure Directory is a Cloud service identity
and access management service.
If you are running on Azure,
we have Microsoft 365,
you already have an Azure Active Directory.
It can be used for securing apps like sign in, sign outs,
getting tokens for your APIs,
but from a DevOps perspective,
it can also be used to secure your CI CD pipelines.
It can be used to eliminate secrets from
your applications using a combination
of services and tools and accounts,
but it's very powerful.
The whole point here is that you cannot do
much without identity and Azure Active Directory
in place and we want to showcase
how easy it is to set it up and get started.
>> Awesome. I think there's a few different kinds.
I've used Service Principles before.
I've heard of Manage Identities.
I think I've used them, but
can you walk us through the different types,
the key pillars of Azure AD?
>> There are three key pillars.
Service Principles are your Cloud service accounts.
They allow you to build
apps that can access resources through an authenticated context.
It's an account the fact that allows you to access resources.
It's good because it enables a lot of scenarios.
Can be locked down, but at the same time,
it's a secret and a username and password.
Again, you need to be very careful about how you store them,
how you deal with them. They expire.
>> They do expire.
>> They create a whole mess when things happen like that,
so the next best thing is Managed Identity,
which is again another Azure Active Directory backed
object that allows service to service communication,
easy-peasy without having to have any credentials.
Azure Active Directory manages
the credentials and the services get a
token and validate the token
behind the scenes. Very easy to work with.
Then the third one,
which is a very new addition to the pillars,
the third one is the Workload Federated identity.
This is an option to allow
you to get an authenticated context outside of Azure
because that's the key service principals
and minus Identities work very well in Azure.
Once you extend and you need to do hybrid,
then that's where the problem starts.
That's why workload federated identity was invented.
>> Awesome. We have Service Principles which I've certainly use.
They've expired. Someone leaves
the organization and you're stuffed.
>> Correct.
>> Like to avoid those. We've had
managed identities which I've used before as well.
Then we're going to talk about Workload identity Federation.
We're going to talk a little about a lot of identity stuff,
securing apps, doing things in CI/CD pipelines,
do stuff with infrastructures code.
We're going to cover all of it.
>> Absolutely.
>> Awesome.
>> I love exciting stuff.
>> Cool. Well, everyone,
stay tuned for Episode 2 where we're going to be covering off
more identity for developers and throughout this entire series.
Tune in to learn more about identity.
[MUSIC].