Hi everyone. In this video, I want to

talk about the new Azure storage SFTP

capability that integrates with Entra

ID.

Because when I think about Azure

storage,

it's very much one of those foundational

solutions

that's used in so many places, so many

types of environment, and now I can use

it in an even more integrated way with

the idea of the SFTP

protocol. So, SSH file transfer

protocol.

And the whole goal around this is if

when I enable SFTP to talk to my storage

account as a client,

whatever that may be,

I can now just communicate using the

SFTP

protocol. I can use an SFTP client to

access, manage,

transfer

the various files.

Now, to do this, what I will require on

the storage account is actually a couple

of different things.

So, I have to have enabled the

hierarchical namespace on the storage

account. So, it's saying when we create

the storage account, we enable the

hierarchical namespace, we think about

it as the Azure Data Lake Storage Gen2.

We get true directories as part of it,

instead of hey, there's a virtual

directory, which is really just made up

as part of the file name and gets viewed

as directories.

So, I'm going to enable the hierarchical

namespace when I create the storage

account,

and then as needed, I turn on

this SFTP

capability. So, I can both enable

and I can disable it

really at will. And once I've enabled it

and it's a hierarchical namespace

storage account, then I just go and

connect to this over with the regular um

port 22,

and I'm using SFTP. So, it's going to be

really, really useful

when I have some application

that's used to talking using SFTP, and I

don't want to have to refactor, I don't

want to re-architect anything. I just

want to go and move to start using Azure

um storage for that.

So, as I talked about, hey, it's a

hierarchical namespace storage account,

and then I go and enable or disable it.

Now, there is a fee for enabling SFTP.

So, if I jump over,

we can see right here

to turn on SFTP,

you get charged, in this case for this

region, 30 cents an hour. So, it's not

something I would just go and turn on

for the fun of it. I would enable it

when I have a very specific need. If I

look at my storage account,

we can see that yes, this storage

account is hierarchical namespace. I see

enabled.

And then if I scroll down and look at my

settings,

we have SFTP.

And then once I'm within SFTP, I have

gone ahead and enabled it, which is why

you now see I have an option to disable

it. So, I can really go ahead and enable

and disable this at will.

Now, one of the challenges we faced with

this

is when it first came out, and I could

still do it, but obviously I have to

authenticate.

And the way this

one option is

is it leveraged local users.

So, at a per storage account level, I

would go and define the different users,

and I would define the very specific

ACLs they would have, and I could have

up to 50,000 of those.

And then I would authenticate as one of

those local accounts as I have an Azure

generated secret password

or an Azure generated certificate. You

couldn't bring your own.

And so, these are very long-lived

credentials that then you have to manage

separately from any existing identity

that you're used to. I think of Entra.

And they didn't adhere to any of the

regular storage permission models, so

you couldn't use role-based access

control, couldn't use attribute based

access control. This was super painful.

Imagine someone leaves. Hey, I forgot to

disable this account, they have a

backdoor to access the storage account.

When someone onboards, I have to go and

create the account. If I want a partner

to be able to use it, I have to go and

create an account. If I want to audit

it,

well, it's not part of my regular Entra

sign-in logs. I can't track it very

well.

And then if you start thinking about

what organizations really want to do

today, which is MFA, which is passkeys,

which is conditional access, I can't do

anything with these per storage account

local users. It's really not a good

solution.

And so, as you would expect, the

solution now

is I do have the ability, if we think

about our Entra tenant

that is trusted by the subscription,

well, I can now leverage those. So, the

users, for example in here,

I now just at a regular way was I get

granted

roles on the storage account. So, they

use those data plane roles that we have.

Um storage blob data contributor, for

example. I just grant them at the

various levels, and they'll be

respected. I can also use the attribute

based access control. So, it's not

separate sets of accounts, it's not

separate special ACLs. It's now going to

use the identities I have, it's going to

use the existing data plane permissions

model we have. And if this was an

external account, think a partner,

that's going to work as well.

Now, a challenge though is I'm connected

by an SFTP client. Uh could be the one

that's built into Windows, it could be

PuTTY.

They don't understand Entra ID.

So, what's going to happen is the way

we're actually going to authenticate

is using

OpenSSH tokens.

Um Entra already supports those as an

authentication method.

And so, what's going to happen is your

application or process,

it will authenticate to Entra,

and then generate an OpenSSH token.

Think Think about it as a certificate,

which I'll download and use as part of

the authentication.

Now, at time of recording, this is a

preview feature. So, in my subscription,

when you have preview features,

I would have had to have enabled SFTP

Entra ID support. You're going to have

to go and do that.

Now, I could generate my own

certificate. Remember, a certificate is

a private key part that stays with you,

you never share, and a public key part.

I can use the SSH keygen, and it has to

be the RSA to go and create it, but I

don't have to do that.

The AZ CLI, for example, with the

PowerShell modules which enable me to do

this, will go and create the certs as

well for you. So, what I want to do is

walk through just showing you this in

action.

So, if I really quickly open up my

terminal,

and we'll jump over to it.

I'm actually switching back to dark

mode, or you won't see the commands

properly.

So, I'm going to use the AZ CLI. I'm in

PowerShell, but if we look at my AZ

version,

I'm just running 2.85, so at the time of

recording, that's the latest one.

I've already authenticated, but before I

show you that, there is an extension I

need today for SFTP.

So, if I do AZ extension show,

you can see I do have that extension

installed as well. So, you would have to

use the AZ extension add {dash} {dash}

name SFTP to get this installed in your

environment.

Now, because I've already authenticated,

the next thing I have to do is just go

ahead

and create this OpenSSH token

to connect to Azure.

And I can do it all in one command. So,

if I do the AZ SFTP

cert file. Now, I'm in PowerShell, so my

um path structure with the

slashes is a little bit different,

depending on if you're CLI or Linux or

whatever, but this will just put it in

my local folder.

So, I'll go ahead and just run that, and

it's completed.

And if I now look,

was it actually created three files?

So, what I have here

is the public key, the private key for

my regular cert,

and then

the OpenSSH cert, so the token I'm

actually going to use as part of PuTTY.

Now, if you already had a certificate

you wanted to use, I could have just

added that as part of the cert command,

and it would have just been a {dash}

{dash} public key file and the public

key file I wanted. So, it would have

been super easy.

I can actually go and look at what it

created. So, if I use Again, I'm in

Windows, but

you should be able to

use this on whatever.

I can go and look at my OpenSSH token,

and you can see the principal

down here, and it's only the first part.

I don't use the part after the @ sign

when I actually go and authenticate

using this certificate.

So, it's just the first part before the

domain name.

And then, I'm just going to

use this token through my SFTP client.

Now, obviously when we we actually go

and focus on this and use it,

I have to have a path.

So, for my client, I have to have a

network path to the storage account. So,

if there's a private endpoint it's

exposed on, I have to be on a network

that has an IP route and a DNS

resolution

to resolve to the private endpoint and

then talk to it.

If it's on the public network, well,

then I have to have opened up

the storage account's firewall to allow

my public-facing IP address to be

allowed to talk to it. So, they're all

things I would have had to have done.

But, with all that done,

now, if we jump back over to my terminal

again,

we can actually go ahead and connect.

So, what I'm going to do here

is I'm using the SFTP command.

I'm telling it details about the key

type I'm connecting to.

I'm telling it the certificate file.

So, that's that OpenSSH the public key

part.

And then, it's the name of the storage

account

.

my

authentication, my username, but

remember it doesn't have

the suffix part, the @savilltech.net.

And then, the rest of the command is

just

the storage account

DNS name. So, that's it.

So, I'm passing in

that OpenSSH. I'm going to say

yes.

And I'm now connected.

So, if I look around,

I can see there's an images folder.

Let's go and look in the images folder.

See what's in there.

Uh let's get the dog

cartoon.png

file.

And we'll exit.

And then,

we'll look at it.

And sure enough, I generate this quickly

this morning. This is the dog cartoon of

me and my four dogs lay lounging around.

My smile wasn't really that big. I don't

normally look like the Joker. But, you

can see there there's me interacting

um pretty easily

um with SFTP using

just a regular client.

It I can access any of the tiers, so

hot, cool, cold. It will write using the

default tier. That's a really important

though.

The cert I'm generating here is valid

for 65 minutes. And this is by design.

So, this is a 65-minute

lifetime.

Now, if I'm doing a write and it

expires, the existing write would

continue, but I'm going to implement

logic in my app to recheck

and get a new OpenSSH token

as it's expiring. And this is a very

familiar pattern. We use an access

token, they're normally short-lived to

around an hour. So, it's following that

same idea. So, this was compromised in

some way, it's very, very short-lived.

And most interactions when I think of

SFTP are short-lived, it's a burst of

activity. So, it's not really going to

be an issue. And then, the key point

here is, so I have authenticated, I've

got this OpenSSH token as my identity,

and then it's just the regular

data plane. Remember, it's a data plane

permission on the storage account that

now takes effect. So, if I was to go and

look

at my storage account, notice I've added

no local users here, but you saw me

access it. And to prove I'm not tricking

you, if I look at the container,

you'll see it's the same files that you

saw.

But, if I go and look at the access

control

and look at my role assignments,

what you'll see I added was a data plane

set of permissions.

So, I added

storage blob data contributor. And

that's the important part.

So, that's at the data plane, not the

control plane. So, that lets me actually

go ahead and interact

with the actual blobs within the storage

account. That's the critical part of

making that successful.

And those local users,

they will get phased out over time.

Like, there really isn't a good reason

to keep those. So, eventually, it's

still there today, you get a choice. I

can disable local users at the storage

account level, but they're going to get

phased out over time in in favor of

this. Remember, this doesn't have to be

a user.

In the documentation, it also talks

about how I would use a service

principal for this. So, there's other um

types of identity I can leverage.

And that's it. I mean, there you have

it. A really nice simplified way for

your applications that are used to using

SFTP to now work with Azure storage

without having to refactoring, without

dealing with another type of credential.

And I as an organization now just use my

existing mechanisms of identity

provisioning, of monitoring activity. I

get all the lovely stuff about Azure AD

governance and life cycle and

conditional access and uh risk, all of

those capabilities, the full

observability, uh I now just get. So, it

makes this a really nice a fitting

solution. Hope that's useful. Uh till

next video, take care.