Oktane20: Shift Identity Left- Secure DevOps Automation With Okta

Ivan: All right. Hello, everybody. Welcome to this virtual Oktane session. Before we get started, I want to read our Safe Harbor statement. So this presentation may contain some forward looking statements. So please refer to the accompanying slides for more information. Don't worry, there will not be a test on this later, but just know that there's some things that we might talk about that contain forward looking information.

Ivan: Now getting started here. I'm glad to be here again for this virtual Oktane session. My name is Ivan Dwyer. I'm on the product marketing team here at Okta. I am joined today by Kalpana Singh who's on the product strategy team at Okta. And we're going to spend some time today talking through some emerging security trends and considerations in the modern cloud era. We've seen from a lot of our customers that DevOps is becoming an increasingly important function across any type of organization. So we're going to talk a lot about the role of security and DevOps. And then we're going to talk about the role identity plays in DevOps security, and all the while introducing this new term, which is "shift identity left".

Ivan: Now, before I pass it over to Kalpana, I kind of want to set the stage a little bit here for this presentation. This is really meant to be a practitioner talk. We really want to focus on your job to be done. So hopefully you can take some of the things that we cover today and put it into practice at your own companies wherever you are along your cloud journey, but as practitioners, no matter your role, you're on the hook for something. We live in an incredibly fast paced and ever changing world as clearly evidenced by today's times. So if you're on the business side, that means you're kind of on the hook to deliver continuous innovation to your customers. It's really the only way to remain competitive in this fast paced world.

Ivan: Now, as every company becomes a software company, this means that developers are on the hook to deliver continuous innovation back to the business. And then the operations folks they're on the hook to deliver that software continuously and very quickly.

Ivan: Now here's where things get interesting. Security folks. You're really on the hook to not get in the way of all of this amazing continuous activity, unless you really have to because of something around security, but really try not to, but unless you have to, that's when you can get in the way. I think it kind of got the idea here. So really the spirit of this talk is how can we enable productivity across your organization without fully compromising on security. And the themes that are going to apply, we're going to talk about it, really do apply to every role here, not just the security team. It is a security context, but it does apply to everybody.

Ivan: Now as for me, I am personally on the hook to deliver this presentation, but thankfully not continuously. So with that, I will pass it over to Kalpana to talk about security in a DevOps world. Kalpana, off to you.

Kalpana: Thanks, Ivan. As Ivan mentioned, I'm part of the product strategy team at Okta. Thank you everyone for joining this virtual Oktane session. So let's get started talking about security in the DevOps world.

Kalpana: Over the past 15 years, there have been two significant changes that have impacted the way enterprises build and consume software. One is infrastructure, or now everything as a service, which allowed the flexibility around where things are developed and deployed. You could basically spin up infrastructure within minutes using a credit card. Hence 80% of The Global 2000 are using one or more infrastructure provider to both test and deploy their services.

Kalpana: Second is how things are built, or how software is developed with the emergence of DevOps, and shift from traditional waterfall model. A majority of organizations are adopting the DevOps model. Hence the DevOps spend is expected to be 23 billion by 2023. All of these changes have a cascading impact on different aspects of the process. You know, infrastructure as a code from static infrastructure security model, shifting from zero trust with dynamic security controls, dynamic registry of services versus a static system of record, a multi-cloud delivery model versus a single deployment development and deployment cycles getting shorter from years to months to weeks, and from weeks to days and hours, respectively, and use of pervasive automation. As this shift happens, security considerations become more critical and can become the limiting factor in achieving the speed and agility enabled by infrastructure and a service and DevOps capabilities.

Kalpana: So how do we rethink the security model? In the past, and to be honest, for most enterprises even today, security controls are an afterthought as you see on the left. The Dev or DevOps team would build stuff and plan to deploy. When the security team came in, or in worst case it came in afterwards to figure out how to implement the necessary controls. As a result, these controls turned out to be complex, clunky, and static, and had to be readjusted if the DevOps teams meeting changes. Also these controls were typically made from a compliance mindset, versus as a security mindset. In order to just get stuff out the door.

Kalpana: To maximize benefits provided by DevOps and infrastructure service security model needs to align with the DevOps process and shift left, as you can see on the right. It will enable controls to be embedded natively at each stage versus layer at the end. And these controls would be more dynamic and agile made with a security mindset versus just a compliance mindset leading to a more effective zero trust model. But as with everything good, it's not as easy as it sounds. As for a 2019 state of DevOps report for most companies, the idea of integrating security into delivery lifecycle is an unrealized ideal.

Kalpana: What makes it so hard? Balancing the need for speed for the business with integrating security in DevOps can be challenging, especially when these two are separate teams and processes for most organizations with different goals. The scale of distributed environments make it hard to establish baseline for a current state and identify what controls exist, what needs to be in place, and what needs to change. Also due to the thermal nature of the environment, things need to be continuously monitored and adjusted. All of this adds tremendous amount of complexity for the teams. They want to do the right thing, but just are overwhelmed.

Kalpana: So let's make security work again in this modern environment by establishing effective controls at each state checking and fixing for vulnerabilities right at the coding stage, signing off all code to make sure only [gold 00:07:10] copy moves forward through each step, continuous checking to see if there are any new vulnerabilities that get introduced throughout the process through dynamic code analysis, embedding appropriate security controls as code is released and deployed, and forcing the right runtime controls to make sure that monitoring and detection of runtime attacks happens, and finally establishing an automated and streamlined process to orchestrate the proper response.

Kalpana: The entire model will have a feedback loop. The DevOps and security teams would work closely to implement and execute this model. It would not be a onetime effort for most organizations. It would be a maturity journey before the DevOps and security teams become DevSecOps. But once you achieve significant or full integration maturity, you will see incredible benefits. Improved confidence in security posture, faster vulnerability times, and faster vulnerability resolution times, improved deployment frequency as security becomes less of an inhibitor, and better collaboration between DevOps and security teams.

Kalpana: So now that we have talked about how shifting security left works, let's talk about shifting identity left, and for that I will pass back on to my colleague Ivan.

Ivan: Great. Thank you so much, Kalpana. So now that we've really seen how security kind of plays into this DevOps automation, I want to talk about the crucial role identity plays, and we'll introduce the term shift identity left. Now, the reason identity is such a key function of DevOps is because it represents access and privileges. So really who can access which resources, under which conditions, what can they do, and then what did they do. So there's a lot to this, and this is not an exhaustive list by any means, but just a few of the kind of key identity functions in this context might include provisioning, deprovisioning user accounts across a wide range of systems and applications, then performing authentication and authorization workflows anytime a user attempts to log in on one of your resources, from there you're issuing credentials for valid requests to applications, APIs, and systems. And then you have to broker secure connections between the user and the target resource enforcing any policies along the way across the systems, and then of course, logging and auditing all of the user behavior.

Ivan: But if we're to look at this in the context of a more automated pipeline, let's take that infinity diagram that you often see in the context of DevOps and we're going to put it in a linear sense. Now identity is very important across each dev and ops stage. There may be some different implementation details between the dev and ops teams, but there's a lot of consistency across the functions. And there's a common need to inject controls as far to the left where the human interactions and configurations lie. So if you've heard the term "shift security left" it's really just taking controls and trying to move them as close to the humans as possible before the machines take over.

Ivan: So when you're writing application code or you're writing infrastructure code, identity and access is very important controlling who can contribute first and foremost, but within that code there's a number of places where additional accounts credentials might need to be placed. So common examples might be an API key to hit an endpoint in an application, a database password to run a query, or an SSH key to provision servers.

Ivan: Now, as we move to the right is when the automation starts to take over. This is where services start to execute across the pipeline. Software is built into packages that can be deployed, and infrastructure resources are provisioned across multiple cloud environments. Now here is really where it's important to understand what privileges various services have and what credentials might be needed for them to follow through that automation. So the notion of least privilege access is a very key theme at this stage.

Ivan: So those services are then responsible for releasing software, or run times are configured across your infrastructure, and the application packages that are deployed. Here is where you have to be really extra careful because granting access to these production environments is basically like handing over the keys to the kingdom. So the closer you can be to a zero trust architecture, the better off you are. Because once live, software that hasn't been security tested or infrastructure that hasn't been locked down is what gets folks into a lot of trouble. Now we see no fewer breaches year after year where the cause was some misconfiguration of access or privileges.

Ivan: Now there's been a lot of investments made across this entire landscape, but we don't really see a ton of progress. Why is that? Personally, I believe it's because we have a very mismatched approach to identity. A lot of the traditional methods just don't translate well to these more modern, automated cloud infrastructure environments. So administrative tasks, they need administrative credentials. This could be an SSH key or an API key, but the challenge with these is that they're static. They're very hard to attribute to a real user. Again, possession is a hundred percent of the law. So we spent a lot of our traditional efforts trying to protect all of these credentials from getting into the wrong hands.

Ivan: Also shared administrative accounts are often used in the context of automation or tooling to perform specific tasks. Again, this is very difficult to attribute to a user. From a policy perspective, you want to be able to manage permissions by a certain role. And then from an auditing perspective, you want to know who the user was that performed that action. And this is really hard to do when people are sharing accounts and using static credentials.

Ivan: And then finally, some systems may just have local administrative accounts with no tie back to some system of record. This is extremely dangerous because that becomes almost impossible to track who has the right permissions across which systems also becomes an operational nightmare when you have different identity stores in different policy stores.

Ivan: Now all of those problems with legacy identity and access management, the traditional methods, they only compound when you're dealing with automation and you're dealing with scale, because you have more systems and they're dynamic systems, you have more accounts and credentials to worry about. So the example I always bring up in this context is think about that classic case of a system administrator who leaves the company. Now how can you guarantee that their access has been properly decommissioned when you have dynamic infrastructure all over the place. Now without a strong identity layer, that's a really hard question to answer. You might have to go manually digging through all of your environments, logging into different systems, logging into different servers, looking into different account databases, all of those things that Kalpana talked about making security hard in general speed, scale, complexity, that just makes an ongoing nightmare for those in charge of this. And this is something that we spend a lot of time talking to our customers about. And we've heard a lot of the challenges.

Ivan: I have heard some horror stories. Anytime I say, "What happens when a system administrator leaves the company," I've heard a pretty wide range of responses. You know, we talk a lot about onboarding users, but offboarding is just as critical, especially from a security perspective.

Ivan: So I've come up with this term to represent how to best inject identity and access management controls into your automated DevOps processes to deal with all of this operational complexity when we're dealing with dynamic infrastructure environments. Now, if you've heard the term shift security left, this is not a far leap by any means. We're just talking about it in the context of identity.

Ivan: Now, the primary goal here is to ensure that automation, automated workflows, have the right guard rails in place. We want to provide the right levels of access where needed. We also want to minimize the exposure of all those sensitive accounts and credentials. And so if we can inject identity into the automation pipelines early on, we can have a better handle on how the access controls and policies are going to propagate across these dynamic systems. So again, static credentials are a significant risk in any system. So rather than focus your efforts on trying to [wrap 00:14:50] controls on them, it's better to replace them with just in time credentials, wherever you possibly can.

Ivan: Now addressing the risk of credentials is a critical path, but the real first step is having a unified identity layer to enable all of the necessary policies and procedures from a single source of truth. And then once you have that unified identity layer, you can better centralize your access controls. And having a consistent control plane to perform authentication and authorization is a better way to answer who can access which resources and under which conditions. And with that unified system of record, this is where you can start to automate things. You can start to think about the lifecycle of accounts and policies, then how that propagates across your dynamic infrastructure environments. So thinking back to that question of decommissioning access for assist admin, if you have the right lifecycle management tied to your system of record, you can ensure that privileges are effectively granted and then removed when appropriate. And of course, in order to execute this effectively at scale, every functional process must be automated.

Ivan: So the main thesis here is to make identity and access part of your automation, not an afterthought. If you take away one thing from me talking here, I hope it is this, because this is a very powerful statement here. Not just because it's Beyonce pointing to it, but it's because all too often I see identity and access bolted on after everything is then automated. So you can spend all this time spinning up provisioning infrastructure, and then you have to go back and figure out how to grant identity and access. That's a really painful process, but it also provides really weak security controls if you're adding manual processes on top of automation.

Ivan: But at the end of the day, we talked about what you're on the hook for if you don't automate your identity and access, that might block all of that continuous innovation and continuous delivery that you're on the hook for as practitioners. So if you can make identity and access part of your automation by shifting left, that's when you can better constantly answer that question of how to streamline automation without compromising on security, which is a huge win.

Ivan: But because we're talking about automation, the only way to do this thing effectively is to declare everything as code, so you get all of the benefits of things being version controlled, documented, testable, reviewable, or reusable, and my personal favorite retractable. I get myself into trouble all the time. Now this applies equally to developers writing application code, and operations folks writing infrastructure code. So remember this, once things hit the automation, that's when the machines take over. So your security controls are really only as good as what you inject. That's why the concept of shifting left is so critical here.

Ivan: But of course, this isn't done with a snap of the finger. As with anything done right in our world, it should be taken in stride and done in phases. So at Okta, we spend a lot of our effort focused on getting you through this maturity curve. Now we want to get you out of phase zero first and foremost. We want to unify identity management. And then we're going to kind of guide you across the rest of the maturity curve as you build out, and involve your own DevOps practices.

Ivan: The reason I start with phase zero here is because this is essentially table stakes. The bare minimum effort is to secure any credentials you have maybe in a vaulting service. You know, we did talk about this isn't really getting identity right, but at least now you have a handle on the account's credentials. You might not have a lot of meaningful data about who the user is, and that's not going to provide you a ton of value, so that's where we're going to kind of get you up to that next level, which is phase one.

Ivan: And that's unifying your identity management layer. This means having a system of record for your users, their roles, and then the policies of what they can do. This is where you can add effective authentication or authorization controls, attributable to a user, and bonus points if you can do that to a device too, very critical in a context of zero trust.

Ivan: Now, if we're going to build on that strong identity layers, we're going to add more contextual access controls. We're going to factor in some of these dynamic conditions, and of course adding multifactor wherever possible, wherever there's human interaction. Now, this is where we start to remove all of these kinds of static credentials, wherever possible in favor of what I call "ephemeral credentials", which are really on demand just in time credentials that are intended for single purpose use. And if you get to this level of contextual access, you're going to be able to make a lot, much smarter decisions, and then give you much better data to monitor and alert on, so you can have more observability around your systems.

Ivan: Now what I like to call the peak of Mount Everest, which is that Holy grail of zero trust, when we talk about fully automated remediation. Now this is no easy task, of course, but it is achievable, but only by moving through each of these phases and truly dedicating resources and time to get it right. Now, the marquee example I always talk about in this context is Google through their BeyondCorp initiative. Now that was a huge effort that took Google six years with a large, dedicated team, but over the past few years, a lot of organizations and a lot of tools have come up to help companies achieve the same outcomes without having to go through such a long process themselves.

Ivan: So this is a nice maturity curve to kind of think about where you are from a identity and DevOps perspective. So take a mental note at where you are along this curve, and maybe what actions you might want to take to move yourself forward. Of course, this is something that we at Okta to spend a lot of time with our customers, and we'd be happy to help you out with that.

Ivan: So let's talk about that actually in practice. With Okta as your foundation for identity, you can leverage our advanced server access product to automate and streamline a lot of these access controls we talked about across your critical infrastructure resources. But just to level set, if you're not yet familiar with the advanced server access product, it is an Okta application that extends zero trust identity and access management capabilities to Linux and Windows servers across any cloud environment, public or private. The product was purpose built for the modern cloud. And we have a very elegant approach to a very common privilege and access pain point.

Ivan: So if you were in attendance at Oktane last year in person, you might have seen us launch this product on the main stage to great fanfare, of course. So here we are one year later now, virtually, but we have a ton of adoption and a lot of learnings from how you, our customers have been deploying and using this product. And we've seen a lot of really forward thinking patterns emerge fully in line with what we've been talking about. These kinds of cloud first identity centric approaches to automation which is a great validation for us for building out this product, and also for the notion of shifting identity left.

Ivan: So just at a very high level, advanced server access delivers three key capabilities in this context. We're going to enable just in time passwordless authentication to Linux and Windows servers by SSH and RDP. We automate the end-to-end lifecycle of local server users and groups at scale with Okta as the backing source of truth. And then we have abilities to enforce fine grain, role-based access controls and command level permissions for strict, lease privilege access across your most critical infrastructure resources. But what this means for the business is really helping to enable velocity at scale. And really that's the primary business driver for adopting the cloud in the first place. And it's what gets us to that continuous innovation that everyone who's a practitioner is on the hook for.

Ivan: But I now want to talk about how this actually works under the hood from a product perspective. So let's first look at the lifecycle automation. So automating identity and access in this context really means managing the end-to-end lifecycle of these accounts and policies across dynamic infrastructure resources. So when you spin up a new server on AWS, the right people have the right levels of access automatically, not after running some manual process or runbook after the fact, but automatically right when that instance spins up, and then when that instance spins down access is removed and everything is automated from a user group enrolled perspective.

Ivan: So moving from left to right here, we have the Okta identity cloud is our source of truth for user and group membership. And if you used Okta before, you just treat advanced server access like any other integrated application. You would assign your users and groups to opt in advanced server access as a downstream application. And then once users are in Okta advanced server access, administrators can explicitly assign them to projects, which are a collection of servers and then their associated permissions. So this is where we can really start to apply policy, and strict role-based access controls. And you might have automation here to add and remove users to groups or to provision specific entitlements. This is where the automation pieces really start to kick in.

Ivan: But the way this really works across large scale distributed cloud environments is through our server agent, which is deployed across every instance or server that's enrolled with our platform. So this server is really there to manage the local user and group accounts and local policies on that machine. And that agent is communicating with our backend API periodically for any changes on the Okta side. And then it's going to make an update on the local machine near instantly.

Ivan: Now what's key here is that because of that direct relationship between a server and the Okta backend, this can be done across tens of thousands of servers in the same manner as it would a single server. There's no intermediary services to run. There's no directories to keep in sync. It is that direct relationship. And that's why we talk about scale, because you can spin up thousands of instances and have this agent managing the accounts, and as the infrastructures are spinning up and down, you have near instant lifecycle management capabilities. That's why we talk about this so importantly from shifting identity left is because it's all near instant. It all happens at scale. And that is really how we're trying to run the cloud.

Ivan: Now what this design enables for the end users is a more streamlined way to extend a single sign in experience, experience to your infrastructure resources. So we just talked about the lifecycle automation, which provides that automated onboarding and offboarding experience. So let's say you're one of those people that's requesting access. You are going to be granted privileges to log in via Okta in mere minutes, as opposed to potentially weeks or days with manual systems.

Ivan: So again, moving along this diagram, so our end users are going to run a lightweight client application. That's going to be there to interface with Okta and then your local SSH and RDP tooling to access servers. Every request is going to be independently authenticated and authorized by Okta against the policies that we talked about. And then once granted we have a backing certificate authority that's going to mince a short-lived credential tightly scoped to that user, that device. And then the server being accessed. That credential or client certificate is used in line SSH or RDP by that client application to establish a secure, direct connection with the target server. The agent on that machine is going to pick up that login event and audit it across your audit logs. And then, because that certificate is so tightly scoped in time, it's going to self revoke. So this is where we're getting rid of static credentials. There's no cleanup because that credential can only be used in the context of that independent login. This is all a very nice and elegant experience here that our customers really love because it's so familiar to them if they've been using Okta to log in to business applications.

Ivan: So if we're going to put this all together, everything that we've talked about across security, across DevOps, across identity in this context, we're going to have a very elegant approach to solving a lot of challenges that arise when dealing with large scale automated infrastructure environments. So the things that you're trying to accomplish with your DevOps teams that you might have been blocked, and we see this is just a short list of things that we've encountered a lot of that manual onboarding and offboarding that is a painful experience for a lot of our customers having to manage all credentials and just have an idea of which ones are out there. That's really hard to do.

Ivan: And then all of those kind of legacy systems that you have to continue operating. On-prem systems, those are clunky, they become barriers and blockers to automation. They definitely don't scale well. Not being able to consistently apply multifactor authentication, not being able to have the confidence that your policies are being applied across these environments, and then having limited visibility, all of these things are really challenging. And so if we can kind of take that concept of shifting identity left, obviously this is something that we promote with the Okta products, but first and foremost, think about the context of shifting identity left.

Ivan: What you're going to gain from a technical outcome perspective, this is pretty strong. You get that automated lifecycle management. I mean, that is huge. The ability to spin up large scale dynamic infrastructure environments and just have accounts and policies be there automatically, that's a huge win right there. But we do that in such an elegant way that we're going to get rid of all of that credential management pain. That is very nice. And of course, if you're still stuck operating a lot of these on-prem systems and you're trying to adopt the cloud, anything that you can operate as a service is going to help you out. It's going to remove a lot of the burden, a lot of the barriers that you might have as you start to scale up.

Ivan: And then we're just extending Okta. So all of what you're familiar with from an SSO and MFA perspective, we're just applying to infrastructure, giving you a nice central place to apply policy for role-based access controls all the way down to the command level from, from a pseudo entitlements perspective. And then we're going to audit everything so that you have a very clear audit log of who accessed what, and what they did on that machine.

Ivan: So all of this is really nice and elegant. If you haven't seen the product, I definitely encourage you to do so. You know, we've been taking questions here throughout. So what I would encourage you to do is visit the Okta website, learn a little bit more about the advanced server access product. And if you'd like a more personal demo, reach out to your account team, and we can set up a time to really walk through the product in detail. We can get a handle of what your infrastructure environment looks like today, what some of the things you're trying to accomplish as you spin up your own DevOps programs, and hopefully we can help you along the way. So with that, I'd like to thank everybody for joining this session and hope you're enjoying our virtual Oktane. Cheers