Loading video player...
All right.
Thank you.
Well, welcome to building secure Applications with Azure and Rust.
I'm Ronnie Garrity, I'm the Product Manager for the Azure
SDK for Rust, and I'm joined here today by Heath
Stewart, our lead engineer on the project.
And we're going to talk to you a bit about
Rust today.
So just over a year ago, our team internally made
the decision to take Rust into the fold of official
Azure SDK languages.
And we did this for a number of reasons that
I'll talk to you quickly before we get into the
demo.
But as of this February, we released the first betas
for our REST SDK.
So that includes our authentication, our identity library, as well
as libraries for Azure Key Vault, Event Hubs, Cosmos DB,
and as of last month, storage blobs.
So now like I said, I wanted to kind of
briefly explain why we decided to bring Rust into the
official Azure SDK fold.
And 1st I wanted to look at the benefits the
language brings.
So Rust's ownership in borrowing system help prevent common bugs
like buffer overflows and use after free errors that by
forcing developers to handle those at compile time rather than
waiting and hoping you find them during runtime in your
tests.
And you know, even worse if you have to find
them while it's out in production.
Rust also offers performance on par with C and C++,
combining compiling down to efficient machine code with minimal runtime
overhead.
It gives developers the control over memory allocation and execution,
allowing them to optimize for speed and predictability.
Rust also has a rich ecosystem of libraries and tools
that is growing day by day, which all enhance the
developer experience.
And the final reason is just the demand for Rust,
not just externally, but internally.
There are a large amount of teams within Microsoft that
want to build cool new tech with Rust and we
want to help support them.
And anybody else interested in using Rust with Azure?
So now a bit about how we're making the Azure
SDK for Rust Secure by design and I've only got
3 things listed here.
There are many more things we are doing, but we
only have 15 minutes.
So the first thing is in how we're handling credentials.
The Azure SDK for Rust does not persist, cache, or
reuse any security credentials.
All authentication data is zeroed after you, so you don't
have to worry about it hanging around in memory for
too long.
We also help protect against accidental data leakage.
We have a custom Safe Debug trait as opposed to
the standard Debug trait.
Our Safe Debug trait helps prevent PII from getting into
debug output and log output, so you don't have to
worry about any of that making it's way out into
the open.
And then finally, our secure Http://pipelinedesign helps us kind of
implement security policies across all communications with any Azure service
in a similar manner.
That way you can be sure that you know, no
matter what service you're talking to, you're still using the
same security policies.
And when you have to eventually go and audit or
update those security policies, you only have to do it
once, and it'll then apply to all communications for any
Azure services.
So that was just a brief kind of description about
why we took the why we brought Rust into the
official fold for the Azure SDKS.
I'm now going to hand it off to Heath, who's
going to show us a project he's been working on
that includes the Key Vault library from the Azure SDK
for us.
So take it away, Heath.
All right.
Thank you, Ronnie.
So as Ronnie said, as we released our first beta
in February and around that time, I wanted to make
sure that we had a good user experience.
We've been developing this for a while, but until you
actually write a good app with it, you never find
some of the nooks and crannies and we've gotten more
feedback since.
So one thing my family and I use is 1
password and I like their CLI I've used and some
other stuff.
I also work partly with our insys a little bit.
So I had this idea, well, what if I wrote
CLI that actually uses Key Vault?
And so that's what this, this new COI that I
created called AKV as your key vault was meant to
create.
And what we can do with it is so if
we have some environment variables like you see here, I
have X secret, we have some secret references in there.
These are key vault, UR is nothing fancy about them.
And as I go through the demo, you'll see how
we're actually able to use this to provision applications.
Not only can you actually run applications using environment variables
that contain secrets, you can actually format files as well.
So if you have a configuration file like a dot
env file you want to put into a Docker container,
you don't need to check it in with secrets because
that's, you know, bad.
And like Ronnie said, we want to be secure.
So the before we get to that.
Oops.
Is we used another product that our team actually works
on, which is the Azure developer CLI to go ahead
and provision.
I made sure to do this beforehand, you know want
to appease the demo here and make sure everything works
so everything is provisioned.
We'll get to that in a bit here.
So in order to connect to Azure Key Vault is
here.
We go the pattern here and we have the same
our, our our mantra in the Azure SDK is basically
idiomatic, but consistent.
If you look at all of our Azure SDKS across
languages, they should have a similar feel, but they should
always feel natural to the language.
Here we went ahead and chose to use functions.
I know that in Rust, there's kind of equal parts
builders and functions.
We chose kind of this constructor pattern.
So to create a secret client key Vault secrets is
you call new and you pass in your vault Uri,
which I'm getting from the CLI and a credential.
And like Ronnie said, we want to be as secure
as possible.
So with the credentials and we're, we're still figuring this
out.
Looking for feedback is when we do deploy with Azure
Developer CLI or AZD, we know that if, if it
was successful, we already have AZD credentials.
So we only use this Azure developer credential and this
is part of our Azure identity create.
If it is not deployed by Azure Developer credential, well
then we have a chain token credential, something we have
in other languages, but are considering here whether we're going
to actually ship that or not.
And so again, we're looking for feedback there.
But what this is actually doing is it is either
using the Azure Developer CLI or if it fails to
find the Azure Developer CLI are authenticated uses the Azure
CLI or AZ command.
And so you can create your own token credential.
So stepping back then.
So now that we have our client, we want to
actually get a secret from it.
And the pattern we're using here is get secret right
now, for those of you familiar with async and Ross,
we do have two awaits.
We are going to be releasing an update pretty soon
that's just going to get that down to 1 await.
The fit.
This first one is actually making the initial fetch.
And then as we're actually getting the body and deserializing
it, we may fetch more, you know, pages more blobs
from the endpoint.
And so we have the two awaits.
Now the the next thing to get into is, like
Ronnie mentioned, is we want to be as secure as
possible with the safety bug trade.
And here's a perfect example of something that anybody that
writes Russ is used to doing this.
We all love the debug trade.
It is so handy for so many things.
We print it, we trace it.
The problem is, though, is anything containing secrets or PII
is going to leak out.
So we don't want that getting into traces here.
You'll see I got a secret from it.
If we actually go into that really quick into the
definition, you'll see, sorry, having to go a few levels
deeper here than I expected that obviously we're going to
have our secret, the actual secret that the secret value.
We don't want that to end up in logs.
So if I go ahead and run this now ahead
of the buffer here.
Well, while this is running here, So what it's actually
doing is going off and it's looking for anything with
a key vault Uri in it and it's going to
mask that.
So here we go.
You see concealed by AKV.
So that's going to contain the actual secret.
But if we so let me set the environment variable
here, that's actually going to show all the trace data.
So if we scroll up a little bit.
Little like finding a needle in a haystack.
They shouldn't have actually printed that much.
No, I'm not sorry.
I'm not seeing it here.
I think.
When you.
Say your environment variable you used.
A comma might have needed to be a period.
Oh, it is actually oh, here.
Well, while this is running, we can move on.
Effectively.
We we printed the secret to it and the secret's
going to have that secret variable in there.
Or at least it should have, except that we use
the safety bug and that is going to only print
the type information.
Little myself.
There right replacing environment variable secret.
No, that was something different.
Alright, let me type.
I know it was working here.
Well, I was just working earlier, apologies.
The idea here is with the safe debug is if
you actually opt into a debug feature, so by default
it's only going to print the type, We are actually
working on a feature as well that should be in
the next beta where library developers, so all the services
that we work with can actually mark things as not
containing Pai, so we can show more.
So the way that you as a developer can actually
opt into that is to enable the debug feature of
the crates.
Oops, I passed it the wrong thing, apologies.
So this is actually enabling the bug feature.
If you know how debug works, is a, it generates
code at compile time.
And So what it's doing right now is it's actually
going through and figuring out all the different members and
what it can print.
And of course, since it's not well, I'll spring fortunate.
Which time do we have?
Not much.
All right.
So a few things that are coming up since we'll
have a few minutes left is we are actually working
on pageables.
So what we call those across the the different Azure
SDKS is whenever you fetch resources that might actually have
multiple pages.
So like say on ARM, we're actually fetching all the
subscriptions, all the resources in Keyball, for example, or fetching
all the secrets that might be across multiple pages is
we want to have the experience when you can iterate
through that idiomatically.
And Rust, you can use all your different chain iterator
functions is the pageables are going to come back with
all the different resources.
And we actually do have that enabled already.
It's just it's a little more work right now.
And so we're going to bake this into the SDK.
So the effective pattern here is that we get every
single page and then iterate through the the different values
in that page and keyboard.
For example, you can have like a page 2 with
no items in it, install the page three with a
bunch of items.
We want to flatten that experience so that no one
ever sees that that the pages may not come back
with a consistent number of secrets.
And so by the time you actually call into that
is the experience we're going to see is going to
be like any time you're iterating over anything else is
that we're going to have a reader and we're just
going to go through all the different items and print
out those for you automatically for those people that need
it.
We'll also let you go through page by page in
case you wanted to say, save a URL to fetch
a subsequent page by itself, like if you have your
own results page.
So both modes will option will actually have the long
running operations as well.
So if you ever you call an API like creating
a certificate, which can actually take minutes, even days depending
on your processes, that you can actually wait on that
output.
And that's all going to be baked into being a
future in async Rust.
So you'll just await that future and whenever it finishes,
your code will continue.
And of course, if it takes days, your code probably
not going to sit there and wait for days.
So we'll also have a way that you can say,
given some token, we want the code to actually go
back in and check periodically with a brand new process
running or a task, whatever makes sense for your use
case.
So this will all feel very similar to our other
Rust or sorry, our other Azure SDKS, but it should
feel idiomatic to Rust because everything is using the async
framework and because async and Rust allows you to define
your own async runtime.
Well, we will default to Tokyo.
We're going to let you plug your own async runtime
in as well.
We have demands for that internally in Microsoft and customers
outside of Microsoft also want to use their own async
framework.
So what we're going to allow that as well, Your
own HTTP stack, whatever makes sense there.
So be very flexible.
Oh great.
Well, thank you, Heath.
I'll just quickly switch over to this.
If you want to scan that QR code, that'll bring
you to our repository for the address key for us,
where you can take a look at our library.
So far there are ton more examples there, examples for
each service library, so go take a look and try
them out.
Thank you very much.
We'll be around if you have any questions.
Learn how the Azure SDK for Rust helps you build secure, memory-safe, and high-performance cloud applications. This session will showcase practical use cases, like managing secrets with Azure Key Vault, to demonstrate how you can create applications that are secure by default. Whether you're new to Rust or an experienced developer, this presentation offers valuable insights and examples to harness the power of Azure. To learn more, please check out these resources: * https://aka.ms/build25/plan/ADAI_DevStartPlan š¦š½š²š®šøš²šæš: * Heath Stewart š¦š²ššš¶š¼š» šš»š³š¼šæšŗš®šš¶š¼š»: This is one of many sessions from the Microsoft Build 2025 event. View even more sessions on-demand and learn about Microsoft Build at https://build.microsoft.com DEM511 | English (US) | Developer Tools & .NET #MSBuild, #DeveloperTools&.NET