What Is Modern Privileged Access Management?
What Is Modern Privileged Access Management (PAM)? - overview
Learn how to rapidly on-board and off-board engineers to all of your resources, track behavior on an organization-wide level with K8, Applications, Databases, Windows, and SSH.
Watch this webinar to learn how a modern PAM solution can help:
- Integrate with the native tools engineers love
- Support infrastructure-as-code management patterns
- Promote best practices for passwordless authentication
- Provide audit logging, JIT provisioning, threat detection
Key topics on What Is Modern Privileged Access Management (PAM)?
- User look for certain features, ease of use, and maintainability in a PAM solution.
- A modern PAM solution should have the following capabilities: just-in-time escalation, audit capability, session recordings, per-session MFA, moderation of sessions, Linux and Windows, K8s management and database access. Teleport meets all those requirements.
- There are four essential elements of infrastructure access: connectivity, authentication, authorization, audit.
- While existing solutions force tradeoffs, Teleport Access Platform does not.
Expanding your knowledge on What Is Modern Privileged Access Management (PAM)?
- Modern PAM
- Teleport Server Access
- Teleport Application Access
- Teleport Kubernetes Access Guide
- Teleport Database Access
- Teleport Connect
- Teleport Machine ID
Learn more about What Is Modern Privileged Access Management (PAM)?
Introduction - What Is Modern Privileged Access Management (PAM)?
(The transcript of the session)
Host: 00:00:02.307 Hello and thank you for joining our webinar today. Before we get started, a couple of logistics. This session will be recorded and we will share the recording with everyone that has registered. Also, if you have any questions throughout the presentation, please submit them in the Q&A section, and we will get to those at the end of the presentation. And now I'm going to hand it off to Scott.
What do users look for in a PAM solution?
Scott: 00:00:27.409 Awesome. Thank you, everybody, for joining. Let me just share screen and move some things out of the way. So way we'll do it is we'll break it down. Unfortunately, we do got to go through some slides. So obviously probably not the thing everybody wants to see or came to see, but we will then go into some architecture of Teleport and then into a demo at the end followed by some Q&A. So be sure to use that Q&A section to submit some cool questions for me at the end. So why are we really here today? Well, I guess I should introduce myself first. So my name is Scott Gallagher. I'm a solutions engineer here at Teleport. And really my job on the presale side is to do demos and talk tech with folks like yourself about Teleport and how it can be utilized within your organization. So going back then, why are we here today? So we're here to kind of discuss what is a modern privilege access management system, more widely known as PAM. And then kind of where do we want to start is what do users look for when they're actually looking for this PAM solution. First, they have a certain feature set that they actually want to be able to implement or utilize based off of that solution. And then second, they really want the ease of use. They want it to be easy to not only use for their end users, but then hit into that last part — is the maintainability of the admins that have to maintain the solution for those users. And then if we look to the other side is — what should a modern PAM solution have.
What should a modern PAM solution have?
Scott: 00:01:57.988 So here's quite a bit of bullets. I won't go through them all, but I'll just kind of hit on some of the high-level ones or the most important ones kind of like Just-in-Time escalation. So if you think of that Zero Trust model, we give people kind of that least amount of privileges that they need, and then they can request those privileges, those higher-level privileges through escalation methods. And then also kind of piggybacking on that one is also that dual authorization of privileges. So having more than one person having to approve someone getting, say, access to high-level production systems or database backends, and then also being able to audit all of that with not only regular audit logs of what users were doing, what systems they were interacting with, but those session recordings as well, and then also being able to moderate those sessions as well. So think of having another set of eyes when someone is connecting to an SSH system or a Kubernetes cluster and they're manipulating that system, having kind of two sets of eyes on that as they're doing that. And then also for that PAM solution too, we won't be able to tie into things — not only Linux, but we want Windows as well. So we want that kind of both sides of that ecosystem when it comes to those environments and things like Kubernetes management as well, and as well as databases. And you'll see, I put it kind of on the right side. Teleport will check kind of all those boxes from that last one.
What is Teleport’s approach?
Scott: 00:03:25.452 So when you're looking at us, we can do kind of all those things, and we'll see some of those things in the demo as well. But really, what's our approach here at Teleport? Really, we want that — first off, that ease of use. We want the solution to be easy to use. And also if we look back at that slide from two slides ago, we want that maintainability. So we want it to be easy to be maintained by the folks from your team that are actually implementing our solution. Second, we want to integrate it with those native tools that developers and end users are using. So think of if I'm accessing databases, I want to continue to use that same method that I was using before, whether it be through a CLI-based approach or kind of an application to connect to my databases. And the same thing with SSH and Kubernetes, using those same tools that I use today, I want my users to be able to continue to use them to access those systems. And again, we kind of talked about it on the last one, but those kind of Just-in-Time integrations are what we call access requests. We want to be able to tie them into systems that we live in each day, whether they be things like Slack or Jira. So as users make those escalation requests, we want them to show up in there for visibility from both ends. As the user, as I make my request, I want to see when it's approved. And as an approver, I want to be able to see when those requests come in so I know that I need to go and take action on them.
Scott: 00:04:49.874 And then one of the big things that kind of puts Teleport in a kind of differentiation spot is kind of we go passwordless. We're not checking in and out credentials and sharing them with others. We're basing everything off short-lived certificates that have an expiration date attached to them. And then we also want to be able to support for multi-environment. So multi-environment, think of today our systems are probably living in that multi-environment situation where we have systems in the cloud, we have systems on-prem. Multi-cloud as well fits into there. So that's really where we want to take that Teleport approach to, to those things. And that kind of brings us then to kind of our famous tagline, Teleport is the easiest and most secure way to access all your infrastructure. We really call this the Teleport Access Platform. And what I mean by that is being able to — as we see on the screen here, is this kind of five protocols that we can support by giving users access to these systems by tying them into Teleport. Things like SSH servers in Windows, but also databases, applications, and our Kubernetes as well. And then if we look at kind of those, when we start looking for a solution as well, there's kind of those four areas we want to check boxes on. We don't want to kind of have to pick and choose that, oh, we need connectivity and we need authorization. Well, no, you really want them all at the end of the day. So you really want as we step through this from left to right — it's kind of that connectivity.
Essential elements of infrastructure access
Scott: 00:06:23.663 So we want users in this kind of post-COVID, or I guess we're still in the COVID kind of, way is we're not going to an office where we have that kind of home run back to everything. We want that connectivity to be, no matter where our end users are anywhere in the world. And then we want that authentication piece. So we want to be able to tie into that existing authentication so users log in one time and then based on their authorization piece, gives them access to those systems that our RBAC can tie into. And then lastly, we want to be able to audit all that. So we want to be able to, like I mentioned earlier, not only be able to see when users logged in, what systems they access, maybe even what commands they ran, we also want to get kind of session recordings so we can actually go back and view what did Scott do when he was in that database at this particular time. And then if we kind of look at taking a step back and look at those existing solutions and the kind of the trade-offs that they kind of give or provide — is if we look at things like the perimeter securities, think of these as those VPNs. Again, we want to be able to check all the boxes, not just kind of one of them. So they really focus just on that connectivity piece, getting users connected. But once a user is connected to, say, a VPN, there's no real fine-grained RBAC or controls in place of what those users have access to.
Scott: 00:07:50.550 And then that auditing piece as well kind of doesn't exist. And then if we kind of go to that shared credentials model as well, where users are checking in and out, those credentials, that's really a focus on that authentication piece. But then we leave out that connectivity or that RBAC and that audit piece that we kind of saw in that last slide where we kind of want to check all four of those pieces, maybe not just one of them. And then if you kind of look at the kind of legacy PAM solutions out there too, yeah, it's IT-approved, but it's probably going to have an impact on productivity. And then most of them out there aren't that cloud-native where you're getting that multi-environment, you're just kind of focusing in on your kind of data centers and things like that. And that kind of brings us then to that: what is the Teleport Access Platform? So it really is that zero trust model, giving users kind of those low-level permissions that they need just to kind of get by on day-to-day, and having them escalate as they need. And again, we're fully certificate-based using those short-lived certificates that have a time to live or TTL on them. So as users go about their workday, we can have them re-authenticate. So if you think of a laptop gets stolen from a user or something, there's going to be a time to live on that certificate instead of that credentials always kind of being there. And then those access workflows, again, tying into escalation requests and things like that. And then again that complete visibility using that audit feature, being able to see what users were doing as well as tying into the kind of session recordings.
Scott: 00:09:25.590 And then just to kind of go through some of those pieces as well, again before we get into that architecture piece, is really having Teleport being able to tie into your existing SSO provider where you can manage those permissions of users and obviously what roles then they get using the Teleport RBAC. And then again, kind of just to cap it off, is that kind of complete session user you can kind of see in the little video recording on the side. Not only being able to see those audit logs which are fully JSON and easily exportable then or shippable off to kind of your SIM of choice, but also getting that session recording as you kind of see in the video. There's an SSH piece that rolls up, and we'll see that in the demo as well. And then lastly, those access requests. Again, just to highlight, being able to tie them into those ChatOps features, whether they be Slack, PagerDuty, or you can use a program or API to manage those as well. And then kind of lastly, before we jump into the demo, is just to highlight that we are fully open source. You can go to our GitHub page and see all the code that's being developed. You can even run it kind of on your own. Obviously, there's going to be some enterprise features that we want you to buy for this. But that's kind of the highlight of the last one is being able to wear full transparency on everything that we're doing behind the scenes. And with that, we can dive into the demo, so let me stop sharing that screen.
How Teleport works
Scott: 00:10:56.861 And I'm actually going to give you a little bit of an architecture thing. Oh, boy. My iPad is not liking me there. Hold on one second. Let me try this one more time. If not, we can go to a slide of this one. If this is the only bad thing that happens to me throughout the whole demo, I'll be happy. All right. Cool. So what I like to do with kind of the architecture of Teleport, obviously, we do have a cloud offering where we manage all of the Teleport pieces that we see in purple here for you. But most users really want kind of that security or peace of mind to deploy it on their own and scale it as needed. And what I like to do is kind of just walk through how does the user interact with Teleport, and then it kind of draws out what are the various pieces of Teleport, and then what are their kind of functions within there. But everything really starts with this user. Again, I have developer highlighted here, but any user that you want to grant access to, any of these protocols that we see here on the right. And you interact with Teleport in kind of two different ways. Again, using existing tooling that we want users to be able to do, whether that be through a web browser or through our tsh client, which is our CLI-based approach, you're going to log into that Teleport proxy server. So really, as we can see in that kind of purple outline box, the Teleport proxy is the piece that sits out there that's exposed, and then everything behind it can be put in that kind of private zone.
Scott: 00:12:30.006 And from there, the Teleport proxy is going to talk to that, our Teleport auth server piece. And it has two main functions. So first, it's that certificate authority. So it's in charge of issuing their short-lived certificates, not only for the SSH servers or Windows servers that we have attached to Teleport but also for that user that's interacting with Teleport. And then secondly, as I kind of probably hit on a couple of times during the slides, it's that audit log piece as well. So being able to see what users did when they logged in, what systems they interacted with, what commands they ran, but as well as getting those tests and recordings on those pieces as well. And then we also — like I highlighted too, as well as being able to tie into your existing identity manager. And really anything that's OIDC or SAML-based — and I apologize if I have horrible handwriting — we can tie into those existing ones. So you think of the Auth0 or Azure AD, those kind of systems can tie into there. And from there, what we do is we kind of do a one-to-one mapping of we identify what roles we want to assign to users based on what we've set in Teleport and we do that within then our identity provider. And then when that all links up, what we'll see in the demo is you'll see all the systems that then my roles that were granted from identity provider afford me access to the systems. And once all this then happens, obviously we come back full circle and that users issued that certificate.
Scott: 00:14:00.720 Again, that short-lived certificate that has a time to live or TTL on it. That TTL can be fully customized to whatever you want. So if you want to give users kind of that 8 hours once they log in, they don't need to worry about re-authenticating until that 8 hours is up. Or you could set it lower for, say, there's Just-in-Time access request where maybe we only want a user to have that elevated privilege for a shorter little period of time, say, an hour or so. And then lastly is then tying into those chat apps features for those access requests. So think of those things that we sit in on a day-to-day basis. So here at Teleport we use Slack. So if I have users that I need to approve access requests for, I want to be able to see them kind of in a more timely fashion than sitting in a web UI and having to worry about refreshing or someone pinging me to do that. So that's kind of the Teleport architecture piece. So what we'll do now is stop sharing and we'll share one last time. This one should work because it worked earlier. And we'll go ahead and keep that one up because I've one more slide to show you guys. So I will go ahead and log in to Teleport here. So we can see at the beginning, we can see that I have my single sign-on provider, in this case, Auth0. And what we will do then is we kind of just went through that architecture workflow of talking that Teleport proxy as we logged in, talking about our server which talks to our SSO provider which gets our roles and our short-lived certificate.
Demo time
Scott: 00:15:35.453 And from here, what I can see is if I say: Go ahead and inspect my user, here, I can see the roles then that my SSO provider linked up with Teleport itself. And we can go ahead and look at one of these roles, for example. So I kind of got to focus on SSH today just for time's sake. So all of our roles are YAML-based so we can see things like what Linux users can my user log into the systems with. We can pull metadata over as well. So in this case, what I'm doing is I'm pulling over my username and stripping away the email part so we can do things like actual true PAM on Linux system. So we can create users and their home directories on the fly as well. And then everything within Teleport is label-based. So labels are how you control and assign what people can see and access when they log in. So for this case, I'm just wildcarding it, but I have a user later that I show that has just kind of a key-value pair of env:dev. So anything that gets tagged env:dev, that user has permission to see within the system and access. And then lastly, everything again ties back to that short-lived certificate of assigning a kind of a TTL to those users as well. So if we can't look and just quickly glance through some of these, I can see as this user I have access to quite a bit here.
Scott: 00:17:05.337 And just to make sure we're good on time. So I'll kind of cover SSH, and then as questions if kind of Q&A rolls up to anything else and we have time, I'll kind of dive into them. But it's kind of going to be the same. So within the UI or kind of the CLI, we're going to be able to see what systems does my user have access to based on the roles that my user has, how are those systems connected back to Teleport. So, for example, here we can see majority of them are tunneled. So what that means is we can do a reverse tunnel and we can kind of eliminate that security plan of exposing Port 22 or having to whitelist certain things on that back end. And then, again, everything within Teleport is label-based. So we can do things like static labels within the configuration file that live on these hosts. We can do things like for SSH if you're living within AWS or Azure, we can actually sync the tags that are within those environments down into Teleport as well. Again, giving you more flexibility to tie into that role-based access into that key-value pair when you assign things. And we can also run kind of commands as well. So, for example, I'm just running commands on some of my notes here to go and say, Hey, what's the Teleport version that's installed? So it gives me kind of quick visibility into, okay, Teleport just released version X.
Scott: 00:18:31.395 Now I know which systems I need to go target and kind of update. And from the UI here, then I can kind of go and I can log in as one of these systems, and then I can kind of do those kind of typical commands that I would do on a system. And we can kind of get each top to be able to show, we can do that full-color code so even though we're diving through a UI kind of based system to SSH or connect to these nodes, we can still get that kind of full-color code. We're not kind of kicking you back to black and white land on everything. I can issue any kind of commands as well if in here. And I'll leave this session open so we can show that we can actually join sessions as well. And I'll connect to another one here and just run some commands to show that kind of session recording that we can get. So again, if I just run some of those commands that I ran before. And then when I exit my session back within the UI, then first I guess we'll touch on the audit log. So again, we can see all the commands that I've ran. And what's unique about what we do too as well, not only do we see — we can see the user commands that were run. And even though we're granting everyone, say, a common username to log in to the system, Ubuntu, EC2 user or whatever it may be, we still — because we're tying into that your single sign-on provider — we're tying everything back to your user identity.
Scott: 00:19:55.342 So the days of having to go and share, say, an Ubuntu user, for example, say 10 people have access to it, now someone went in and rm -rf’ed, removed one of my configuration files or directory that's important, we can go back and kind of tie that back to a user and then kind of do a root cause analysis to figure out what happened within that. And then also, like I said, I have — exit that one session — I also have some Windows ones we can look at too, but we can actually play these back as well. So we can see those kind of commands that I ran there. And then what's unique about our session recordings as well is we can actually copy out of these as well. So think of the example of we have a user who went and maybe set up some kind of application or database installation on here. We can then go back and use the recording to copy and paste to put together documentation. Or the example I just kind of mentioned, do a root cause analysis of maybe an incident that happened when somebody broke something. And then we can also do things like active sessions as well. So we can see when users are within sessions. I can see users that are logged in, what node they're logged into. And we can actually join these sessions as well. So maybe I just want to go in and see what Scott's doing on this system. I got a little wonky there. But you can see as we type or as that user types, I can watch what they're doing. I can also kind of if I see they're going down a path that I don't want them to be too, we can actually terminate that session for them as well.
Scott: 00:21:31.986 And again, I kind of mentioned during the slides as well that we can do things like within Teleport 9 we can do moderated sessions. So when a user joins a session, they need to wait until they get another set where multiple people, sets of eyes kind of on that. Let's see, what else can we look out to So same thing with kind of desktops as well. If I look at kind of that Windows model the same way, I can say what users log in, and we get that full Windows desktop. And we have that kind of clipboard sharing as well as desktop recording going on, and we can actually control that through RBAC. So if you want to disable clipboard sharing, you don't want people copying out potential sensitive or any kind of data outside of that Windows box or something else, we can turn that off. And the same with recordings as well. If you don't want to record those, we can control those through that RBAC session as well. So if I disconnect again and kind of go back to activity and session recordings, we can see that Windows recording there as well. Really, I didn't do anything in there, but we can get that full end-to-end recording and visibility into what users are doing. And then lastly, what I want to show, then we can get to Q&A is if I log in, say, with this user — let me just grab his one-time password. Let's make sure I type this right because I didn't type it right yesterday during a demo. And success.
Scott: 00:23:01.480 All right. So we can see right off the bat this user has access to not much within our system. Again, I'm setting this user's role of that key-value pair for everything to that env:dev. So they're able to do kind of their day-to-day stuff within whatever that environment may be, development, Q&A staging. But then say they're ready to push — they've gone through the steps, they're ready to push to that kind of production environment. And this is kind of where that Just-in-Time access request comes in. So under Activity and Access Request they can create a new access request. And these roles that they're allowed to request can be fully defined on your end as well. So maybe they need to push some SSH stuff. They can give a reason, Fix for prod. And what I want to do before we do that is I'm going to drag my Slack window over to show that we can connect with those kind of chat apps. So I've tied mine into Slack. So as that user makes that request, I can see, okay, the new request came in, the user that made the request, what roles that they've requested access for that elevated privilege for, the reason behind that. And then as an approver or approvers, we can click a link and be dropped directly back into that UI. Again, we can review if we need to. And we can pick a reason, approve or deny them, so we can send them back a message, be careful with a little smiley face, and submit it back to them.
Scott: 00:24:29.869 And then again, since we've tied into that chat apps feature, we have that visibility as that end user of not having to sit within that UI, Hey, my request got approved. Now, as that end user, I can go back and refresh the page. Or if I've logged off, I log back in and I won't see my approved or denied request under here. And then I can click Assume Roles. And what we'll do is we'll see the roles then that I've been elevated to, as well as how long I have to do. And we can do things such as locking too of not only users, but access requests. So think of this scenario. Maybe somebody creeped through and got an access request approved or realized maybe they shouldn't have access. We can lock users down through that as well. And then if we go back and look at those servers, then we can see that we've gone from one to many and we can actually then still connect back to those systems now that we have access to and go through that whole gauntlet that we saw or spiel that we saw before of we can have moderated sessions for these. We can get that full session recording and get that complete visibility in our audit log and through those session recordings. And with that, I actually think — I didn't close it. I thought maybe I closed it. There it is. I wanted this one to just pull this last slide together. So kind of where to begin. So a lot of the data that I pulled through some of those beginning slides, I pulled from our PAM Buyer's guide that we have out there.
Next steps
Scott: 00:26:01.902 So we'll get you a copy of the slides and stuff and you'll be able to access those resources. But we also have things like we have a community Slack where a lot of our folks that are actually employed here at Teleport sit, our engineers, our sales engineering team sit. So as you maybe spin things up or have questions, you're able to interact with us. Again, since we're fully open source, you can also kind of bring up ideas or thoughts or things through our GitHub page or through our GitHub discussions. And then lastly, that kind of link at the bottom is kind of our getting started link to if maybe you want to kind of kick the tires on that kind of Teleport open source before you maybe talk to us about those enterprise features. That's there and available for you as well. So with that, that kind of ends kind of the whole spiel of slides. We did the architecture. We did the demo of some things. Now let's see if we have some questions out there.
Host: 00:27:00.930 Excellent. Thank you so much, Scott. Just a reminder to the audience, if you have any questions, please submit them in the Q&A section. And we do have a couple of questions in the queue. One of them is how teleport can help companies scale.
Scott: 00:27:16.996 Yeah. So I think for that one, if you think of scaling your thing, think of that kind of onboarding and offboarding of users. So as I bring new or hire new users, we're experiencing kind of growth here at Teleport, how can we easily onboard them and grant them access to those systems as they come on board in that kind of scalable or quick fashion And also, the same goes as we offboard users as well. So as they leave the company, we want to be able to quickly remove their permissions so when they are gone or are leaving that they don't have access to, say, those production level systems or whatever systems at the end of the day. And then it's more of that kind of ease of use from an end user perspective of being able to see kind of everything that I have access to, not having to have either a Google Doc or some kind of bookmarks of everything that I need access to. Where does it live, what are the IP addresses, how do I connect to it. That ease of use for that end user.
Host: 00:28:18.582 Great. Thank you. The next question here is how the solution is more modern than other existing PAM solutions in the market.
Scott: 00:28:29.020 Sure. Yeah. Great question. So if we think of — and I kind of harped on it probably quite a bit during it — is we take that approach of using their short-lived certificates. Giving users kind of that time to live or that TTL of how long they have access to something before they need to re-authenticate, and also being able to tie into kind of those more fine-grained access controls of what permissions people have and what access those roles then grant those users.
Host: 00:29:00.998 Great. Thank you. That concludes our Q&A. I want to thank everyone for joining us today, and thank you, Scott, for a great presentation.
Scott: 00:29:09.672 Yes. Thank you, everybody.
Join The Teleport Community
