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.