Tim Hobbs - DevOps & Service Layers

We've come a long way today. I'm going to talk about IAM and DevOps and how those come together in what we do at service layers. Fundamentally, IAM is a tool. IM is a tool that we want to use to accelerate the business of a customer. So IAM is if we treat it as a, a single layer in the entire stack, we've seen this morning that there is a stack from infrastructure all the way up to the users. If we treat it only as one layer, then we isolate what we can do to only that layer. So with DevOps, we, we look at crossing those boundaries of the layers. So we do all of that to make things faster, to deliver once upon a time in the world of IAM, we would take months or years to deploy. As we've just heard deployments, 20 times a day is much better. That's what we want that allows us to respond to, to the business, to the users, deploy features, but also deploy security and deploy security fixes. This is the world of IAM. It's broad, very broad. There are a lot of different topics here. There's IAM for consumers, there's IAM for business to business transactions. There's the internet of things, which is bringing a different kind of IAM. If every thing has an identity, then how do you ensure access for every identity of everything?
That's not a small problem. Also, we need to integrate as a company, you need to integrate your IAM solution with many partners, many external organizations. So it's not simply within your company that you need to implement security and access control, but also how your users or how the identities move from partners to you and from you to partners with IAM, the goal is enforcing access. And in order to do that, there's a cycle. So this cycle of gathering requirements analyzing, implementing, and enforcing happens repeatedly. The question is, how often does it happen? If it happens once at the beginning of the six month project, six months later, you may be outdated with what you thought you needed to secure or protect against the technology changes in the meantime. So we need to move from multi-year implementations to implementations that take a little bit of time that are very responsive and incur a small amount of difference between the planning cycle and the implementation cycle.
On the other side, DevOps has this mentality that instead of handing off from development to operations, we integrate these teams and by the way, quality assurance or tests or security scanning, all of these things are part of the cycle as well. So DevOps is, is vertically integrating these previously horizontally separate departments or roles. And this doesn't mean that we'd lose security. And it doesn't mean that we give everybody privileged access, but it means that we make things quicker to deploy. We automate everything we can, and we'd let people be independent when it's appropriate within the security controls that we, we allow and then measure it. So let's have a cycle let's measure, let's implement, let's measure again, change something and implement again, but let's do it quickly. If we bring IAM to DevOps, then what, what does that mean? Well, IAM is an application two, so let's treat it the same. Why should we have two different processes, one for implementing IAM and access control and a completely different one for building and deploying applications.
Instead of developers on the IAM side. In most cases we've seen as an integrator in most, in most cases, we're not doing a lot of development, but with thousands of configuration options in every single IAM product, there is a lot of opportunity for mistakes and a lot of opportunity for not understanding the tool you're working with. So IAM is more config ops than DevOps, less development, more, more configuration. There is still some development. There continues to be custom integrations with many different systems. We want to configure the IAM products, the off the shelf products to behave. As we expect to implement our own company's business processes, integrate with all of our partners, not the general partners in the world and on the op side. What this means is that the, the IAM products are not always designed for cloud ready infrastructure. So we just saw a great example of the migration from hardware machines, to IA infrastructure, as a service to software, as a service. And if everything is the same, if everything is cloud ready, if everything is Kubernetes, if we paint the world Kubernetes, then a lot of automation and a lot of tooling becomes easier. So from our perspective, that means IAM products need to work within a Kubernetes ready environment. They need to be packaged. They need to be dynamically scalable, and they need to discover each other automatically. There cannot be manual configuration of the number of servers I'm going to deploy
In order to get DevOps working. What do we need to do? Well, we need to start by using the same technology. If we use fragmented technology, then it takes us longer and increases our complexity. So normalizing the, the technology stack allows us to all be speaking the same language, using the same tools standardizing on this, reduces the variability in, in what we deploy and the problems that we face. We then bring DevOps to all at all facets of the organization. So within our organization, we created the entire organization based on the principles of DevOps. And therefore we didn't have a lot of time to do this. We didn't need to do this. We said, this is the way it is done. This is the way this organization will run under DevOps principles. And therefore we focused on automating delivery of infrastructure, along with applications, along with configuration, with the goal of providing self-service capabilities, not only to end users, but to the developers or the application deployers or the integration consultants that are looking to deploy the IAM products on a continuous deployment system.
Again, we can use all this for IAM. So DevOps says, let's do all these things. Yes. IAM tells us this too. The first thing an IAM vendor will tell you is first, get all your identities in one place. Next let's use that same IAM system everywhere. Well, this is the same methodology. So IAM with the DevOps mentality, it means that our IAM experts and deployment engineers are the same team. The principle of you build it, you run it here. It's a principle of you configured it. You also need to be part of the conversation of what infrastructure is necessary to implement that synchronization flow between your IAM system and an external identity store.
So the IAM expert or the IAM configurator is responsible for much more than just using a machine. That's already running software. They're responsible for how that machine responds under productive load. So that means they need to be part of determining what infrastructure is necessary. What are the resilience requirements that we have? Must this be 100% available? If so your configuration must accommodate this. Every system that is deployed, every instant that is scaled up and scaled down must have the same configuration and must use the configuration that was designed to handle a dynamic environment. And on top of this let's layer the features that we want, if I want to pass identities to my partners, then that feature needs to be part of the configuration. And finally, if there, there are specific business processes that need to be integrated, let's make this part of the flow as well. And all of this is a version release. And now we know that at this release, I have this, these features, which expect to have this infrastructure profile, which include all of my unique business processes that I said to my users would be available in this period of time or this release.
What that means for us is that everything is code
Everything. The configuration of the infrastructure, the configuration of every instance that runs the configuration of the products that run within the instances, the configuration of the monitoring and logging for every single component in every single instance that gets deployed. All of this is code. All of this is versioned. We can always roll back to what we did before. When we find something that went through our testing, because we didn't write the test for it. Okay? All the tests are version controlled. When you implement a configuration, implement the test that verifies that it's acting as you expect, and it's not acting as you don't expect. So both sides, the happy path and the malicious path let's protect against both. And let's verify that when we are going to deploy this, we check that it does what we expect before it goes live. So we start with infrastructure. We have automated deployment onto Kubernetes infrastructure running in any cloud environment. So we determine which components we want to run, which IAM product, what logging stack, which metrics do we want to gather and, and report on. And we deploy this onto Kubernetes. We make a Kubernetes cluster or many clusters.
We can isolate by namespace, or we can isolate by cluster. In many cases, we isolate by cluster because namespace isolation within Kubernetes, unless you're using a custom networking stack is not quite enough. It's pretty good. And it's getting better, but it's not quite enough. When we start talking about VPN connections to a development environment versus a VPN connection to a production environment, to talk to a legacy system. Many customers want to have not just name space isolation within Kubernetes, but they want physical networks separation between environments onto that infrastructure. We start with some operational components. So all the things that go around I am.
How do you gather data out of this system? That's authenticating and authorizing users, where do the logs go? Which logs are important for keeping for a long time audit logs. I must keep a long time. Operational logs have a shorter lifetime, but it's important that I gather all of them along with the events of when something was deployed or changed or scaled up or scaled down, or when I suddenly have so much load that I'm now driving components to do things they are unexpectedly doing. And this goes to their, the outlier analysis that we just heard about monitor the systems for their operational health, but also for their functional health and have an event driven system that lets us respond in real time to what is happening.
And on top of this basis of infrastructure and operational components. Finally, we put some IAM functionality. So finally we're putting single sign on. And finally we're deploying the functionality of profile management or authentication or Federation, but it's just another application. It's very important for us that when we deploy components, they are automatically discovered and automatically hook into the existing logging metrics and inventing systems that are there with off the shelf. I am products. That means that many times we need to help with this. And we help in two ways. One is we help by building the glue. And the other way we help is by providing very clear feedback to the, the IAM vendors indicating where there are deficiencies for a cloud ready environment.
And this is all part of a, a continuous delivery methodology. So every time we make a configuration change, this goes into source control. This goes through a build test and verification cycle, and then gets approved for deployment to an environment, whether that's a development or integration or production environment, we decide which version of the functionality want to deploy every single time. And as often as we want to, and because everything is code, if we want to test variations of our configuration, or we want to test variations in the configuration of the infrastructure or the ability to respond to dynamic load, that also is code. We can create a branch and deploy an entire parallel stack where we can verify or test or see what will happen if we change something. And that gives us a lot of flexibility to create playgrounds where we test things out and then decide if we want those tests to come into the mainstream. So this is a little bit different from AB testing that happens, but AB testing is also possible, but this is really a create a completely different stack to try out something else, try a different configuration, a different version, determine that the functionality meets your business requirements before you agree that that should be part of your production deployment.
So bringing this all together, it means that there is, is a, a pipeline for continuous delivery, a component based and service oriented architecture that allows scalability and flexibility. And because of this, we can deploy this to many instances, many clusters, many geographic locations, all with exactly the same configuration. So there is no variance in the configuration other than the destination of where to deploy it. And this works across multiple cloud providers anywhere there's Kubernetes. So we were lucky we could start our journey at the Kubernetes plateau and say, Kubernetes is the minimum. And now that all the data center is the same. Now let's manage what goes on to that data center, that software defined infrastructure
At service layers. We've taken this idea of the pipeline and this idea of continuous deployment. And we've, we've started with the single pipeline and we've identified that the single pipeline is a long control loop, and it's not responsive enough. We need to break this into smaller control loops, smaller deploy measure, change loops for each of the different components so that small changes have small impact instead of a small change, having a large impact across an entire deployment. And that lets us do many deployments with differing configuration. Anytime we want here, I want to leave you with, with two things, treating operations like a product team means that everybody's following the same rules. So the, the result of the ops team is infrastructure. And if that is operating, as you expect, and it is measured, tested to do what is required, that's success. And can we really use DevOps for IAM? Yes, we can apply DevOps to anything, but IAM is software and IAM is very amenable to the DevOps methodology. One last thought DevOps does not mean not agile DevOps and agile go hand in hand. DevOps is really crossing some of those boundaries of infrastructure to software and managing all of those together.
Thank.