 Hello folks, this video is part of a series we're doing where we take a look at Azure Lighthouse and all its benefits from a variety of different perspective. Have you thought about how you can safely provide support to a customer with their Azure subscription? How you can help them manage their environment efficiently and without using bespoke tools and processes? And all the while lightning the administrative burden that comes with managing access levels, invitations and directory listings. Well, stay tuned because today we're discussing exactly that with James Brookbank, Chief Technology Officer at RIPE. Hi James, how are you doing? Great, thank you. So James, you're a Microsoft service provider or MSPs for short. What brought you to using Lighthouse as opposed to other tools? Okay, yeah, we have been managing Azure for our customers for about six years now, since about 2015. And prior to Lighthouse we required a myriad of set of tools in order to manage different customer environments. Predominantly for our automation purposes, we needed to create our own onboarding process using Azure AD application, multi-tenanted application settings, which required us to have a full onboarding web application, which meant the customer had to log in, accept the delegation and then bring our application into their environment at which point we could then delegate access to their resources to provide automations and that sort of thing. Similarly for our own access as engineers, we were required to put guest accounts into customer tendencies, which meant that we would have to switch between customer tendencies, increasing admin overhead, time to get into the environment and actually make any valuable contributions. What Lighthouse did was flip that on its head essentially. It enabled us to onboard the customer through Lighthouse, which delegated their resources into our environment. So we now can log in with our own identities, our parallel identities which have coverage in terms of multi-factor authentication, conditional access policies, all of those sorts of things you have in an Azure AD environment. And that one through those checks and balances, we then had access to customer environments. So they were protected by the fact that we had our full security policies on our own tendencies. And that passed through to when we accessed theirs and had access to their resources. So that increased their security posture and how we interacted with their environments. But it also made it easier for us. We suddenly had a single plane of glass that we could access all customers at once basically or switch between the ones that we needed access to at any given time. And I assume that it makes life easier on both sides. So for example, I'm taking a personal example. I've been invited into a customer's tenant years ago. The persons that I used to deal with are no longer work at that company. I don't have a point of contact at that company, but somehow I'm still in their directory. So it still shows up as part of one of my potential logins. So Azure Lighthouse, that basically takes that completely away. So there's a lot less risk to forget somebody on that way. Is that correct? Yeah, for anyone without a highly comprehensive off-boarding policy for user management or an automated tool that detects these users that aren't logging in or that have been there for a while, that sort of thing. Yeah, those sorts of things can hang around for quite a while. And you're right, from your own view, you will see in the directory switcher multiple tendencies that you have access to. And, you know, you'll just go about your day and you won't even think about those anymore. They'll become just part of the scenery. So they don't come top of mind, which is an obvious security issue there, especially for the customers where you have an account in their environment. So yes, Lighthouse doesn't do that. When a subscription is delegated to the MSP, it is delegated at a behind the scenes sort of level. I can't give you the technical breakdown of how that works, but essentially, yeah, the subscription is tied to... So me, as a parallel employee, has a parallel tendency, or the MSP tendency, and I have an account in that tendency. When a subscription is delegated to me, my object ID, or a group that I belong to, is given delegated access to the customer subscription, which means I'm not part of their tendency that I don't have a guest account. I'm not an object ID in their Azure AD, so there's nothing there for them to clean up. So no, there won't be that trailing user account that gets left behind. It is also quite good for the customer because they can go to a... It's called the service provider page in the Azure portal, and it will show them all of the service providers that have access to their environment, what the delegations are, what permissions those delegations have, and they can simply remove it at any time, and then that's gone, which leads to control back for them as well. It's not often that... I'm talking extremes here. You don't have customers going and removing you that often, unless something really tragic has happened with the relationship, but that control remains with them regardless. Yeah, but it's a great thing for a customer to have because they have control. They retain control over who has access, and they can decide when to revoke that, whether or not in whatever scenario their relationship would go sour, for example. Yes, exactly. So I know you've mentioned that you've been managing environments in Azure for a long time. What about other clouds? And I don't want to go down the path of comparing clouds here, but I want to make sure that the... I want to get your view on what the experience of managing Azure Cloud versus managing other clouds, pros, cons, anything you can tell me on that would be greatly appreciated. I don't have a lot of experience with other clouds. We specialize in Azure. That's the only cloud we work in at the moment. From what I know, the concepts are similar to how I explained it earlier, which is you require either guest accounts or some kind of custom role created in the customer account that you assume as a service provider, which has, I mean, they're highly secure in the way they're implemented, but there's a little bit of, again, when you need to clean up those resources, you have to have an off-boarding process to make sure you capture all the roles that you've created that the service provider uses. Plus, from a service provider perspective, you've got to intentionally assume a role or log into a guest account into their account, again, using that previous method, where I'm going into their account as opposed to their accounts being presented to me under my login. So, yes, from what I know, that is still the same for other providers. All right. In terms of your usage of Lighthouse to manage other tenants or customers, what are the normal tasks that we normally do? What is it that you're most likely to use Azure Lighthouse for in terms of, like, take me to your day-to-day of yourself managing a customer's environment using Lighthouse? Yeah. So, primarily, it's visibility. So, we log into a customer environment and we check their resources for performance issues, security issues, availability, anything like that. So, I guess, from a BAU perspective, it would be login, check the environment, look for any anomalies, look for infrastructure services that might be either overused or running out of storage, you know, those kind of basic infrastructure-level checks. Look at any alerts that have fired. Obviously, critical alerts go to an on-call sort of service, but there are other alerts that are firing that aren't so critical, but may pose a problem in the future, so it's just keeping an eye across those. Going into things like Azure Security Center to check security alerts to see if there's anything that needs attention in there. There's, similarly, Azure Monitor looking at any logs or anything you need to look at. So, it's all that visibility sort of stuff as to sort of starting the day, making sure the environments are all up to scratch. Then there's any particular service requests. There could be anything from assisting a customer with deploying applications. So, helping them build pipelines or even just manually deploy something if it's just a one-off. Doing configuration changes, so your standard move-ad change management. So, that's, you know, resizing a VM or scaling a database or any of those manual tasks that a customer might ask us to do. And then any project work. So, any new applications that are being spun up, any proof of concepts that we're assisting with, anything that is being done inside the customer subscription is for us to access and help with. Then overriding all of that is support. So, we have a close support relationship with Microsoft that we leverage for our customers. So, any issues they have, we then can go in through Lighthouse to the help and support page and log a ticket directly on the resource. So, we don't have to use a phone line and then go through the steps of what service is it and then only after the engineer is involved that we can show them. Using it this way, you get all of the metadata of the resource that's in trouble is automatically included in the ticket because it's presented through the Azure portal. So, you're getting like simplified support of existing environments. Simplified management and overview monitoring of that same environment all within the confine of what the tenant or the customer has onboarded. So, basically, they control the amount of access that you have. Yeah. So, through the original delegation. So, we do have some customers that only want us to have read access to their environments. So, we can still do checks and things on their resources, but we can't make any changes. Others are obviously different. They allow us to have write access. Yeah. So, it really depends what the customer use cases and what they want to leverage us for in those aspects. And you find that managing that environment, for example, are you able to like set policies for them? Yeah. Yeah, certainly. Using the Azure policy framework, we can create policies. We actually use, one of the main ones we use policies for is our own tagging. So, when we roll out onboard a new customer, we use a tagging policy that basically defines what sort of service tier an object has. So, for instance, if it's a highly critical production resource, then we tag it appropriately. And that way, the alerts that get created for that go 24-7. Go to our own call team, that sort of thing. Then we have other resources that are only really business hours. So, we tag those appropriately as well. And then we use policy to track those, so that when new resources are deployed or something like that, the policy will then show us that we need to attend to those and retag them, those sorts of things. Okay. And as a service provider, are there things that you wish that Lighthouse would do better? Like, give us the real nitty-gritty here of what you think in terms of we've hit the mark on here, but we still have work to do on here. Yeah. I think predominantly right now, the biggest gap is role-based access control management. So, access to resources or resource groups in Azure controlled by roles. As a Lighthouse, as a delegated subscription through Lighthouse, we don't see the actual role-based access control list for what the customer has access to. When we come in from a Lighthouse perspective, we see what our groups and users have access to, but we can't assist the customer in setting their own access policies there. So, if a customer says, I don't have access to this resource, will we say, well, we either need to log into your tenant directly, going back to the August account sort of version, or you guys need to do it, unfortunately. Okay. So, that's probably the biggest gap at the moment. So, it's almost like a byproduct of that delegation. So, they've decided how much access you have to their environment, but that negates you being able to help them in a certain situation where you have to check how much rights they have in their own environments. It's actually a little, the system doesn't support it. The highest role you can be given as a Lighthouse delegated service provider is contributor level, which by default in Azure doesn't have the ability to change permissions. So, only an owner can change permissions on a resource, and Lighthouse delegation doesn't allow the owner role. So, it's actually, I mean, when Lighthouse was first conceived, I can see that it was probably a good thing to do, but customers want that level of management from their service providers. So, it does, yeah, there is a little bit of a gap there. Okay. You mentioned earlier that before we started recording that you had possibly a demo on policy or update management. Yeah, policies. I've got one open here, and it's the one I just mentioned before about auditing for tags. Yep. So, this is just a simple Azure policy screen. I'm currently scoped to a customer subscription, and you can see that we've got 87% of resources that are compliant with policy, and there's a few that we actually need to check out. So, just at a glance, we can see that for the subscription in particular, we're not completely compliant, so we'll need to go through and look at what resources are not tagged appropriately in here. What we will then do is once we're tagged, we have an automation that will roll and deploy alerts for resources that need the alerts to be put on them. So, that's, yeah, really quite a simple way of doing it. We can actually, I won't do it now, but if I scoped to all customers at once, which we have over 150 subscriptions, so it might take a little while to load, but we could see at a glance how many customers we actually need to just give us an idea of how much work would need to be done to go through and re-mediate all of this. So, for you as a service provider with multiple customers, this is really a really great way of seeing your entire scope of what your to-do list is going to look like, whether you're seeing all of the alerts or everything that's not compliance, but across all your customers, not just against one. What about automation? What about, like, dashboard? Is there a way that you've, is there a secret sauce that you have to, like, have a global viewer or a single pane of glass view of all of your environments? Yeah, so for each customer, we have a dashboard, primarily infrastructure-related. It's looking at CPU, memory, disk space, that kind of thing, and we generate this through an automation that we've built that leverages Lighthouse to gather all of it, so basically we can either do a single customer at a time or we can do a total customer refresh. So the script will basically go through, log into each customer environment, run through all of their resources, and pull out the ones that we want to have a look at, grab their metric data and build this whole dashboard for us. So depending on what resources they have, that's what you'll see in here. So these are single customer view at a time, but they are built through an automated process that leverages Lighthouse to do it in a really efficient way and quickly. So, yeah, if we ever need to add a new resource type or a new metric that we want to view, we just need to update the config for the script and then rerun it, and it will go and pick all of that up for each customer and regenerate the dashboards. Your dashboard, are you sharing that with each customer or is that for internal consumption? We do use it internally. We have used it to build specific customers when they've wanted this kind of information for themselves as well. So we don't hoard it for ourselves, but yeah, it's just a really, by default, the past 24 hours. So it's just a really quick way of viewing to see that there's no anomalies here, to see that, you know, that CPU hasn't gone out of control for a particular resource or something like that. Or, for instance, when there's storage usage, and you can see that it's creeping up over time and if it continues on that trend, it's going to hit 100%. So it's kind of a proactive check to make sure that we're not going to have anything fall over. One of the really powerful things about Lighthouse is that aggregated nature. I can go into Security Center, for instance, and it will actually aggregate all of my customers up into a single security score, for instance. So as a service provider, we can look and say, oh, we probably need to have a bit of a, I don't know, a task to go through and explicitly increase score for some of this. Obviously, we have our own subscriptions and we have our dev subscriptions and that sort of thing, so the score is a bit up and down, but it is really powerful to be able to see and it kind of allows you to benchmark in a way and say, look, this is industry best practice and we're above it, for instance. So across all customers, we're doing really well from that perspective. Similarly, alerts and monitoring, we can get an aggregated view of everything that's going on at once. I know that a lot of Microsoft service providers are also what we call CSPs or cloud service providers. How does Lighthouse help with a CSP or the differences or tell me about that. Okay, yeah. So CSP, obviously, Cloud Solution Provider, it is primarily a partnership between a reseller and a or CSP and a customer, primarily for Azure Usage selling Azure licensing. When you create a reseller relationship between a customer and a partner, by default, the partner gets full admin privileges to the tenancy, so that's everything. It's Azure Office 365, basically the Azure AD and everything that it's connected to. And that delegated, that delegation allows service providers to fully administer the environments. But the admin on behalf of is quite of a, it's a little bit of a back door mechanism, for one better term. Yeah. What happens as a CSP subscription has a secret, not a secret, but it's a group that's given owner access to the entire subscription that is managed by a group on the service provider side. So the visibility to the customer isn't high as such, and the service provider can go through that. So again, there's no guest accounts in the tenancy, but through that back door, you can access a customer subscription, almost without them kind of knowing. There's still, you know, activity logs and that sort of thing, so things are audited, but it's just a little bit less visible to the customer. Okay, so a little less transparent, a little bit more nebulous in terms of figuring out who's got access and when something was done, unless you have to go through all the logs and the activity logs, you wouldn't be able to just say, oh, here's the list of who's got access and so and so has access to it. Yeah, yeah. So using that as a mechanism to access, obviously it raises questions like when a customer needs to complete a security questionnaire for when they're bringing a new vendor or something like that, or a new customer of their own, they would need to explain that process and how it works. And so, yeah, just a little bit more complicated. And since we're talking about access and privileged identities and so on, so where does PIM come in in this whole thing? Like privileged identity management? Yeah. So PIM's a great addition. So it's been in Azure for a while. It's been in part of Azure AD privileged identity management for Azure AD related role elevation, I should say. So you could be a standard user in Azure AD and then if you need to do something at a global admin level, you can request and elevate your access to global admin for a period of time to do the work and then it gets revoked. So that's that whole zero trust that are just in time management. You only elevate when you need it and it comes back off automatically as opposed to being a permanent global admin. So that concept has been implemented into Lighthouse now, as we know it's in public preview. So you can now, when you do a delegation from Lighthouse, you can specify that a role is read-only, for instance, but with the ability to elevate to a contributor access for read-write. So any time of day, standard operation is just read-only access for any customer under this delegation and then you go to a process whereby you go to the PIM console choose which subscription you need to elevate to what you need to elevate to contributor, for instance, if you need to do any writing activity and then a period of time a justification for it and hit the approve button. At that point, depending on your process, it could go for approval to a management person or even potentially to the customer for approval and then once that approval happens you get elevated to that permission and you can do your work and then after a period of time that elevation gets revoked. So it's really peace of mind for the customers that protection against accidental things for one thing. We're all human so people not intentionally but may do something that's disruptive to the customer availability or the application availability. So it protects against that. It's very intentional. You have to intentionally elevate which is also audited. So it's protection on all sides really. It protects the customer primarily but it also protects the managed service provider. And I would think that I used to be a consultant and working for a service provider years ago way before the cloud was a thing but I do know that the time having any kind of mechanism to protect both the partner and the customer was was a very welcome piece of process and tooling. So now that's PIM is going to be in preview right now as you mentioned into it's going to give you the best of both worlds of the two types of customers that you have that you mentioned before. The ones that only let you read stuff and then the one that gives you contributor access to everything. Yeah, exactly. And it's a much better model these days because traditionally and you may have had this when you were consulting but a traditional model was to have two user accounts standard day-to-day work and then one for admin. So again coming back to that whole admin overhead of having multiple accounts and certainly when they're browser based you then either have to log out all the time or use a separate browser or an incognito mode or something like that. So all of those little operational problems kind of go away because now we're able to use a single identity but also have the protections that you're not always an admin you only elevate when you need it. So yeah, again it's just a far better way for everyone to work on these kind of procedures. Well, James, those are all the questions I had for you. I want to extend a very warm thank you for answering those questions and giving us your personal view and experience of using Lighthouse as a Microsoft service provider to manage your customers tenant. So again, thank you very much. No worries. Thank you.