>> Tune in to this week's episode of the DevOps Lab,
where we're doing episode 2,
and we're going to show you how to deploy
a Secretless app into Azure using Azure Key Vault.
[MUSIC]
>> Welcome to this week's episode of The DevOps Lab.
We're running with episode number 2,
and we're going to be talking about security with serverless apps.
Welcome back, Christos. Great to have you here.
>> It's great to be here.
>> Awesome.
>> Another exciting topic about security
>> I know. You're going to tell us why we need a Secretless app,
and why secrets are bad?
>> Absolutely. In the first episode,
we covered the what and how.
Now we're going to look exactly on how to do things,
but there's a line I really enjoy saying,
hackers don't break-in, they sign in.
>> I like that.
Hackers don't break in, they sign in.
>> We have done
a fantastic job in making their lives a lot easier by
committing secrets to GitHub and keys and certificates.
All they had to do is just scan GitHub or other public
repositories for information like this and then they use
it to make their way into resources.
Whether it's through a storage account is not secure,
whether it's through VM,
username, and password.
Once they get their food through the door,
then it's a lot easier for them to
break into the rest of their resources.
We want to eliminate that.
We're either too lazy or too fast to think
about the implications of
committing these things into the resource code.
>> Absolutely.
>> That's what happens over social engineering.
Obviously, that's another way to get access,
but that takes too much effort.
It's a lot easier to just scan the web to find that.
>> Find those passwords.
>> If you know your way through Google,
then you can also find web configs that could be
exposed to the world or other JSON files that could have secrets.
Trust me, there's a lot of information.
Please do not scan the Internet.
This is like public disclosure.
You could be in serious trouble,
but the information's out there if you want to do bad.
>> Yeah. A lot of companies do get
targeted and there are holes in their infrastructure;
there's holes in their code, etc.
We need to find ways to eliminate that.
>> Exactly.
>> How can we eliminate it?
How do we resolve this? What do we do as the next steps?
>> Well, the best thing to do is to eliminate secrets,
hence the Secretless apps.
But they need to live somewhere so we can live with our secrets.
You have connection strings,
you have keys to other APIs.
This is information that we need
to use to make our application run.
The best way to do that is to offload that somewhere else.
Back in the day, we used to do SQL.
We store all our secrets in SQL,
but you still have to access SQL
somehow, so there's a connection string.
What if we could eliminate everything?
That's where Key Vault and Azure Active Directory come into play.
If you are running anywhere,
you can use Azure Active Directory
and Key Vault to help you offload that.
Key Vault becomes the focal point
for storing all the sensitive information,
Azure Active Directory becomes the gatekeeper,
and your application all it needs to know is how to access
Key Vault without having to authenticate again through secrets.
>> Cool. Can you show us how to set this up?
>> Absolutely. Let's do a demo on how you can use
Azure Active Directory with Key Vault and
the Azure SDK libraries to achieve that.
Perfect. Let me switch to my screen.
Here I have an app that I have already built,
so I don't have to go through the pain of building it.
We're going to quickly navigate through the code.
This is Adobe application, by the way.
Everything I show also gets supported by
Python and Node and Go because the libraries
that we have for Azure Active Directory and
Azure Identity and the address
SDKs are available in multiple languages.
What I show here, it's also achievable in other languages.
I have a lot of underlines here because I need to do a restore.
Switching branches. That's what happens.
Anyway, so here we have two things;
one is some settings that I've put into my app settings,
but I don't want them to be accessible through code.
I'm using Key Vault at Startup to populate that.
There is a builder extension
for the configuration to add Key Vault.
You'll notice that all I need here is a credential builder,
which is part of the Azure Identity,
and a link to my Key Vault.
But there is no secret anywhere.
>> Awesome.
>> You can define how you authenticate.
There is a default Azure credential that can do a lot of things.
I will try to get secrets from the less secure to the more secure,
starting with environmental variables,
all the way to using a mass identity.
Now obviously on my local machine,
I have a mass identity, so I'm using the address CLI,
and then when I switch to a production environment,
it will use that same token credential to go through
the list of credentials and find the right one.
So I always like to be explicit as well
because I need to know
which account is used when it authenticates against Azure.
If it uses my Visual Studio or obviously a code account,
it can have a lot more privileges.
We want to eliminate that super privileged account.
>> We want to use the least amount of
privileges required to do the task
>> Because many developers will have access to
production systems and they will have contributed rights
or sometimes own their rights to an Azure subscription.
We want to get the service principle,
all the mass identity in production to do that.
Then this allows us to bootstrap the application when it starts.
Asynet does this clever thing that bootstraps everything.
It populates any environmental variable
it finds in the app settings that matches a name.
Then later on I have
another page where I want to explicitly call a secret or runtime;
not a start up, but a runtime.
I want to say go and grab my secret.
This page here, the Key Vault secrets model,
does exactly the same thing.
You will try to authenticate against my Key Vault client
using my Azure Identity credentials and then go and pull a secret.
This is not the best design.
This is mainly for demo.
Ideally, we have probably a single done for
your Key Vault client and you will be
passing it through dependency injection through your application.
But just this is a simple example.
Let's run it and see what happens. Don't run.
We have similar examples for Node and Python,
exactly the same principles.
Now it's going to use the account I have in my CLI.
Hopefully, it hasn't timed out.
If it has, we'll do an easy log-in again and
will pick it up. God, this is slow.
Now I can open the page in the browser.
The fact that he started up front means that
we are already connected to
Key Vault because he wouldn't start up, otherwise,
he would get an exception saying I can access
Key Vault or the account that you're
using does not have permission to Key Vault.
Here you can see I'm pulling on a conflict secret,
and then when I jump into my page,
which is tiny, has some secrets there.
Now I can easily go into
my Key Vault and change things in runtime.
This is what IT ops will be doing.
They will be managing the secrets for you.
You as a developer don't have to know
what the secrets are or how they work.
You can develop against a Dev environment in local,
and then when you move to production without any code changes,
you get the exact same benefits.
It can be secret.
>> We want to do this in our development
environments, our other environments.
If we have stage changes,
ie, Dev test,
pre-prod, canary environments,
we want to have this configuration for all these.
>> Exactly. I'm going to change it through a surprise name.
Let's see if you're going to guess it.
>> Is it the DevOps Lab?
>> Oh, come on.
>> Is it April is amazing?
Because that would be pretty cool.
>> There you go. Lo and behold, they happen.
Your admins will manage the secrets,
you as a developer all you have to know is
which secret do I need to consume to connect to Key Vault,
which secret do I need to connect to SQL
and therefore we eliminate secrets from our code base.
>> Awesome. That's really cool.
We know how to deploy Secretless app,
we know how to use Key Vault.
>> Yes.
>> We're good. We've taken those secrets out.
Awesome. Well, thank you,
everyone, for joining today.
We have learned how to pretty much
make our apps secretless in our code,
which will secure our apps even further.
Tune in next time as we go into more topics
about security for developers and CICD with DevOps.
[MUSIC]