Oktane19: Bringing Modern Identity to Infrastructure Access

Ivan Dwyer: I'm Ivan Dwyer. Really excited to be here. I am on the product marketing team at Okta here, and I joined about nine months ago via the ScaleFT acquisition. That was July of last year, and since then, I've kind of been responsible for bringing the advances server access product to market, which was previously ScaleFT server access.

Ivan Dwyer: It was obviously a very, very proud moment for me yesterday, and the entire ScaleFT team. There's a few folks in here to see that magnitude of a product announcement and to see the warm reception we got from Okta's customers about this new product, it was really exciting for us. A very proud moment for our team. We put a lot of work into this in the last nine months, but we're putting a lot more work into it, and we have a lot of exciting things to share here, so I'm happy to do a deep dive.

Ivan Dwyer: But nothing like customers and having customers say it first. For the past few months, we've been selectively adopting ... some Okta customers have been adopting the product through what we call the early adoptive program. And we're very lucky to have Jordan from MailChimp who was ... I think maybe the first, not the first to sign up, but he was the first that I talked to the day after the acquisition, when my head was just spinning a million miles an hour. I got ...

Ivan Dwyer: A rep hit me up and said, "Hey, MailChimp, they saw the announcement, they want to learn more." I hopped on a call, gave Jordan a demo, and then 30 days later, he was using the product. We flew him out here from Atlanta, so we're going to bring him onstage in a little bit. And Sneha, who is on the sales engineering team, they're going to do a little panel discussion. But Sneha was on the sales engineering team here at Okta, and she bravely jumped in to become one of the sales specialists on this new product, and has been working with a lot of our customers to help them get up and running, give them demos of the product. And she knows it in and out, so the two of them are going to have a great discussion.

Ivan Dwyer: But first, I want to set the stage a little bit with some of the design thinking around our product, and then we're going to do a live demo, a little different than what you saw at the keynote. But first, a test. Everyone memorize this yet?

Ivan Dwyer: Just kidding. I'm not going to do that.

Ivan Dwyer: First, I want to talk about, let's talk about what it meant for Okta to invest in the infrastructure space. I think we know. We saw yesterday, everybody was real excited this happened, but there's obviously been a lot of thought and a lot of thinking behind this for the past, not just the nine months that ScaleFT's been part of Okta, but even before that.

Ivan Dwyer: And a lot of it centers on a few things, and Todd touched on a few of these, but as customers, you're adopting more IS. I mean, that's just the reality of moving to the cloud, but with adopting IS comes a whole suite of complex identity and access implications. And it really could take a PhD to get each cloud vendor's IM's specs down right.

Ivan Dwyer: What if we could just maybe abstract some of that complexity into something like Okta, which is already your identity system of record? That's kind of the direction that kind of said, "Hey, maybe Okta can do more on this cloud infrastructure space."

Ivan Dwyer: But from a product perspective, and we're just kind of seeing this zero trust emerging as that dominant security architecture for any modern organization regardless of size. And we heard it this morning in the keynote. Everyone kind of thinks about zero trust a little differently. To me, it's just cloud-native security done right. And what that kind of means is if you're adopting cloud infrastructure or you're adopting cloud applications, the security controls that are inherent to that cloud environment is kind of what we think about from zero trust.

Ivan Dwyer: And it's really just doing security right in the cloud, so as a leading platform provider for zero trust across not just infrastructure, our controls for all of our access kind of have to match the model, and some of that is a little different than maybe traditional thinking.

Ivan Dwyer: And with all of that IS adoption and cloud adoption, devops is becoming an increasingly important function across all of your organizations. And with devops, automation is the name of the game. But shifting a lot of those controls left, which is kind of a term for devops security, is a real challenge, and the last thing you want to do is have a bunch of kind of legacy environments and things holding you back from automation. And it just so happens that a lot of the controls around infrastructure access can hold you back from automation.

Ivan Dwyer: Really, I see this as being one of the last dominoes to fall in terms of cloud adoption and automation. All of these things kind of came together at the right time, and you, as customers of Okta, have incredibly high expectations for us in this regard, and so that's why we're really excited to be introducing the product that we're introducing.

Ivan Dwyer: But let's touch on some of that complexity around needing to modernize identity and access with all of those key trends.

Ivan Dwyer: A lot of it has to do with the credential mechanism. Now, you're dealing with infrastructure access, so think of your SSH keys, RDP passwords, these, it's just really hard to keep track of these at any level of scale, whether you have a handful of servers on prem, or you're running thousands of servers in the cloud. Just the idea of the credential holding the privilege to do the task, that's a real challenge because, in that sense, possession is 100% of the law. You have access to that key, it's really hard to control who actually should be granted access.

Ivan Dwyer: Similarly, you deal with infrastructure, you might use a third admin account. You might pass around ... we saw, the keynote demo, was kind of a joke with the little keychain with the SSH keys and passing your SSH keys via email. You know, that's obviously a very extreme thing of what not to do, but we still see a lot of that from just sharing accounts between people inside of organizations. And obviously, as an identity company, Okta, we believe in identity first. Identity-led authentication workflows.

Ivan Dwyer: And so, if we can kind of get away from some of that, sharing around the accounts, then I think we're in a better ... kind of modernize how we treat infrastructure access.

Ivan Dwyer: And then a real challenge, think about the case when a systems administrator leaves your organization. It's really hard to figure out what they had access to, how to decommission their accounts; that's a really manual process and a huge, huge pain point. I'm sure you've maybe encountered that at your own companies. Just having a handle on not just the provisioning of accounts, but the de-provisioning of accounts.

Ivan Dwyer: And we're dealing with critical infrastructure. We saw it a couple weeks ago in the news. Some disgruntled IT admin who had been fired still had access to the infrastructure, bricked a bunch of production servers. The guy's name was Speedy Gonzalez. I don't know what they were thinking, anyway.

Ivan Dwyer: But that's a real thing, and that happens all the time. And it really is about that kind of automation and provisioning of the accounts at the infrastructure level.

Ivan Dwyer: But lest we forget the end user experience, because nothing frustrates sysadmins more than having to jump through a bunch of hoops to do their job. And the thing about sysadmins is they are super-technical, and will do whatever they can to find workarounds, which is not the security that you want to put forth in front of your organization.

Ivan Dwyer: Now, again, all of these, what's consistent is this is all blockers to automation. And if you're adopting IS and you want devops as a function inside of your org with zero trust as that architecture, anything that's blocking automation is going to hold you back. So, let's do what we can to modernize identity and access.

Ivan Dwyer: But I do want to touch on why this is such a hard problem to solve, and just kind of double-click on that credential problem. We kind of already mentioned it, but you've got those static keys, the SSH keys, RDP passwords. That holds a lot of weight, but they're very static in nature. Possession is 100% of the law. It might work for one or two people to have, manage their own credentials. But this breaks down at any level of scale.

Ivan Dwyer: Out of this has come a whole suite of best practices and products that have done everything they can to protect the keys, and it's all about, how can we better manage those credentials, and wrap management plans around them, vault them, rotate them? And then basically saying, "I'm going to continue to protect these keys," and have a really good answer how I secure my credentials.

Ivan Dwyer: But that's still fundamentally rooted in the notion of, it's the credential that holds the privilege to do the task. And that doesn't necessarily mean you have a clear link of who should be able to access what. And this is probably why we see no fewer breaches year over year related to some form of credential misuse because, again, it's possession 100% of the law.

Ivan Dwyer: What if we could kind of start fresh, and think about how to solve this problem? And this is where I think zero trust kind of comes into play. Fundamentally, at an architectural level, it's getting away from binary decision-making. We see it a lot in the perimeter; the perimeter is a binary decision. I'm in the network or I'm out of the network.

Ivan Dwyer: Same thing applies to credentials. It's a binary decision of, I hold the credential or I don't. What if we could take all of that contextual access capabilities that we see Okta investing in from logging into your business applications, and apply it to the infrastructure level?

Ivan Dwyer: This is hard. But it's something that we can do using some kind of modern technologies, and a lot of the stuff that ScaleFT has built. And it's really about taking that contextual access decision and then minting a credential that matches that decision.

Ivan Dwyer: Imagine putting all of this effort into bringing in context around user, device, network, location; grant somebody access and then hand them a short key. That's a wasted effort. We want that credential to match the decision exactly, and that's kind of what ScaleFT built. That was our bread and butter, and what we're now bringing to Okta through advanced server access.

Ivan Dwyer: I guess ... the announcement was yesterday, so not that exciting. You've all seen this. Zero trust access for infrastructure, and we hear this a lot from our customers, it just works. It's a very elegant solution.

Ivan Dwyer: But what I think is really cool and why there's so much interest across the Okta customer base, is that it's really just Okta for infrastructure. We're taking everything you already know, and it's very familiar from terms of single source of truth for your accounts, we're just doing that to the machine level. Lifecycle management, provisioning, de-provisioning accounts. Now we're doing that from Okta to the machine, and we're extending very familiar, seamless single sign-in workflows to new protocols in SSH and RDP, and then with adaptive MFA, the ability to inject a lot of those contextual access controls into a server access decision process.

Ivan Dwyer: All of this comes together. You know, infrastructure access is an incredibly complex topic. I know that. I've been building the product for many years. But when you really think about it this simply, it just makes sense as a core Okta product. And I think that's why people are so excited about it, because you already have this frame of mind of, "I know Okta does these things, and they do them very well. What if we could just do that across our infrastructure fleet?"

Ivan Dwyer: And I'll show a demo, but we're really trying to make this a seamless end user experience, and the word is Elegant. That's the one that I come back to all the time, we hear it from our customers. There's no services to operate, no PKI to manage, no out-of-band processes. It's very simple, direct client-to-server connection where every individual request is independently authenticated and authorized based on these dynamic conditions. And then that's backed by an ephemeral credential mechanism that mints one time, short-lived, tightly scoped client certificates for every single request.

Ivan Dwyer: Cleaning up a lot of the pain around credential management, everything's an Okta identity-led workflow, it's very seamless, and it's simple, and it's super elegant.

Ivan Dwyer: If we go back to some of those challenges around what we need to modernize, what are we going to get and gain from this product? I mean, the big one is eliminating that credential management. I used the word Ephemeral; that's the way we kind of think about these credentials. What's the best way to emit the risk of credential theft? And this is a line from one of our ScaleFT founders, who I see over there, is to make them useless outside of a single scope.

Ivan Dwyer: So, it's not about protecting the credential. It's about making them basically useless, basically, in the sense that you still need a credential to log into a server, but if we can tighten that scope in both time and user end device, then we've done a really good job of making things very, very tightly scoped to a request.

Ivan Dwyer: Everything's identity-led. You've got your Okta system of record already. Now we're just using the same thing for local accounts on the servers themselves. It's a very clear link from an identity perspective, which extends to both the end user experience, how you build policy, and obviously, how you audit on that eventually down the line. Very seamless, identity-led.

Ivan Dwyer: That lifecycle management, that is the killer feature by far. You saw it onstage when Nick Fisher from Atco Group got fired. His account was instantly deactivated inside Okta, he couldn't log into any more servers. Nobody had to go in and figure out which systems he had access to. Nobody had to go in and remove those credentials or remove keys from his laptop. It was pretty seamless, it was just Okta, and you get that from end to end.

Ivan Dwyer: And you've seen a lot of the announcements we're making around more lifecycle automation. Think about that in the context of infrastructure access. That's going to be super huge. As we roll out more of those lifecycle management capabilities, think about that at the infrastructure level.

Ivan Dwyer: And then, we're going to make your sysadmin super happy. We'll let Jordan talk about it, but it really is about putting forth a very seamless end user experience for the people who really need access to critical infrastructure. In a bind, because that's usually when you need to get access to infrastructure, and if we can kind of make that a very seamless experience, then everyone's going to be super happy.

Ivan Dwyer: Let's see it live, and please, please pray to the demo gods, because I'm going to do something a little crazy. Not crazy. You've already seen the end user experience from the keynote demo. I want to actually show what it takes to kind of configure an environment and spin up a server in Amazon EC2, an EC2 instance on Amazon, and then enroll that with our platform via automation. We're going to do it a very manual way, just so you can see how it works. But as I'm going through this, picture this built into your automation at crazy levels of scale.

Ivan Dwyer: All right.

Ivan Dwyer: Camera one, camera two. Beauty! All right.

Ivan Dwyer: First thing I should mention is that as of today, the advanced server access is delivered as an application in the Okta integration network, so any Okta admin can just add advanced server access to your tenant just like you would any other application.

Ivan Dwyer: And then once you're inside of here, you're going to assign your users in groups to advanced server access like you would any other application. We're going to provision downstream, Okta to advanced server access. All the crud on the users. We're going to push those groups, and all the group membership is going to get pushed from Okta to advanced server access. But now, think about taking that one step further, because advanced server access is going to push that downstream to the servers. Everything that gets provisioned here goes all the way to the machine level.

Ivan Dwyer: And we have a separate console for advanced server access. This team, ASA demo and advanced server access team, represents the top-level object of a tenant and each team is backed one to one by an Okta org for identity management and authentication. And then within advanced server access, a project is a collection of servers and their associated role-based access controls. This is how you organize your infrastructure in a way that you know who has access to what based on group membership.

Ivan Dwyer: Let's create a project live, and see what happens.

Ivan Dwyer: Don't make me log in. All right. Oktane Demo. We're just going to keep some defaults. The defaults are that advanced server access is going to manage the server users.

Ivan Dwyer: Now, a project, as I mentioned, is a collection of servers and their role-based access controls. As a new project, there's obviously nobody in this. But the way to enroll a server that's going to be backed by advanced server access is, we have an enrollment process.

Ivan Dwyer: Now, there's a couple ways to do this. You can map your cloud accounts by account ID to a project, so any time you spin up a server in said cloud account, it gets registered with its project.

Ivan Dwyer: The other way, which we're going to do right now, is through an enrollment token. And the enrollment token is just a randoms string. It's really just there as an association method of saying, "When we install the advanced server access agent on the machine, we write this little token file and then it knows to put this server inside of this project."

Ivan Dwyer: What I'm going to do, I'm going to copy this token, I'm going to jump over to my enrollments script. This is just a handful of lines of Bash that's going to take to install advanced server access agent and do some basic configuration. Think about this in the context of automation. I'll just walk through a couple things. First, I'm going to write, copy that enrollment token that we just created. Again, that's the association method. What it does, it writes that to a local file, and then when the agent starts up, it knows to then associate the server with this project.

Ivan Dwyer: We can add some basic configuration. There's a whole list of configuration things you can add. I'm just going to give this a nice, fancy, easy name so when I log in, I can just do SSH Oktane Demo. And then, there's one thing that's probably better illustrated later, but once we're on the machine, and then you just kind of install the agent here.

Ivan Dwyer: What I'm going to do is I'm going to take this, copy it over, and we're going to manually spin up an EC2 instance, because that is fun. I'm going to breeze through this, and only mention a few things relevant to advanced server access. But this is where we need to definitely pray to the demo gods. Okay, T2 micro. Everything default. Basically, we want to run that install script at startup. That all looks okay. Don't need any of that. Let's just give it a nice, easy name.

Ivan Dwyer: Oktane. Not backup, demo. I had a backup. Security group, we'll drop it in a basic web security group that's got, I believe, 22 80 443. I think this could be just a web server. Now, here's the last thing that's important. Normally when you launch this EC2 instance, here's what it's going to say. It's going to say, "What's the key pair you want to associate this with?" Which would be the form of a static credential that we're trying to replace.

Ivan Dwyer: What we're actually going to do is when we spin this instance up, we're going to proceed without a key pair, which I have to acknowledge, because it is not as smart as us about how to do this yet. They're like, "Hey, you might not be able to connect to the server, but because we're running that install script, we should be okay."

Ivan Dwyer: I'm going to launch this instance and while this is starting up, let me jump back to advanced server access, and let's talk about adding permissions. By default now, even though all of those users and groups have been provisioned from Okta to advanced server access, by default, nobody has access to this because they haven't been assigned the project. The project is the authorization scope of these role-based access controls.

Ivan Dwyer: Let me add one of those groups, Okta admin. I'm going to be an admin, and I'm going to sync that group to the server. Admin and Linux in sudo, administrator on Windows, add that. If we go back, we'll see now, this group has got a group name and a group ID. This is what gets written to the server as the actual local account. Same for the local user count. There's only one Okta admin, which is me, and I get this ID. And I'm an admin, meaning I'm granted sudo.

Ivan Dwyer: Let me jump back and add another group of a few more folks. Okta demo users; this time, we're not going to give them sudo privileges. I'm definitely going to sync that down to the server, though. Add that. And let's look at that again.

Ivan Dwyer: Now we've got a whole handful of user accounts. I'm the only one that has sudo privileges, but these are the ID's. Now, if we go back here, let's just see if this is initializing maybe still. Let's just see if it's picked that up yet. There it is! Ho, ho! Sweet demo gods!

Ivan Dwyer: Here's the server in Inventory now. You can see, it has that AWS instance running Ubuntu, and it's got this sweet little Oktane demo; that was the configuration we wrote. Now, through the ScaleFT client, advanced server access client ... Oops. I still say ScaleFT sometimes.

Ivan Dwyer: Through the advanced server access client, which ships with a CLI, I've got my inventory of servers. Remember this sweet name, Oktane Demo? I'm just going to type SSH, SSJ, Oktane Demo, and through a very nifty little feature of SSH called proxy command, while I'm still just typing SSH and I'm interfacing with a native SSH binary on my machine, I'm actually interfacing behind the scenes with the SFT client, which is the client application. It does a lookup on the server inventory, and it's going to say Oktane Demo, and it's just going to SSH to that instance that we just spun up.

Ivan Dwyer: Cool. I just logged in via SSH. Nothing spectacular about doing that, but there's a few cool things on the machine now that we're here. One is if you're familiar with Linux access, you'd expect maybe in my home directory for there to be a .SSH directory with an authorized keys file. We eliminate that. No static keys. The way we logged in was through that one-time credential, which I'll show.

Ivan Dwyer: My local user account. This is that Okta account with that ID, and I'm a member of the SFT_OktaAdmins group. That's the group that gets written on the machine. In fact, everyone that was a member of that group gets created their own account.

Ivan Dwyer: All of that happened on startup, so when that agent was installed, it called out to advanced server access, it got the user and group membership, and then created those local accounts on the fly. Because when we ran that install script, we installed SFTD, which is the agent.

Ivan Dwyer: Now, the agent's there to manage those local user accounts, to capture all the login events. And then one other thing that we ran in that install script was we added a single-line configuration, added by SFTD, to trust client certificates that are signed by our certificate authority.

Ivan Dwyer: When I say certificate authority, I don't mean that in the traditional sense like web PKI. This is very much when we created that project, we spun up what we call programmable CA. All it really is is a certificate-minting machine, and it mints the certificates based on that authorization scope. When we talked about this scope, it is ... here's the audit events, user, my Okta account, client, this MacBook running the SFT client to a server inside of that project, and at this point in time, that was the credential that was minted and issued, and then the client used that certificate to log in. And because the server was configured to trust certificates signed by us, it allowed that as an authentication mechanism. But now that certificate's already expired, so it's pretty much rendered useless.

Ivan Dwyer: There's a ton more, obviously, I could show on this product, but I just wanted to kind of walk through what it takes to actually configure a basic project and enroll a server. Now, picture that at scale. Picture doing all of that via automation. I would say most of our customers do 100% of their work via automation. They rarely ever interface with the dashboard that much around creating projects and enrolling servers. But you can bake this into your machine images, you can bake this into your Chef, Puppet, Ansible, Terraform. Config management, it's all super seamless, and super slick.

Ivan Dwyer: That's the demo. Hope you enjoyed it. All right. Yeah! All right. Gotta love those demo gods.

Ivan Dwyer: Now, what I'd like to do next is invite Sneha and Jordan up to the stage. What I want to have them do is, we have some modern design principles. There's eight of them. It's kind of our manifesto. Think about it as our methodology of how we design this product, and it might be a little different than what you might be used to in this space. I'm going to have them talk through each one individually, and kind of get Jordan's perspective as an actual customer who's deployed this from MailChimp, and hear what's he gotta say.

Ivan Dwyer: Take it away!

Sneha: Great! Thanks, Ivan. Thank you so much for joining us today, and we're looking forward to having you tell us all about your journey. To get started, did you want to just introduce yourself, as well as what MailChimp does?

Jordan: Sure, yeah. My name's Jordan Conner, and I'm a security operations engineer at MailChimp. And for anybody who doesn't know, MailChimp is a marketing automation platform for small business. We started with a lot of email products but have gone into multichannel avenues, as well.

Sneha: That's great!

Jordan: Yeah.

Sneha: We're really excited to get started, so the theme that Ivan left us on was automation. And if we think about automation, then something that's really important is, how do you get there using some of these products?

Sneha: What was that journey like for you?

Jordan: Yeah. Automation was obviously the biggest factor, or value add, for us at MailChimp. How we had managed keys before and access to our infrastructure was primarily through Puppet and configuration management. Having developers create keys on their laptops, and manually create a PR, and add that to our configuration management. Any time we had to onboard somebody, it was a whole thing. Big old page in the Wiki on how to do it.

Jordan: And so, bringing in ScaleFT completely removes ... or, bringing in advanced server access completely removes ... sorry.

Jordan: Completely removes that process, and it's a lot more streamlined. And MailChimp serves its core traffic out of over 2,000 servers and three data centers, so anything we can do to increase that automation is a big add for us.

Sneha: That's great.

Jordan: Yeah.

Sneha: With automation, was that something you were able to use for both your end users and administrators there?

Jordan: Yeah, absolutely. With advanced server access, we had ... Onboarding was a lot easier, not only for the end users but also for our admins, and also off-boarding, as well. If somebody left the company, there's no longer a ticket that had to be created, or anything like that. It was very seamless.

Sneha: Yeah. By using Okta and advanced server access, not only are you getting the features that Ivan just talked to us about, but we want to make that journey seamless. With everything that you do with Okta, extend that to everything that you do with your on-premise infrastructure.

Sneha: That brings us to, how did you manage access before you started using server access? And was that easy to do?

Jordan: Well, like I mentioned before, we used Puppet for all of our configuration management, and we did the traditional thing with static keys. Every developer would create one on their own laptop and store it on their own laptop, and we would give them instructions on how best to protect that key, but there was always some kind of trust there with the developer. And accidents happen, and having so many static keys existing for a long period of time is obviously a risk.

Jordan: When we were looking at improving that process, we were thinking, "What's a better way we can do this?" And obviously, certificate authentication is not only easier for our developers, for our sysadmins, but I think it's also probably more secure, as well.

Sneha: Yeah. By using certificates, these certificates are not just about making the end user experience easy, but this manages security and usability. It's tightly scoped to say who the user is, what server you're accessing at that time, really going back to that zero trust model of always being able to verify not just who you are, but who you need to be in this moment while accessing these resources. And we're glad you were able to use that.

Jordan: So was I.

Sneha: You've been using Okta for a while, and that's a different model when we think about shared accounts and things. Have you been able to solve some of those use cases with shared accounts?

Jordan: Yeah, absolutely. We try and have as many individual accounts as possible and remove shared accounts where we can, but obviously, some still have to exist, and being able to tie into Okta is a huge way for us to move further in that direction, and make sure that everybody has their own identity when they're performing actions on a server so that we can have audit record, a correct audit record of what they did and where. And make sure that not only do we have accountability for what's happening, but also that we are not sharing credentials, and keeping those as tight as possible.

Sneha: Yeah! And with using server access, the other thing you get is also, we have some built-in capabilities around service accounts, as well, outside of typical logins. And those can be integrated seamlessly. I know shared accounts sometimes are a lot more than service accounts, but we are trying our best to solve those use cases across the board.

Jordan: Yeah.

Sneha: Before we started using advanced server access or being able to log in, you must have had some kind of directories to log in. How has that change been?

Jordan: Yeah, absolutely. We try and limit AD or LDAP as much as possible, and luckily, we had a pretty good methodology with creating local accounts through a Puppet configuration management. Bring in ScaleFT and creating those local accounts worked seamlessly with our existing tools. Worked very well with all of the existing infrastructure that we already had.

Jordan: And before we were introduced to advanced server access, I was looking at different ways that we could tackle this problem, and one of the things we were looking at was free IPA and some ... that just wasn't a value add for us, having to manage all those directories and manage LDAP like that. It just wasn't what we wanted to do, and honestly, it was just a big risk for us, as well.

Jordan: That's just a huge target for those servers on our network. We keep it simple with local accounts, and it's worked really well for us.

Sneha: Yeah. We're glad! With local accounts, one thing that Ivan mentioned was, we wanted to take the Okta products to advanced server access. If we take a simple example of what Okta does with lifecycle management today, that shouldn't stop at cloud apps, and we wanted to take that to your on-premise infrastructure. This means being able to say, "Based on what you've done in your source of truth, be it AD or your HR source or anything in Okta, based on where they are, those are back permissions," will translate into, "If a user moves groups, that will resonate all the way down to your servers. If the user leaves the company, that's instant, as well." Really making sure it's not just secure, but you're also reducing a lot of admin overhead there.

Sneha: You've been using Okta for some of these processes, but before, with servers, even while using Okta, you still needed to do a lot of checkout processes. Do users like the way that they do it now?

Jordan: Yeah, absolutely. I think when we were first presenting this to the team, I think a lot of people were hesitant. The keys were something they were very familiar with, they could touch them, but I think ... I mean, our IT department had done a really great job of bringing Okta to some of our other applications at the company, and so, bringing this interface to infrastructure access just made a lot of sense.

Jordan: And now that our developers and our engineers have seen it, it translates really well and, I mean, everybody gets it.

Jordan: You come to recognize Okta as being your authentication, and translating that into infrastructure access is, it's great and seamless.

Sneha: Yeah, your one place to go!

Jordan: Exactly.

Sneha: Okay. I think PAM is something we all talk about, right? Privileged access, where users need to be, but how do you define how that works? How are we able to help you with who a user should be, outside of just logging in?

Jordan: Yeah. I mean, advanced server access brings us great knobs to tweak when we want to create different roles for our users. Before, in our configuration management, we started kind of those patterns when we were a very small company, and as we're over 1,000 people now at MailChimp, and obviously that ...

Jordan: We needed to scale those processes. Advanced server access brings us new opportunity to give the right role and the right access to the right developers. As we specialize more in the engineering departments, there's more need to give role-based access.

Sneha: Yeah. With role-based access, not only the demo you saw, somebody had user access, somebody had admin access. This is a huge area for us, and as we kind of develop the product, we want to make these permissions so granular that you're able to manage who a user should be on all these servers from this one dashboard, so we're just getting started there.

Sneha: A lot of times when we're setting up Linux servers, and access is great, but we have to have jump servers or bastion architectures. Is that something you have in your environment, you're looking to use?

Jordan: Yeah. Well, currently, we use a traditional VPN to manage our access to our servers, and it's all white IP, white list-based. And we're a growing company, and we're adding offices, so one of the problems that we see with VPN is whenever we need to go add new network equipment or even open a new office, that's a lot of overhead that we need to do to then go configure the VPN, and then configure accesses based on those new IP's.

Jordan: With removing that piece, I'd no longer have to worry about IP, or a firewall rule mis-configuration or any IP-based configuration like that.

Sneha: Yeah, making it easier for your users.

Jordan: Yeah, absolutely. And honestly, it keeps it a lot simpler, and that access point is grouped into advanced server access and that infrastructure, and it makes a lot more sense, and when you think about the architecture.

Sneha: Yeah. We want to enable you to use the architectures that you want to use, and not force any kind of architecture that we need for this product to work. So, one thing that you get with using bastion is we natively support the ability to translate that kind of authentication. If your user is trying to log in, they can directly try to access at the server that they need to reach, but that may be behind a bastion architecture, and we can translate that seamlessly within advanced server access.

Sneha: We hear about session recordings a lot. Is that the way that you keep track of what's happening, or what's the best way for you to see what's going on with your users?

Jordan: Yeah. How we have it currently is we have a bunch of audit D-logs that come into our ELK stack, and it's kind of how we parse through what's happening with our servers. But audit D-logs are not the easier thing to read, and they can get pretty messy, and there's ... I mean, it's more or less a fire hose when it comes to audit D-logs. Having the events page, it's easily human-readable, it's clear, and it's given us a lot more insight into kind of what's happening.

Jordan: And not only what's happening on the servers, but also we can see the end points that our users are connecting to our infrastructure with, as well.

Sneha: Absolutely. A lot of you use Okta today. As you know, the sys log populates everything that's happening with the user. This extend to what's happening in server access as well, which comes down to who the user is, what they're trying to access, what credential was minted to them; that's all being logged, and we want that to be presented in the way that you need.

Sneha: Thank you for sharing that with us. And with that, quickly, we hope that that was a good journey for you to see how a user goes from using everything they see in Okta, really identifying who they are with Okta's adaptive policies, transforming that to not just your cloud apps but your on-prem apps, and we'd like to thank you for being here with us today, and also being a customer who's always helping us out.

Jordan: You're welcome! Thanks for having me.

Sneha: Thanks.

Sneha: And with that, I'd like to invite Ivan back to tell us where we're going next.

Ivan Dwyer: All right!

Ivan Dwyer: Zero trust. You guys heard about it? All right, no ...

Ivan Dwyer: One, zero trust, kind of emerging as that dominant security architecture for any modern organization. Obviously as a leading platform, our controls have to match the model. And we want to see us continuing to evolve how we treat identity and applicant from a very zero trust mindset, and extend that model to more things.

Ivan Dwyer: Similarly, as we're seeing this kind of convergence of all disparate access controls and access management under a single identity like control plane. Now, when we talk about extending advanced server access to Okta customers, what we're doing is we're strengthening Okta's core identity and access capabilities, we're just adding new resources and supporting new protocols. We just want to see more resources and more things coming to Okta, 'cause having a central control plane is going to make it easier to create and manage those policies. You have better confidence that we're adhering to those policies, 'cause you have a central view into it, and then it's just seamless access controls and seamless single sign-on.

Ivan Dwyer: Whether you're a human user or service user, privilege user, accessing a piece of infrastructure or business application or an API, the more that we can kind of unify it under an identity-led control plane, I think the better off you will be as Okta customers and we're kind of thinking about that from a big picture perspective.

Ivan Dwyer: Now, very specific to infrastructure, how do we want to evolve Okta for infrastructure? This is a very forward-think statement here, thanks for that disclaimer before we started, but servers is really just the beginning for us. Servers is kind of a natural resource to extend Okta access controls to, but your infrastructure environments are not just servers. There's databases. We're getting more container orchestration. We're seeing Kubernetes evolve and the dream, from the Kubernetes standpoint, is to never have to SSH into a server again.

Ivan Dwyer: What's the interface to Kubernetes? It might be a CLI. You have two control. What if we could inject Okta access controls in front of CLI's? Whether it's you're a native AWS CLI, GCP CLI, whatever kind is coming next. We're kind of seeing, what we want to do is support Okta identity and access across every cloud environment, every platform is a service, every container orchestration layer, and for Okta to just kind of be that access control layer.

Ivan Dwyer: Very forward-thinking. Would love to hear feedback on where we're kind of taking this product. Obviously, today, what we've announced is advanced server access. That is available, as we mentioned. But you tell us where you want us to take this product. I guess that's probably a good time to open it up for questions.

Ivan Dwyer: We got a few minutes.

Speaker 4: This is really great work, thank you. SSH, the certificate authority also supports security options, like whether or not you'll allow port forwarding and agent forwarding and exporting. Do you know if that is supported in your product?

Ivan Dwyer: That's a good question. The actual cryptographic properties of the certificates themselves, think about that as relatively meaningless. It's more about limiting their kind of scope and time. But the ability to take some of that trust from our client to be able to forward that across different environments is something that we've built some capabilities around that.

Ivan Dwyer: But in terms of using SSH, we kind of want to take a lot of that client trust, 'cause we've got the client application, and try to make it as direct as possible. I think the fact that we support bastions is kind of a good way to think about the way we could potentially hop.

Ivan Dwyer: But if you start moving around some of the properties of your local SSH client is where you could potentially get in some trouble, so there's configurations and ... to do port forwarding, Netcat, things like that. But it's kind of a function of your client trust, which you buy into that Okta authentication session. But that's probably one, and I think our engineering team probably has some opinions on that. You'd, love to connect you with some of those folks, too. But good question. Yeah.

Ivan Dwyer: All right.

Speaker 5: What happens to the bash history when it uses a de-provision?

Ivan Dwyer: What happens to the, sorry?

Speaker 5: The bash history.

Ivan Dwyer: The bash history!

Speaker 5: Yeah.

Ivan Dwyer: Ah. Good question! Ah, we're getting some good Linux admin questions.

Ivan Dwyer: I mean, you're a local user on that machine, right? We create that local account. But we create that local account not on first login, but we create it when that agent hits our environment. If you disable that user account in Okta, from a lifecycle management perspective, we disable that account from a certificate-minting perspective, but we don't delete the account from the machine.

Ivan Dwyer: If you then re-add somebody to a group, it picks up that change and it reactivates that account, and so it preserves the account history, so things like bash history would preserve. We were not going to delete that local account and then re-add it. It is that first time it connects to our back end, when it creates that account.

Speaker 6: A lot of companies use privileged accounts when accessing servers. Some privileged accounts have very strenuous password change requirements, as in the password being changed in a certain number of hours. How does this tool address password changes? If we're using local accounts.

Ivan Dwyer: Right. Think of it as an Okta authentication workflow. This is a sign-on policy between Okta and advanced server access as an application. All of those policies that you enforce at that level get carried through to this.

Ivan Dwyer: The thing that we add from an auth end perspective is that device binding. If you've got MFA as a sign-on policy in front of advanced server access, we're going to enforce MFA on that first authentication event, then every login, though, is carrying that authenticated session through and then re-authorizing based on the role-based access controls and any other custom policies that you have on top of that.

Ivan Dwyer: Meaning that the password association is more like logging into Okta versus logging in as, to a server at a local account level, because we're kind of carrying it through from Okta all the way into the server. Whatever you have as a sign-on policy inside of Okta is going to get passed through.

Ivan Dwyer: It's a little different than, I think, traditional, around rotations and things like that because we're actually, there is no SSH password associated with a key, 'cause there's no key. It's just, once that request is authorized, the certificate's minted and delivered to you, and then the client application uses that certificate to authenticate, but there's never a password exchange in that flow. It's more logging into Okta as you normally would.

Ivan Dwyer: Hope that helps.

Ivan Dwyer: All right, we got a lot more here. Here we go.

Speaker 7: Hi. What are the connection requirements for the client on the servers? For example, in the demo, they showed that when you delete the account in Okta, it automatically replicates to the server. But what needs to be in place for that to happen?

Ivan Dwyer: Right. The agent running on the machine needs an outbound connection, port 443 to hit our back end, and that's what picks up any changes. It's actually the agent calling out to our back end environment. The client is really what's communicating with the SAS application in terms of Okta. The client needs to be able to connect to the internet, the agent needs just port 443 access to the internet to pick up those changes. Those are the kind of baseline requirements, but if you've got private instances, that's where the bastions come into play because we're going to take that client connection and move it forward.

Ivan Dwyer: I am getting some serious hand waves that we are out of time, so I'd better stop talking! Thank you so much for joining the session. This was awesome. Find me afterwards! Talk more.