[podcast] Managing Multiple Cloud Identities
Both Jeff and Jim have over a decade of experience in the Identity & Access Management space and guide companies on their IAM Program journey through Identropy's Advisory Services arm.
On this episode, Jim and Jeff talk with Morgan McNamara, a member of Identropy's crack engineering team, about a question submitted by listener Neil on approaches to manage identities across multiple cloud environments..
We hope you enjoy this episode and please subscribe to the podcast for updates on new episodes!
LISTEN HERE or read the full transcript below.
*Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.
Podcast #11 Full Transcript:
Identity At The Center #11: Managing IAM in the Hybrid Cloud
Jeff: Welcome to another episode of the identity at the Center podcasts. It has certainly been appreciated, the likes and ratings we've been getting. If you like what you hear, do us a favor. Share the show with other like-minded individuals and you can also e-mail us at email@example.com, I am Jeff, and that is Jim's voice you're about to hear. Jim.
Jim: Hey, Jeff, Survive the hurricane?
Jeff: Survived the hurricane, so far anyway.
Jim: One hundred miles in-land.
Jeff: So I guess I'm a hurricane survivor.
Jim: That’s right. We are joined today by Morgan McNamara. She's one of our crack members of our engineering team here at Identropy. Hello, Morgan.
Morgan: Hey Jeff, how's it going?
Jeff: Good. Thanks for joining us today.
Morgan: Yeah, no problem.
Jim: So, Jeff, I want to clarify by a crack member, that doesn't mean you smoke crack, right?
Jeff: That's a personal question. I don't think that's probably right for the podcast. I think as long as the work gets done. Hey, Matt, whatever could be, So today is Thursday. You know what? Today is Jim Morgan.
Take a guess. Other than, you know, podcasting,
It is the opening night of the NFL. Who? Bears Packers. My Bears actually are looking good now. So there's a chance that we might actually beat the Packers on Thursday night football open season. I'm very excited about this.
Jim: Now, seems of pride played about 100 times.
Jeff: It's relatively even though the Packers seem like they've been adopting the Bears for the last decade or so, the actual overall record is relatively close, which makes it one of the better rivalries.
Jim: Yeah. Cool.
Jeff: Morgan, do you have a team that you follow in the NFL?
Morgan: Oh, God. Out of obligation, I have to say, the Buffalo Bills, All right. Go Bills.
Jeff: My dad is one of the Bills fans, so I get you on that one. He's from your fan in Rochester area. So, yeah, the bills were his team.
Morgan: Okay. Yeah. That's like right next to me. I'm from Buffalo, so I'm. Try your hardest bills.
Jeff: Jim, do you follow a team.
Jeff: That's right, Eagles, of course. Did you see that the Eagles offensive line did the ESPN body issue?
Jeff: Yes, if that's your thing. I'm just not sure; this is the first time in twenty five years of NFL football that I'm not doing a fantasy football league.
And I gotta tell you, I find it to be quite free. I'm actually gonna be able to watch the games, enjoy them, rather than wonder, how my running backs did or are you having second thoughts around not starting one guy on the bench?
Jim: I stopped doing about 10 years ago and I feel the same way. It was like is ruining the game for me. Did the same thing with fantasy baseball where like, you know, I was just so concerned with how individual players were doing it that it was, ruining the sport for me.
And I'm sure there are a lot of people out there listening, period. But there are lot of people out there listening who play fantasy sports and love it.
And I used to love it. I'm with you, man. It's spring.
Jeff: Yeah. I just I don't know. It is just decided not to do it this year.
It's there's a certain freedom aspect to it.
Anyway, all right. Let's actually talk about Identity Access Management and get us back on track here. Today, we're going to talk about a topic that was submitted to us by Neil, who listens to the show. Certainly appreciate his email. Let me go right into what he writes. One area that I think would be pertinent to discuss is around the managing of identity and a multi-cloud environment. There is a growing movement toward vendor agnostic use of cloud services, and this drives some new thinking around how we approach identity. Do we centralize or distribute identity management? And he thinks that it good subject, which I absolutely agree with. So let’s start off with, why do companies have multi-cloud environments? Morgan, do you want to take a stab at that? And then, Jim, I'll chime in.
Morgan: On my assumption would be that, they have different platforms, different languages that they're using. And they're trying to sort of. Sequester each one of those to try and make it as secure as possible instead of integrating them all together in a single cloud instance.
Jeff: I think that makes sense.
Jim: this is a good answer.
You know, Jeff, look, what I've found is that most clients that I work with are either one of two camps.
They're either in single cloud environments and they're using something like AWS or Microsoft Azure. And those are definitely the two that I see the largest uptake on, at least the client base that we've been working with or they're in a multi cloud and they have more than one.
So they have AWS and Azure hosting, and so the ones that I find that are in that second scenario. And to be honest, I'm not an expert in the features of AWS, the features of Azure or any of the other club platforms. But from the level that I'm at the feature, there seems to be a lot of feature parody. I'm sure there are people out there pulling their hair out saying that. But, you know, for the most part, I'm finding that most clients aren't choosing AWS or Azure based on this feature or that feature, but more which company they align with better. Now, where I see the situation where a client has multiple clouds, maybe they even have multiple kinds of instances within the same provider. It's kind of been thrust upon them in that their organization, you know, grew through acquisition or merger or they purchased some software that. That was on one of the clouds and they were already on the other cloud or that some decisions were made within their organization. One part of the organization were Microsoft The other part, AWS Now they're coming together and kind of sharing to manage I.T. together. And so, in other words, they're kind of thrust into a situation. They really choose multi-cloud. It just kind of happened.
Jeff: I see. Yes. It looks like from a use case perspective, if you're and the idea that there are different parts of that business, they have different use cases kind of place. And what you just said. If you're on the SharePoint site or if you're e-mail, you're probably familiar with Azure from a cloud perspective.
But there might be someone who is more on the Google side because of the strength of the analytic side that they might be having. So they're more familiar that Mimetic got off business than Google's cloud platform, whereas, you know, developers might be looking at AWS and splitting up services there. So pulling things together is certainly part of the challenge, I think that comes along with it. But in my mind, I think it's kind of goes with that use case.
So if you're in Office 365 shop, you're on Azure, whether you like it or not, you're already using Azure from that approach.
And it becomes that question of, OK, well, we're already using here right land and expand, which is, the approach many software vendors will take is why you don’t use, Azure for the rest of your cloud services, whereas company might have, other pockets at A.W.S. And that's pretty common. I think a lot of companies try to consolidate on one. But I like the security aspects more. Morgan, you mentioned before around having things and kind of a little bit different silo where you don't have all your keys in one castle. So I think there is benefit to that as well. Using the right tool for the job rather than trying to make one service. Meet all your needs when it may not, may not be the best for the business.
Morgan: Yeah, absolutely. If I could just jump in and mentioned something interesting that I noticed you guys are discussing that was that it's almost like there's this sort of resistance and in a sense to complete migration, to cloud infrastructure, because when you think of implementation of a cloud, it's really dissolving the traditional perimeters that we've seen that have relied on things like a firewall and VPN. It's just you those just aren't as viable anymore. You’re looking at a cross-platform system where you're trying to simplify the I.T. stack.
That elimination of the perimeter is going to demand some sort of seamless implementation with a centralized user management tool. And it almost sounds like companies are kind of afraid to do that and they're trying to almost reestablish perimeters where they just tried to migrate to a fragmentation of it.
Jeff: Yeah, I think the premier's got this point. I think that's I think that's a losing effort. If you're trying establish perimeters on the cloud. Jim, what are some of the problems that you see if you're taking a multi-cloud approach?
Jim: I think, Kate, the biggest problem is the same. If you have a single cloud approach, which is, it's obviously compounded the base problem is the number of secrets or credentials that it takes to run a large cloud environment. You have secrets credentials for the console to access infrastructure within your applications. They're embedded within configuration files or embedded service accounts. So the volume of the number of credentials that you have to manage is in kind of a controlled fashion just becomes such a major effort that really the problem. And when you go to a multi-cloud now, you've compound the day of as many as twice as many secrets that you need to manage.
Jeff: Is the visibility issue, too, right?
If it's not being if the cloud is being managed centrally, some areas probably have different procedures and processes and policies for their own cloud.
AWS maybe manage a different than Azure or Google. And you may not have that visibility to know who has access to what, which is really kind of foundational for any IAM program, which would be part of the security strategy.
Jim: I mean, think of how, how much companies struggle to comply with their own policies in terms of password rotation when it comes to service accounts.
Now you're looking at a new environment that oftentimes said, a cloud environment that spun up without information security, having a hands on role.
Now, I'm talking in generalities. Right. Not every organization spun up their cloud infrastructure that way. But now you've got thousands of credentials that have to be managed and passwords that need to be rotated and compliance. And you may not have a technology solution supporting that, So I think that's really the problem. And then when you have multi-cloud, they just picked up and repeated that same kind of problem in a second place or more. Or you could be talking about an internal private cloud or how you look at it, the more places that you have to manage all these credentials. The heart of the problem becomes to manage.
Jeff: So it sounds like an answer might be some sort of centralization strategy across the club, or at least from a management standpoint.
Jim: I mean, I think this histamines question is using should we take a centralized approach or distributed approach? I'm definitely in the camp of a centralized approach. I want centralized command and control, centralized and visibility and access to wide. What they've done and I want to put together some guidelines or best practices that I can, put into effect and in terms of managing those entities within the cloud.
I've got some topics that I'd like to dive into or are kind of best practices that I think that, and kind of taking on the approach of you've got to walk before you run.
Obviously, people who are listening to these podcasts could be in different organizations that have a different point in their life cycle, that have different types of applications are coming in different clouds. So I'm going to kind of start at the most basic level in terms of the approaches that I think need to be tackled. And then we'll get into the more advanced stuff.
Jeff: All right, let's hit it. What's number one?
Jim: Ok, so starting on, from the basics, strong authentication practice, and so, starting with the assumption that you've got good practices for managing identity.
So just thinking of your employees, including the population of people who do administrative with developer functions in the cloud.
So you've got a good lifecycle management or identity governance practices for those people today, who works here, who gets access to what? And most importantly, when they leave that, you're cutting off that access. If you have that kind of centralized that, say, around your active directory, then you can plug in your access to the cloud through your corporate single sign on solution or PAM solution that I think, either one of those technologies is kind of trying to solve this problem. But what I see the most is organizations starting with managing the console, kind of the management interface for their cloud and guard putting that providing single sign on to that with their SSO solution. So like after paying or one login or something like that.
Jeff: like the system worked with that approach as well. Something like I mean PAM, CyberArk.
Jim: And a lot of those other vendors have solutions developed around Azure and AWS specifically thinking of AWS, probably the one that I see addressed the most. But I think every solution that's trying to tackle this problem should be focused on providing a solution for AWS as well its Microsoft. So there are solutions out there that would allow you to use your PAM solution, which has its own set of benefits. Those benefits are kind of more down the line of more advanced benefits than what I was planning on going through at the moment. Because what I want to talk about next was, with authentication, so we're just talking about access to the console at the moment and providing a single sign on, using your account that has good IGA practices around it that's getting disabled when you leave the organization. On top of that, I want to layer multifactor authentication because your web console is going to be available over the open Internet. And we want to make sure that we're providing a very strong authentication to log in.
Jeff: You've got MFA strong credentials. Morgan, I know you had some experience working through AWS when you're logging into AWS did you have M.F.A. enabled when you were trying to get access to the console?
Morgan: when I was setting up access to the console, I actually because I had directly signed it through AWS Web browser, I did not have to do multifactor.
Jeff: Ok, so that might be a recommendation for a former client, a former colleague, right? Lawyer yeah, really?
At this point password only isn't good enough. I think that's kind of like preaching something that we say all the time. You got to put M.F.A. everywhere as much as it can, especially on the cloud. It’s like every week there's like a new article around how someone's clock got breached. S-3 bucket wasn't configured correctly. You know, is exposed. I mean, there are just so many things that can go wrong. And I think that's what scares maybe some of the people who may be more hesitant to adopt the cloud. Going back to the point where, you know, we're going to meet earlier, but it's common. I mean, you just can't start putting, you know, racks and racks of service in your environment where you've got to do a good job of securing access to them in time authentication. And from my perspective, I look at it as you've got to know what you've got before you can protect it. So you've got to know who has access to what you've got to know with all the different counts are especially if you're working off the compounded problem, you're using multi-cloud. You have different vendors get that inventory in place. You know what the accounts are. I know what the permissions are. Start to figure out which ones are human and which ones are machine. So a lot of development takes place. So you want to make sure that you identify what's actually controlled by a person will be more programmatic. And then I would look to centralize as well. So I certainly agree with that approach. Maybe putting something in front of it like the SSO solution makes sense and then using the MFA that's part of the SSO solution to get access to the cloud environment in my mind would probably be a good first step towards that.
Jim: I mean that's what I really feel strongly about is that, from a console perspective, because I think that's where someone can inflict the most but the most damage. They can get a setting that can allow them to access to many of the instances, the server instances or the platform services through the console so they can get into the console with a very strict role or a very high level role. They could do a lot of damage. So that is kind of basic blocking and tackling and using a SSO solution MFA strong password policy and then using the other policies that make business sense.
I mean, if you don't, they shouldn't have people accessing during certain times of the day or from different IP ranges than your corporate network.
Then go ahead and put those policies in place. Anything you do to restrict access to just those folks that should be accessing that environment all the better.
Jeff: Than of these undersells have things that conditional access rights.
He can do things around Geo location, device fingerprinting, you know, that sort of thing.
Jim: That's become pretty commonplace today.
Jeff: I remember when that used to be like, wow, we're cool because, you know, we can do this and others can't.
But now it's almost a standard feature most right access management provider. So now it's kind of looking for ways to differentiate between those. I see things that like that Cash Corp, they specialize in cloud management. Deb offsets those sorts of things that might be interesting to look at. One area that I think is has a lot of potential would be more of like a just in time provisioning of access where people don't have permissions all the time. They get up just when they need them and then those permissions are pulled back or, you know, what are the rules are the entitlements that give them access. those products out there like plane I.D., you can do something through it, through an IGA tool at any governance administration tool like, potentially SailPoint or CDN or, even things like Oracle or IBM or those sorts of things. It's a lot more complicated, though, when you're trying to do it that way, because you really have to know, what the permissions are and then who's going to prove it. If it's something that's critical from a timeframe perspective, it's that approval available to it to put that in there. We see these challenges sometimes of the problems at destination site, too. Just even inside the firewall. People are getting access to servers. And there's this stigma of red tape that kind of goes around Privilege Access Management processes. That could easily happen on the cloud side, too.
Jim: Right. We’re I think privilege access management really gets you the most mileages beyond just accessing the console when you start getting into managing your server instances and managing the accounts and have access.
So one of the other tips or keys that I have is, making sure that each person who has access servers has their own set of credentials, that you're not sharing credentials over a group of people. So, for example, if you're using a Linux instance on the AWS AC2 server, those keys should be individually, provisioned per person.
So private keys should be private to the user where privilege access management system could be really advantageous when it comes to managing those instances is to allow temporary access. Person doesn't actually need to know the password to the account on their server. And then of course you could set the firewall rules on the console to only allow the IP address of the IP range that the privilege access management server exists on to actually access the server. So then you have some network access controls, additional network access controls, guarding access servers.
So some good, and that's kind of basic blocking and tackling for the enterprise.
So a lot of the best practices for managing your server environment in the enterprise move over to managing the servers in the cloud as well. Jeff, one thing you mentioned, what I would recommend for anybody who's listening to go out to their Web site, watch some of the videos that they have posted there, their tech talks with their Co-CTOs. I mean, these guys are both really bright and they really understand the space and they walk through a lot of the ways to approach. Now, their focus is primarily, I think, around managing DevOps, managing really secrets in the cloud and those secrets a lot of times. Go back to that. You're looking at this from a developer SailPoint your polishing applications outside of the cloud.
But I think that's a lot of what we're talking about today, managing a multi cloud environment. So it gives a really good vendor to bring up relative to this discussion. I think DevOps is something that you don't want to forget about.
How do you deploy apps without hard finding secrets? You look at technologies like Hash 4.
It's a way to have your applications programmatically go out and fetch your secrets rather than having to hard code them into configuration files in the same with your DevOps tools like Kubernetes does not have to hard code all those credentials into something that can be seen by multiple people within the organization.
Jeff: Yeah, that takes a lot of work out too, because if you haven't built out applications with that in mind. If more of like a legacy type approach trying to go back and reconfigure applications to use the programmatic means to pull keys from vaults of the sorts of things could take some time.
So it's definitely not something that happens from an overnight perspective. Maybe something like PlainID as well. If you're looking for more, I think they have some interesting use cases that that might be helpful for people who are looking at managing access to cloud environments.
Jim: The other thing I think you brought up a good point about, a lot of work. I don't think that IAM program manager can go in and don't be confrontational, if you will, about trying to implement security. You really have to partner with the development team.
They have to see the value in having checks and balances. They see the value in, the visibility that they can get, the manageability that they can get.
A lot of times you run into kind of a mindset that, well, there's only 10 people in the department. They've all worked here, three more, three or more years.
We trust them. The thing is, security is not about trusting people. It's about being able to not have to rely on trust is being sure that you had the security controls, everybody knows that, hey, if you try to use something, we're going to know about it.
And I think from an IAM program manager perspective where I'd look at is to try to partner with the manager applications because I think that, they're going to have to adopt this technology and more or less willingly for it to be a success. And they should look at the IAM team as a partner, somebody who can provide administration of that of these platforms and be a proper checks and balances that can allow them to focus on development and not have to focus on security as much.
So I think hopefully that helps kind of put at least our opinions around that for Neil and maybe other folks who were having similar questions. I think to sum it up right where we're fans of centralizing it. But you've got to have good policy procedure, back ending that kind of technology approach and how you'd want to manage the permissions and making sure you don't forget about humans and non-humans, that programmatic side of things, devOps, etc., getting access to the cloud. I'd like to kind of pivot back a little bit to Morgan and kind of talk a little about her background, cause I think she's got kind of interesting story where, If you remember one of our first episodes is, how people got into IAM, most of us kind of fell into it. And I think Morgan is another good example of that. Morgan has an amazing LinkedIn profile, by the way, which I will definitely link in the show notes, so kudos to you, Morgan. That definitely shows us how the writing skills are there. Maybe you can talk, Morgan, about how you get to IAM?
Morgan: I was an English major originally graduated and did some writing for online news journals.
But there was a shift to paying writers in terms of publishing where, there was no actual monetary value attached to your quote-unquote payment. So from there I kind of pivoted and went in to code. I as someone who obviously has a respect for language, I figured the language of computers might be something pretty fascinating and I was not wrong, definitely in some regards kind of being a professional student, which I loved. I started attending the local weekly meetings that we have in Austin. Through that, I met someone who is one of the board members for in a hospital application called Open EMR and that's open source and charity based. All the developer activity on that is out of people's own pockets and time through that.
The person who kind of recruited me onto the project saw how. Willing I was to learn and to kind of experiment with things, so he kind of threw me towards the AWS implementation where we migrated the patient document database to Cloud and that's really how I fell into Identity and access management.
Jeff: How long did it take to do that migration?
Morgan: I'm gonna say a couple months, maybe two months.
Jeff: And that was what, re-architecting the application? Moving data stores around?
Morgan: Yeah. My personal involvement with it was a little more spotty because I was learning and self-teaching and also working on code base infrastructure at that point as well with OpenEMR. So I was kind of being thrown around there.
Jeff: I think that's I think that's fascinating. It's such an interesting pivot to go from English major, you're writing in to technology like that.
I guess, what are some of the languages that. Well, I guess what was the first language that you learned on the I.T. side of things?
Morgan: When I first got interested in this and I say this is in coding in general. I went to Alaska and I was initially just filling a notebook as a dictionary, basically with terminology.
And I was like, OK. Does anyone have any recommendations for when I should start with? And someone said, Python. So that's actually where I started. I wish I would have started with, like, code academies command line, because by knowledge quickly became kind of Swiss cheese. And they had to go back a lot of times, kind of backtrack and fill in knowledge holes to understand really why things were happening and how they happened, but Python was first and then I moved on to html, CSS, SQL.
Jeff: Jim, I think you probably have a question or two.
Jim: Actually, one of the things I do want to close out one other last point that I wanted to make on the best practice, I think it's just around logging and make sure that you have logging centrally set up to identify problems and sending out alerting and current triggers me into another thought.
So one of the things I started off this discussion around why organizations end up at multi-cloud and I said, the cloud seems pretty comparable, so in other words, appeared on kind of the checkbox list. It doesn't have. No sequel databases have. I guess. Yes. Yes, they all operate a little bit, definitely. And most of all, some open standards and they have some proprietary connectors. And so it's probably not super easy to just pick up an application and run in both environments and expect that you can only do that a very thin level. You have to integrate in the logging solution, so many of the tiers of the applications; you have to make them specific to the cloud that you're running. That's why I think it makes it hard to consolidate clouds as well as like you can't just. Pick up all your applications and one, if you're using the platform services of cloud, you're running everything on server instances. But if you're using the logging service of the of your cloud provider, when you migrate that application from cloud , from AWS to Microsoft or vice versa, you're going to have to re-engineer that application some to work with the logging service of your new cloud. So that was just something on to throw in there as well as that, the idea of multi cloud will probably be around this for a long time because it's not just as easy as moving a bunch of server instances from one environment to the other.
Jeff: I can't believe that I totally skipped over the fact that he could have to prove everything right. So I'm glad you brought us back to that.
Jim: No problem.
Morgan: Actually, that brings to mind, identity federation and cloud trail with AWS where you have a lot of information about people who even request it in based on their IAM identities. So when you have decentralized logging, you have that single point of access to all salient logs that are created across accounts regions, which is really critical for security. But if it's fractured with a distributed database, I would think that you really lose a lot of data integrity because of the complexity introduced there. And then I would question kind of hit handling failures. You know how you distinguish site failure and link failure.
Jim: The applications across multiple clouds. So this is one of the things that I've been thinking about is that you have a cloud like if one of your goals is to distribute it in an environment distribution application. I don't feel like you'd have to have it running AWS and Microsoft. So if one goes down, the other is available because they look at AWS or Microsoft they've got data centers in around the world. So I guess, if you're really paranoid about the entire company going down, that's one thing. But, from a geographical load balancing perspective, we've got data centers in different regions of the US and throughout the world.
So my thinking is that, if you're starting out today on like let's start our migration to the cloud, you'd pick one vendor and spin up services in more than one geographical location.
You wouldn't say, let's go to two different vendors in case we lose a vendor.
Jeff: Yeah, you don't overcomplicate it, especially if you're just starting out.
Jim: I mean, if you're going to go to the cloud. I mean, it's kind of like level one is just spinning up server instances. The real benefit you get is if you get a level 2, level 3, which is to leverage the platform services for your application. So you're using a common logging platform if you're using a common no SQL database or secret database. But it says as a service. Again, those services are going to look slightly different from cloud to cloud or from vendor to vendor, and your applications aren't going to be able to point exactly the same way across multiple clouds.
Jeff: Right on. I think that's probably a good spot we can leave it for now.
I certainly appreciate the conversation. Hopefully Neil and others get some value out of what we talked about today. Morgan, appreciate you taking the time to join us. Welcome to the team. Welcome to the party.
Morgan: Yeah. Thank you for having me.
Jeff: Jim, go Bills!
Jim: Go Eagles!
Jeff: Go Bills, right Morgan?
Morgan: Go Bills!
Jeff: We're gonna leave it there. Appreciate folks taking time to listen to us. Hopefully you've got some value out of it. Feel free to like, subscribe, listen, tell your friends or share the show and we'll be talking to you on the next one.