Tim Hobbs - What Connects DevOps & IAM

Architect at ISC consult and he will talk about what connects DevOps and identity management. Probably not that far away from my microservices presentation the morning. That was a great introduction this morning. Thanks very much perfect. Oh Yes, please definitely Will help you clicking through the slides. Super good morning. My name is Tim Hobbs. I am a microservices evangelist at IC consult and the cloud architect for service layers.

We created service layers because we see that the IAM strategy that all of you or many of you use needs to improve, and this needs to improve to meet the needs of your business now, and in the future, Martin explained this morning, how there's a potential for using microservices or containers or orchestration as a way to, as a technology to make. I am more flexible to make IM respond more quickly to the needs of the business. And this is what DevOps combined with technology can do. So DevOps is a philosophy and that helps us bring agility, but helps us bring speed to market or time to value.

This has been used for application developers for some time now, but we need to expand this just from the application development space, into the way we deploy many different things, many different systems, including IAM, IAM itself. We could redevelop it from scratch, but then we would lose the 20 plus years of experience that we have learning how to do what we do. Now. There are some really great products out in the market right now that do a lot of different things.

And if we're going to do something with IAM, we want to take advantage of that experience in those products and all the, the experience that built into those products by those great developers and those companies. So our goal with DevOps is to automate, to create configuration driven and resilient systems for IAM to support the applications that are used by the business to satisfy customers. IAM is a pretty broad collection of technologies. Standards approaches in all of these cases. They need many integrations with internal and external systems, which leads to complexity.

Also, every business has some different business process. And therefore, even though you may buy an IAM product off the shelf, you still end up doing a lot of customization, but we don't call it customization. We call it configuration and guess what? There's a lot of it. It takes a long time to configure all of the ways you want to do business into a general product.

Again, this leads to complexity and this leads to a situation where if you don't have repeatability and you don't automate this repeatability, you have risk and it's not just technical risk. It's business risk IAM has a known implementation cycle and we should continue this. This is a basic cycle of enforcing access for identities to the things they should have access to. So enforce the correct access, but then continue to evaluate reimplement and reapply the access that you want to the current state of your business.

Current state of your system, this continuous integration and implementation cycle must continue and should continue. The only question is how quickly do we do it? If we have a six to 12 month cycle time, we have a very slow response time to the needs of the business. So this has to be radically improved. DevOps is a strategy that can help us do that. So DevOps has a concept, brings things that brings departments, areas, skills that traditionally have been separate together. This doesn't mean that everybody has to be on the same team and know how to do everything.

It simply means that development can't build something and then be done with it until somebody else tells them. There's a problem. Fundamentally DevOps is about communication and it's about better communication between your development team, your quality assurance team and your operations team. DevOps also has some other good ideas like automate everything. And this automation is not just so that it's faster it's so that we don't have repeatable mistakes. We just heard how lengthy the process can be to perform a manual search in many different systems.

Of course, manual anything is generally slower than digital. Anything, computer driven, anything. So automation is a fundamentally important concept. If we want to do things more rapidly. So DevOps teams automate everything they can, and DevOps engineers are more responsible. We give them the appropriate responsibility so that they could do more than just commit some code and then wait for somebody else to approve it.

We, if we trust them, then we give them the ability to commit the code and deploy the code and deal with the remediation. If that code doesn't work properly, DevOps, DevOps, engineers need to not only build code and deploy it, but they also need to build the tools to measure whether the code is effective and is meeting the original business requirement. So let's build components that meet business requirements, not components that are existing for their own sake, and then build the tools to measure your business drivers and compare that to what was deployed.

If we now apply this mantra to IAM, we do a lot less development because IAM is an application too, but IAM, if we use an off the shelf, product needs configuration, not development. Usually we may need some development. There are many systems that don't comply with standards that we must integrate with. So not everything is standards driven, although that would be fantastic. And our traditional development team is now a team of IAM experts.

People who know these IAM products and who are professionals at configuring the products to meet the business processes and the business requirements that you want to see implemented. So really with IAM, we're talking less about DevOps and more about config ops, lots of configuration, and only some development we want to configure how the product behaves. So all the operational characteristics, the nonfunctional characteristics of the product, we want that to be correct tuned well. So the product is scalable and reliable and resilient.

We want to include the processes of the business, which are specific to each business. We can generalize for an industry. We can generalize for a regulation like GDPR. We can generalize for an industry like healthcare or finance. And in some cases, that means that the configuration for that particular use case is reusable. But it's only reusable. If we put it somewhere that we can re reuse it. If we need to manually do this every single time, we continue to have a long implementation cycle. We continue to have the same problems that we're trying to get away from.

And that application teams have already gotten away from also IAM deals much more with system integration. So IAM is touching a lot of systems and not necessarily the, the system of record for everything regarding identity and access. In many cases, there are external systems. We traditionally say, well, the HR system is not the IAM system. It could be, but in many cases, it's not many, in many cases, that's a separate system that needs to be communicated with. So system integrations are a significant aspect of many IAM implementations. The ops aspect of IAM.

We think it's really important that we take IAM products and we refactor them for the modern data center. And that modern data center looks a lot like what we heard this morning, containers, orchestration, dynamic, scaling service, auto discovery. These are all components of what we want to see in our data center. We should apply this to IAM. If the IAM products that we see right now, don't do this. Let's make them do that.

Let's put the pressure in the correct place to help the IAM vendors move towards a product architecture that supports the way we want to run the data center, which gives your business flexibility. It's all driven by the business. It's not driven by the data center. I hope unless your business is the data center. That's okay. The methodology we have taken is that everything is code. We version control, everything we deploy.

This means the configuration of the infrastructure necessary to run one or several IAM products combined with all the microservices that need to integrate them or go along with them or mask APIs that are proprietary. This includes the deployment pipeline or the process for deployment. And this process is driven by your business. You decide which stages, steps, gates, approvals that you want a deployment to go through, to go from. I have an idea.

Show me a prototype to I've deployed that into production and it's available to my customers or maybe available to some of my customers because it's an alpha test, a beta test, a rainbow deployment. We take all the IM configuration and we put this into source control. So we feed the source controlled version, controlled configuration for IAM components into those components. When they're deployed, this allows us to version control a change to the configuration and therefore the operations and behavior of the IAM system itself.

And I say IAM system, it would be great if this were several different microservices for individual IAM functionality, functionalities use cases also as code all testing, functional operational security tests, all monitoring configuration, logging, auditing, monitoring of the systems internally and monitoring of the systems from the outside Here on the left, you see an example of, of how we do this. And we say, here's what I want my production cluster to look to look like. So let's start with infrastructure. What do we deploy first?

Well, what we do is we decide what we want to do. We have an expert configure this. We create a cluster and our cluster is Kubernetes. We've decided that Kubernetes is a great orchestration system and it's fundamentally suited to the modern data center supported by all the big cloud providers. And many people are running it on premises. So let's put in what we want for infrastructure into our source control. We check it in, we run it through a pipeline. We then deploy it.

We happen to use giant swarm to create Kubernetes clusters, but you can use anything you want and create this cluster on AWS or Azure or Google cloud. It's all the same. We're really painting the data center with the brush of Kubernetes. And this gives us one method to manage the infrastructure itself with code next, let's deploy some operational components. These are components that we need, but they are not IAM components, Elastic search Keana, Prometheus Gana, automatic certificate generation. Let's use a microservice to do that.

Let's tag resources in AWS so that we know exactly which resources in our infrastructure. We have dedicated to which customer so that we can identify cost tracking for everything that we deploy as a microservice. Next let's deploy some IAM. I want to deploy for drop am. I want to deploy a skill service for Alexa. I want to put in the components and the features that meet the use cases of the business for IAM and all the little bits that need to go in between and all those little bits, let's put them in as microservices. And if we can, let's take those IAM products.

And because we're in an infrastructure as code environment, we can deploy multiple instances of a single product and use them for different pieces of functionality. Even if the product isn't ready itself to separate those functions as microservices. So we can hide the monolithic architecture of a product behind a controlled deployment. We automatically do this. And then finally, let's do it over and over. Let's deploy all of the systems we need combined with the correct configuration.

We want the version of the configuration we want and the configuration for the features that we want and it's complex. But we think this architecture works really well. And so far it has. So we align the business process for the release and the operation. We version control every component we version control, every configuration that's put into that component or fit into the component. And we version control, feature blocks that fit into the components as the basis to meet business use cases And package it all in containers, because that makes it easy to deploy in an orchestration system.

So let's do this for one data center for many data centers, either way. It's just a matter of how many times do you want to deploy this and how do you want to have them connected? And I'll leave you with this. It doesn't matter if your apps are Greenfield, brownfield or legacy, DevOps can be applied to any system. So it doesn't matter what the actual architecture of products are. It would be great if everything was a microservice, because that makes, that gives us a lot of flexibility, but we can apply DevOps principles to anything. And that's what we've done at service layers.

And that's what we are finding effective. Thank you.

So, Tim, thank you very much for your insights and the details you brought to the stage, which I didn't do my keynote. So I prepared the ground for you. Yeah. Thank you. I think it was a good fit here. And so we already have a couple of questions here.

And so, Yeah. So Yeah, I think the first question is a good one. What about segregation of duties we used, we should be afraid of developers working production environment. Yeah. How about separation of duties? Isn't important. Of course it's important. It doesn't go away. When we have requirements for separation of duties, let's implement them into the process that we want to use for deployment.

So let's make that the process of how we deploy and let's make that let's automate the process so that people are invoked when they need to be in order to satisfy separation of duties, constraints. So really separation of duties is a constraint on touch production. And if we say don't touch production, then what do we want to do to prevent that separation of duties is one of those aspects just as a release control is only release on Saturdays. Okay.

If, if that's what you want for your business, that's a constraint you put on your release process. Okay. And the question instead of putting management components in Kubernetes glasses or others, do you see ILAs as the future where you don't have to worry about it? I think that's probably in between our two Talks. Sure. So of course I can talk about this because we provide IDAs, we provide identity as a service, but identity as a service so far has been relegated to identity.

And as a service is so limiting that you don't have the ability to customize for your business process or to integrate with your existing systems. And we think that has to change, which is why fundamentally we said, well, we like the idea of I, but we also know from our experience in the, in the past that a high level of customization is usually necessary, especially with enterprise customers. And in many cases with specific industries, I, I would see it a little different from my perspective. I think we need both.

In fact, we need standard things. You can get service, but we also need the flexibility to do I look at more at where does, where does the standard traditional on premise IM have to evolve? And I think from that perspective, it's super important to look at microservice architectures Agreed. And Well's question. I think that that's so, and probably the truth is somewhere in between us Usual.

Well, this is why our first choice is deploying the cloud and we'll manage everything for you. And our second choice is you bring your own cloud, you bring your own licenses, you tell us which product you want to use, and then we'll help you run that. So we'll also deploy into an on-premises environment. And do we see policy driven, configuration driven authorization as an enabler? Absolutely. Martin talked a lot this morning. That was a perfect short answer. Martin talked a lot this morning about authorization between services. This is fundamentally lacking.

This is something that service mesh technologies are just starting to, to take on board, not just for authorization of HDDP requests, for example, but also at a lower level. So this is a place where, yeah, there's a lot of work to be done, but there's a lot of opportunity.

Okay, perfect. So thank you again, Tim for this. Perfect. Thanks so much intro to the topic you want this. You don't want, I want this, I want this. I also take your hand. Not a problem at all. So thank you.