Fireside Chat with Microsoft Azure & HashiCorp

Tune into this discussion moderated by Pushya Jataprolu, Senior Product Manager at HashiCorp with Rob Barnes, Senior Developer Advocate at HashiCorp and Jonathan Lyon, Senior Program Manager at Microsoft Azure. Rob and Jonathan will discuss practical frameworks for implementing Zero Trust Security with HashiCorp and Microsoft Azure.

Pushya Jataprolu: 

I'd like to welcome Jonathan Lyon, senior program manager in Microsoft's identity and network access engineering division and Rob Barnes, senior developer advocate at HashiCorp. We'll be talking about how HashiCorp and Microsoft are working together to make zero trust accessible leveraging identities in a multi-cloud world. Let's start at the very beginning. Zero trust is everywhere. Rob, can you help me understand what that means in practice?

Rob Barnes:

It’s a good idea to kind of set the stage with a scenario to look at how things have typically run within organizations. We can take a developer, for example, who is working remotely that needs to access some workloads within the network perimeter. Typically, they would use something like a VPN to access that network. At that point, they will be able to access any of the workloads that they are required to perform their function. That's a pattern that has been quite common across organizations, for the past couple of decades at least. And essentially what that pattern is doing is, it's trusting everything inside the perimeter.

The issue is when you get into a cloud environment. We have this thing called the shared responsibility model. So now there isn't such a rigid perimeter that you're used to governing. Essentially, some of that responsibility is going to be down to the cloud provider. In this case, it will be Microsoft Azure, and you don't have full control over how they manage that. Now it's no longer enough to authenticate your identity via VPN and have access to everything. Now, every time you want to access everything, we need to just double check whose identity it is, and make sure that that identity is authorized to access a particular system, workload, or whatever it is you're trying to access. It's just kind of more of a mindset shift from the rigid perimeters that we are used to. They no longer exist when we start moving into the cloud realms. Now we have to start looking at things from more of an identity mindset.

Pushya Jataprolu:

Thank you, that makes a lot of sense. So in this scenario, what are some of the key challenges customers have implementing zero trust security?

Rob Barnes: 

We’ll use the scenario of a developer. One of the things that I've learned throughout my career is that, in order to do a good job when it comes to security specifically, it’s heavily centered around providing a good developer experience. If you make things difficult for developers to do their jobs through the basic things that they need to do within their roles — essentially it's a barrier to adoption.

Specifically, that's the first challenge there. Secondly, I think you have to look at the developer workflows and you need to try to find ways to bring some of these processes into the things that they're already doing without adding too many additional steps. Essentially, what you want to do is — you want to reduce the complexity for the end-user, or the developers in this case. That's a really, really key point to emphasize. Their productivity is the thing that you cannot afford to disrupt. 

Jonathan Lyon: 

Just to add on to that, Rob — often with organizations, knowing where to begin is one of the more challenging parts of the zero trust model. I think a lot of people are getting the concept now. We see recent stats where 64% of CTOs are already looking at building a zero trust plan. But often it's where to actually start? I think the developer and scenario you gave is a great example because they tend to be more privileged users because of the nature of their work. Really what we need to start looking at is — we need to verify explicitly, we need to ensure that the developer is that developer. We need to ensure that the device they're using is trusted, it's healthy, it's patched. If it's a tablet or mobile device, not got a rootkit or something like that on there. And then, of course, least privileged access is crucial.

It wasn't that many years ago that if you brought a developer into your organization, you made them a domain admin or a global admin because they need to access servers and lots of resources and be able to install software. That causes a world of problems, so ensuring that the least privileged have enough to do their job, but actually making sure they don't have too many permissions.

Pushya Jataprolu: 

That's fair and you brought up a really important point there, Jonathan. That starting problem: where do you think our customers can start? Where do you recommend organizations start when implementing zero trust security. Is there a framework to follow?

Jonathan Lyon:

It’s a really good question and it isn't as complicated as it might seem. Obviously, one of the problems we have, as Rob mentioned right at the beginning, is the move away from being in an office. You know we're all working from home predominantly now because of COVID, and because of working changes.

We're no longer potentially using VPN so those bubbles, where we could contain everything is gone. What we need to do is take that complicated matrix and simplify it. The simple way to do that is using identity to start with, and Azure Active Directory, we have a policy engine called Conditional Access. That allows you to build your policies around what people can access, and how they can access it. 

As a starting point, the key point is creating an inventory of your application and workloads. Understand what your users, your developers, are accessing. Once you've got that, you can actually break it down into a “who”, “how”, “where”, and “what” scenario:

• Who are your users? Is it a developer, is it an end-user, is it a guest user from another organization? Or even, is it a workload identity, so a server to serve identity? 

• How is it accessing, is it a corporate-provided laptop, is it a mobile device? And also, what client app are they using — a browser, are they using a rich client? 

• We can then look at the where. Are they on a VPN, are they on a home network, are they in the office, are they on an unsecured wi-fi like in a coffee shop? 

• And then the key bit is that inventory, the what. What are they trying to access? 

And using those sort of four columns, you can then start shaping what users need to access. What workloads, and define that “how” and “where”, as to how they can access those or how they can't access those in certain scenarios. Based on those, you're able to build a decision on that “what”, the workload.

Pushya Jataprolu: 

That seems to make things easier to follow. Have a set of steps you can think through. That makes a lot of sense. Can you both talk about the importance of identity driven controls, in terms of zero trust security in the cloud? Let’s start with Rob.

Rob Barnes: 

Absolutely. If we go back to the original scenario — in fact, what I'll actually do is just to latch on to what Jonathan said. He set the scene very, very well talking about some of the pillars there. I think that is the kind of mindset we need to take when we're talking about identity-driven controls.

Essentially what we're talking about is service to service communication. We're talking about human-to-machine communication, we're talking about machine-to-machine communication. Essentially you're looking at things like single sign-on. So there are some pillars that we should think about every single time we're trying to implement a zero trust mindset to our systems, our infrastructure, and our applications.

Just like Jonathan says, it sounds a lot more scary than it actually is. Even if we look in the traditional kind of castle and moat approach, we were doing it already. If you look at what our firewall rules look like, it was normally via IP address. If we think about what that IP address represented in the world there, it was an identity for an application. So you'd have a virtual machine or even a bare-metal machine, it would have a specific IP address. It would have a responsibility of earning a particular application or workload. When we go on to our firewall, and we allow the IP address to communicate with something, essentially what we're saying is that identity can speak to something. So it's just getting your head around that. It's the same kind of thing, but instead of looking at things that IP addresses now, which is a lot harder to do in this cloud-native world. You know, essentially the IP addresses are a lot more dynamic and a lot less predictable, so we can't really manage a rule base or things that are forever evolving. It's important just to understand that we need new ways of assigning identity to our workloads — which is operating in a more dynamic and fast-moving pace that the cloud enables us to move in.

You want to just control what can talk to what, you want to control who can access what. And, essentially, if you have a single database that you can trust as your identity provider. Jonathan made a very good example about Azure Active Directory. This is a great example of something that you can use as a single sign-on. One of the other challenges that I tend to find — and I've run into this so many times in the past — is essentially authenticating a human (especially with things like Azure Active Directory) is very much a solved problem.  We have our identities in this database, and we can authenticate. We can use our usernames and passwords, and add extra layers of authentication like multi-factor authentication to that. But where the biggest challenge comes in is authenticating our applications.

How do we securely assign an identity to our applications if we're not going to use an IP address, which we can't use if it's dynamic? And this is one of the reasons why I really, really love working with Azure personally. Because one of the most underrated features, in my personal opinion, of Azure is a feature they have called managed identities, which is super nice. It's a way of assigning an identity to a workload, a virtual machine, whatever it is, and you can assign granular permissions to that.

With that, it means that when you're authenticated in that virtual machine to other services within Azure. That initial kind of secret zero injection piece is taken care of whereas, without something like managed identities, you need to find a way to inject some kind of identity into that. And there aren't many good secure ways of doing that so definitely something to look into. Azure managed identities is, for me, the way forward. 

Jonathan Lyon: 

And just to add to that we've recently announced that within our governance tools, within Azure Active Directory, we're now including workload identities. We can actually see which developers own those workload identities. We can ensure that they're not being used for anything else, and they're not being repurposed. Those sort of bits using access reviews, and again, that auditing process can ensure that least privilege is happening on those workload identities as well.

Pushya Jataprolu: 

That's fantastic. So now I want to hear how Microsoft Azure and HashiCorp are working together to make zero trust accessible, regardless of where the organization is in their journey to the cloud.

Rob Barnes:

I’ve been a big fan of HashiCorp for many years, long before I joined the company and started working here. I’ve also been a big fan of Azure. It was actually my entrance to the cloud world. I’ve been doing a lot of things with HashiCorp and Azure collectively. If we look at some of the integrations that have been put in place between the two of us, we can see that HashiCorp and Azure have worked really closely together to align on the way that we deal with some of these security issues; how we tackle the issues of assigning identity.

We have quite deep integrations specifically with things like HashiCorp Vault, which is one of the areas that I specialize in. I can probably talk a bit more detail about that a bit later on, but we have multiple layers of integrations with HashiCorp Vault. 

Boundary is one of the newest Open Source projects that we have, and you can now login to Boundary using your Azure Active Directory identities and the managed group feature that we have. This is super nice, it means that you can just manage all of the identities in that one place, which is going to be Azure Active Directory. You're going to be able to access HashiCorp Boundary to get access to the rest of your workloads which again, is super nice, and we have things like Terraform. It's leveraging the Microsoft Graph API for managing an Active Directory permissions structure which is again another evolution and the whole identity approach. 

Just to kind of elaborate a bit more on things like Vault, this is probably the area I have the most knowledge in and most commercial practical experience in. Essentially, the first integration I can probably talk about, which is the obvious one, is the Azure Authentication Method — AuthMethod is what we call it- in Vault. It takes the same principles of what I've described with Boundary. You can literally take the identity database that you have in Azure and you can use that to login to Vault. The reason why that's nice, is the last thing you want to do is to manage your authentication and your authorization in multiple different places. It creates a kind of an identity sprawl and it's a nightmare to manage. As you'd have to remove permissions in one place, you have to remember to replicate that in different places. Managing that centrally is a key pillar. Using Azure Active Directory as your identity provider is a great way to have a source of truth for identity. You can also do things like we have the Azure Secrets Engine. If you need to authenticate with Azure instead of giving people long-lived credentials, like service principal credentials. Essentially what Vault can do is, it can go to Azure and create a short live dynamic credential for you to access Azure. With all the permissions you need for that specific task, and it can give that to you

Now, I mentioned that it's short lived and that's because it will have a time to live associated with that credential. once that has expired, then Vault will go to Azure and say, “hey, can we revoke this credential?” That way, you don't have to worry about secrets being screwed everywhere. You don't have to worry about credentials, be elite, or anything like that. So that's a super nice feature. Then we have some other things as well, which tend to get overlooked. But we'll talk about things like auto unseal so anyone that's familiar with HashiCorp Vault in general — when you first bring up a cluster, it's in a sealed state which is to protect everything that's inside it. And in order to unseal it, you would normally enter a quorum of unsealed keys, which will open up a cluster and allow people to authenticate and interact with Vault. And that is good from a security standpoint, but from a more operational standpoint that can be a nightmare to manage, especially when you have server restarts in the middle of the night and on-call engineers have to be working up to and to unseal keys. We have a feature called auto unseal which essentially in this case, you would use Azure’s Key Vault as kind of your unsealing key and it would automatically go in and unseal that so that is super, super nice.

But it brings about the problem of, how does Vault authenticate with Azure, right? So we have that same issue I mentioned earlier on about the secure introduction of secret zero. And this is where I'll talk about managed identities again. We have support for the Azure managed identities in Vault. As long as you're running HashiCorp Vault in Azure, you can assign a managed identity to it. That will automatically authenticate with Azure and have access to the cryptographic key in Azure Key Vault and allow your cluster to automatically unseal. There's a lot of work that's happened between HashiCorp and Azure to make this seamless experience between our offerings as easy to use as possible for the end user, for the operators, and for the developers.  I think it's really, really good what we've managed to achieve together so far.

Jonathan Lyon:

It really, really is, Rob. Just to add on right now, if we look at Vault and Boundary, they support Azure Active Directory as an SSL provider today, and soon they'll be available in Azure App Gallery. You’ll be able to go into Enterprise Apps and add those to your Azure Active Directory Tenant straight from there. As soon as you've done that, whether it's Vault or Boundary, that becomes an Enterprise App within your organization.

And what that means is, you can create a conditional access rule. If we look at Boundary or Vault for that matter, they are privileged workloads, they allow you to access secrets or remote access workloads that are potentially sensitive. It may be home data or key business systems.

Once we've got the single sign on working, you can create that conditional access for where you can verify the identity. What groups are they, and what roles, what location are they in? Don't forget this isn't just human identities, it can also be workload identities. So coming back to those managed identities that Rob's quite passionate about (which I'm pleased to hear). You can actually specify potentially what regions they're in. So actually yes, I'm going to allow this managed identity to talk to your kinfolk, but only if they're both in the same region. That way, if that managed identity tries accessing something from a different region, it wouldn't be allowed in. Location isn't just necessarily about where you're physically at, it can also be used with those workload identities. 

We've also got risk with Azure Identity Protection. We can look for patterns using our machine learning models to look for risks such as lateral movement. We can look at situations where impossible travel or likely travel has happened, or even potential credential theft, where credentials are available for sale on the market that could be linked to that identity. Once we verified that user, it's about authentication, and the key thing here is authenticating with strong auth. Now typically strong auth is seen as MFA, and I'm a big advocate for MFA, especially if you were accessing something quite sensitive like Vault or Boundary. But we talked early on and Rob mentioned not interfering with the developer getting on with their job so maybe they don't want to have to get the authenticator app out and do an MFA challenge every time. There are other options, including password-less technology, where if they've got a Surface device, they could use Windows Hello. They could use a fighter to security key or biometric devices such as fingerprints to actually do the authentication and do that second verification for them. And you know if you're using something like biometrics or Windows Hello for business it doesn't interfere, because as soon as you go to access Boundary, cameras are going to look at you check who you are who you say you are, and let you in so you're verified. Once your users are verified, we can then talk about verifying the device. We can check that it's healthy, that it's been patched, that it isn't jailbroken or something like that so we can actually ensure that the device is healthy. And once we're happy with those, we can have a policy that says you're allowed to access Boundary or you're allowed to access Vault and actually provide that sort of first layer of protection into Boundary. Once you're into Boundary, you've then got the secure methods that provide to access your various workloads in Azure or any other cloud, for that matter. It's really providing that protection to get you into that secure platform like Boundary or Vault and then leaving you on.

Rob Barnes: 

Just wanted to latch on to that and just add to make sure that I'm getting the point across — when we think about how you go about implementing a zero trust mindset to your organizations. I think everything that we've said so far, it should kind of give you a common theme which is you do this by managing things centrally. If you think about your identity, you want to manage that centrally in one place right, which is why this integration with Boundary is such a key thing. The fact that you're able to just go to the Marketplace and actually add all of these things there to applications just makes life so much easier. You think about how you're generating dynamic credentials, you want to do that centrally, you want to manage your secrets centrally. You think about how we access workloads with Boundary. Well, that's again a central piece. What you want to do is, you don't want to sprawl the responsibility of all these different things across so many different places. You want to manage them centrally, which is why the integrations are such a key point of interest.

Pushya Jataprolu: 

Sounds great. Thank you so much, thank you, Jonathan and Rob for taking the time today. Really appreciate it, this has been really helpful, a lot of information there which I'm sure a lot of our customers can use. Zero trust security and how Microsoft Azure and how HashiCorp come together to help play a critical role that identity and zero trust becoming accessible. Thank you.

Jonathan Lyon:

Thank you.

Rob Barnes:

Thank you so much, it's been a pleasure.