The Right Time for Adoption: DevOps Trends with Cerbos' Alex Olivier

In this episode of ShipTalk, host Dewan Ahmed sits down with Alex Olivier, the CPO and Co-founder of Cerbos, to explore the evolving landscape of DevOps and the critical role of authorization in modern software development. With a wealth of experience designing enterprise solutions, Alex shares his insights on how to balance developer productivity with security, making the case for adopting tools like Cerbos at the right time.

Alex's journey in tech has taken him through esteemed roles at Microsoft, Qubit, and various startups, where he has consistently focused on enhancing the developer experience. His expertise spans core components such as authorization, data management, and security, making him a valuable voice in discussions around modern DevOps practices.

In this episode, you’ll learn about:

• Cerbos and its Mission: Discover what Cerbos is and how it aims to streamline authorization processes, empowering developers to build faster and more securely.
• Balancing Speed and Security: Delve into the challenges teams face when trying to maintain rapid development cycles without compromising security.
• Optimal Timing for Adoption: Alex discusses the right conditions for adopting new tools and technologies, ensuring that organizations make informed decisions that align with their goals.
• Emerging Trends in DevOps: Gain insights into the trends that are shaping the future of DevOps and how organizations can stay ahead of the curve.
• Getting Involved with Cerbos: Learn how listeners can engage with Cerbos and contribute to its mission.

Join us for an enlightening conversation filled with practical advice and expert insights that can help you navigate the complexities of DevOps and authorization.

Transcript

WEBVTT

1
00:00:03.850 --> 00:00:22.269
Dewan Ahmed: Hello, everyone. Good morning. Good afternoon. Good evening. Someone once told me. Time appropriate greetings catches them all. My name is Dewan. I am your co-host for the ShipTalk podcast where we talk about the ins and outs, ups and downs of software delivery.

2
00:00:22.350 --> 00:00:33.280
Dewan Ahmed: And today I'm beyond excited to have with me, Alex Olivier, co-founder and CPO. Of cerbos dot dev. Hey, Alex, how's it going.

3
00:00:33.710 --> 00:00:37.900
alexolivier: Hey? Thank good to see you. Thank you for having me looking forward to our conversation.

4
00:00:38.130 --> 00:00:42.360
Dewan Ahmed: Yeah, absolutely. Did I say it right here? That's the right way to say it.

5
00:00:42.360 --> 00:00:49.349
alexolivier: Yeah. Absolutely cerbos dev for those that are into your kind of Greek mythology. Cerberus, the three-headed dog, the gatekeeper

6
00:00:49.410 --> 00:00:51.860
alexolivier: authorization security. That's the route.

7
00:00:52.570 --> 00:01:10.180
Dewan Ahmed: Before we start. I must say you have a fantastic setup like your light lighting, and in your background you tell our viewers and listeners like, what do you do for online meetings and podcasts? And how do you have these crisp settings.

8
00:01:10.580 --> 00:01:30.290
alexolivier: Great. I wish I had like an intelligent answer. Firstly, this is a fake background, which I think nowadays I think everyone's kind of used to these, you know. You can kind of tell when you wave your hands. Your fingers don't quite look right, though, the rate that these, like Sora and these video generation Llm models and such are coming along. I'm expecting to see some pretty funky backgrounds soon.

9
00:01:30.564 --> 00:01:36.910
alexolivier: But big thing for me, like in the past life. I did do like sound and audio and light, and all that sort of stuff for sort of productions and things.

10
00:01:37.230 --> 00:01:52.369
alexolivier: Is having a good mic people can forgive bad video. People can't forgive. Bad audio, I would say, is the main one, though problem with a very sensitive mic is, I have a 9 month old, daughter, and you can hear her screaming in the background sometimes so apologies in advance that crops up.

11
00:01:53.510 --> 00:02:04.689
Dewan Ahmed: Same thing for me. My son is at school now, but if he's not like he might knock on my door time to time, and I have a nice like. We are open. Sorry you're closed. Sign on my door.

12
00:02:04.690 --> 00:02:05.509
alexolivier: Oh, nice!

13
00:02:05.750 --> 00:02:13.199
Dewan Ahmed: He said. He suggested that just like the shops outside, they have this sign. He needs a sign to know when he can knock on the door, and when he can't.

14
00:02:13.200 --> 00:02:26.799
alexolivier: Yeah, I've kind of gone down the habit of like home automation as well in the limited free time I have. And one of the things I've been wanting to do is like, hook up my calendar to home assistant, and then use home assistant to trigger like a light on and off outside my office just haven't had time yet.

15
00:02:27.138 --> 00:02:28.830
Dewan Ahmed: That is, that is cool.

16
00:02:29.070 --> 00:02:34.459
Dewan Ahmed: So tell us more about your background, and and how you co-founded cerbos dot dev.

17
00:02:34.840 --> 00:02:48.510
alexolivier: Yeah, absolutely. So my background, I'm a software engineer at heart. I spent way too long in my teenage years, writing bad software and sort of fell into a career. I guess you could say so.

18
00:02:48.510 --> 00:03:05.270
alexolivier: you know. Started off doing freelance consulting type stuff ended up at Microsoft for a bit when I was at Microsoft I was doing consulting as well, but working predominantly with large enterprise businesses. So name a big bank. There's a good chance I worked with them for a bit. The health service here in the Uk. As well.

19
00:03:05.290 --> 00:03:09.719
alexolivier: and the areas I was working on was like application, architecture, and security, particularly

20
00:03:10.180 --> 00:03:28.280
alexolivier: after realizing I didn't massively enjoy working in a company of 100,000 people. I then went into the world of startups and went through half a dozen startups in various different industries, e-commerce, finance, fitness, supply, chain, but always very much focused on the data and infrastructure side of things, and moved into

21
00:03:28.460 --> 00:03:38.149
alexolivier: the dark side of product management, which is, I know, is a very loaded term. But one of the commonalities across all that experience is that there were. These systems had to keep building

22
00:03:38.450 --> 00:03:41.560
alexolivier: and keep implementing, and there was no real.

23
00:03:41.600 --> 00:03:50.129
alexolivier: anything special about them. They were just like commodities. So things like authentication, things like logging things like authorization and permissions, and

24
00:03:50.240 --> 00:03:57.000
alexolivier: having done that enough times, and in one case, in one company, we had to build that system 3 times in the space of one year, because the requirements kept changing.

25
00:03:57.150 --> 00:04:14.779
alexolivier: I got more and more annoyed that I wasn't like an off the shelf solution. That kind of solved that problem. So myself a couple of my old colleagues, in fact, one of my former Ctos said, Right, let's do this. Let's go and build a company solve this problem once and for all for developers. And that's sort of where service came from

26
00:04:14.940 --> 00:04:17.209
alexolivier: 3 and a half years ago. Now I've been going a bit over that.

27
00:04:17.320 --> 00:04:19.940
alexolivier: And yeah, basically

28
00:04:20.110 --> 00:04:27.349
alexolivier: fell into this because I got annoyed at having to spend all my time thinking about something that wasn't really relevant to the core business. And now I spend all my time thinking about it.

29
00:04:27.950 --> 00:04:39.979
Dewan Ahmed: That is nice. I can almost relate, not co-founding a company, but of course, working at big companies with hundreds and thousands of people, and also working at much smaller companies.

30
00:04:40.080 --> 00:04:57.909
Dewan Ahmed: You already touched on like the authorization and service, and and the link to to the the logo we have. But for those of you of the listeners who don't know about servers. Could you please tell a bit more about what servers do, and how it fits in the the devops, ecosystem.

31
00:04:58.240 --> 00:05:02.280
alexolivier: Absolutely so. 1st off, I really dislike

32
00:05:02.310 --> 00:05:18.430
alexolivier: the word authentication and authorization, because they sound very, very similar, and it's very easy to get those 2 muggled up. So service we do authorization, not authentication, and to not use those terms, and not to use the awful contractions of auth n, and auth Z.

33
00:05:18.520 --> 00:05:36.339
alexolivier: When you think about authentication, this is about challenging a user to provide a credential. They provide that credential username, password, passkey whatever. And you verify an identity. You now know who this person is. Authorization is. The next step which okay, once you now, who know who someone is, what can they actually do inside of the system.

34
00:05:36.630 --> 00:05:48.689
alexolivier: And this is a component that you need essentially, at every layer of your business, ultimately. So down from if you look at it from a devos perspective. You've got to make sure that your infrastructure people that

35
00:05:48.760 --> 00:05:59.939
alexolivier: access it to, you know, do tasks first, st you know who they are, so they authenticate by some mechanism. But then also, should they be allowed to do this, so are you a manager? Are you an editor? Are you viewer, or an admin etc.

36
00:06:00.230 --> 00:06:24.590
alexolivier: And then, from the infrastructure up, you need that essentially at every level. So the base infrastructure who can get access to your cloud environment. Your Kubernetes cluster, who gets access into the cluster into which namespaces, and then, where servers particularly focuses, is in the actual application layer itself. Both your internal teams, but also your end. Users need to have permissions and controls around what they can do inside of a system. We're all familiar with signing up to some new

37
00:06:25.020 --> 00:06:36.529
alexolivier: whizzy Sas tool that makes our lives much, much easier, and we go and invite our team members on, and we need to give them roles. So this person's an admin, this person's a viewer. This person's a manager, basically that component and the logic behind it

38
00:06:36.820 --> 00:06:47.800
alexolivier: effectively. It's kind of commoditized. You have some business rules you need to make sure that every request fits those business rules to make sure it's allowed or denied. And Servers is that engine that you can drop in to any part of your stack.

39
00:06:47.920 --> 00:06:53.269
alexolivier: and to solve that in a policy driven approach rather than just hard coding application logic, which is the

40
00:06:53.390 --> 00:06:55.470
alexolivier: go to approach, I would say.

41
00:06:55.530 --> 00:06:57.620
alexolivier: if you were to just start out.

42
00:06:58.160 --> 00:07:23.809
Dewan Ahmed: Yeah, yeah, that makes sense. A lot of times like concepts in software engineering, right? They're interrelated like, you learn something in one field. You can relate to something others. So for my friends, who are from the network engineering background, you might relate to something like a triple, a threat model where or triple a model, where you have the authentication, authorization, and auditing so like a lot of, or if not all of

43
00:07:23.810 --> 00:07:35.870
Dewan Ahmed: services, has some way to to do all 3 like you need to authenticate. You need to authorize, and, of course, as good practice, or nowadays you you must do some sort of auditing.

44
00:07:36.200 --> 00:07:48.619
alexolivier: Absolutely. And when I, when we kind of think about talk about this space, particularly, people know the Aa model, which is great, that's an amazing start. And there are a couple of kind of additions to that. I would say so when we think about

45
00:07:48.650 --> 00:07:59.629
alexolivier: the lifecycle of a request that's coming from one of your users or your internal services. Kind of hits. What's the cycle? And what's the journey that request has to go through for the actual action to happen. So

46
00:07:59.690 --> 00:08:07.049
alexolivier: you have some client. They are authenticated. Request comes in through your Api gateway. There's a Jdbt. Header associated with it.

47
00:08:07.180 --> 00:08:24.900
alexolivier: By the way, the authorization header in the Http spec really annoys me because that really is authentication, not authorization. But that's beside the point. So you have that bearer token, it goes to your gateway. You might have some coarse grain or medium grain authorization, where you simply check whether that token exists and it's valid, and maybe contains a scope.

48
00:08:25.350 --> 00:08:30.630
alexolivier: and then your gateway or service mesh will ultimately pass that down inside side of your application.

49
00:08:31.100 --> 00:08:32.959
alexolivier: Now, inside of your application.

50
00:08:33.030 --> 00:08:38.049
alexolivier: you effectively know when that request comes in a few different things. You know who the user is because it's authenticated.

51
00:08:38.130 --> 00:08:45.380
alexolivier: You know what resource they're trying to access based on the Api call. And you know what action they're trying to do. So if you create update delete are the common ones.

52
00:08:45.430 --> 00:09:00.060
alexolivier: But when we talk about authorization of the application layer. I always encourage people to think more about what the end user actions they're trying to do. They're trying to approve a purchase order. They're trying to download a report. They're trying to comment on some asset. Let's say those are kind of the more actions

53
00:09:00.200 --> 00:09:10.990
alexolivier: and the bit I'd kind of add in that journey is once, you know who someone is. You now need to know. The associated information with you. So Authentication Directory is what we refer to as then authorization, then audit.

54
00:09:11.160 --> 00:09:13.660
alexolivier: because once you've got an identity, you now need to be able to

55
00:09:13.750 --> 00:09:27.370
alexolivier: rationalize what that identity can do, based on what teams or groups or roles they're they're part of. So this is where your classic ldaps or ads come in, or even just your own application database that stores this person's in this tenant or in this team

56
00:09:27.490 --> 00:09:29.609
alexolivier: be able to do access.

57
00:09:29.880 --> 00:09:36.279
alexolivier: Then you have the authorization piece. So use that context who they are teams, group roles, resource and action. They're trying to do.

58
00:09:36.400 --> 00:09:53.720
alexolivier: And because now your authorization can be contextual, based on not just who the user is, but what teams and groups they're in, plus the individual asset or resource they're trying to access. So only the owner of this resource is allowed to edit it. You can go and inspect the object and understand. Okay, the idea of the user making the request is equal to the owner. Id attribute of the resource.

59
00:09:53.880 --> 00:09:57.539
alexolivier: And then you want to capture that in the audit which comes back to the audit audit side of things.

60
00:09:58.170 --> 00:10:14.189
Dewan Ahmed: Yeah. Great that you mentioned about, let's say, the existing clouds Ldap or their authentication layer, and how this could integrate. So let's say, some team is using something like opa. How do you say like this? Either is a replacement for that or complement to that.

61
00:10:14.790 --> 00:10:27.429
alexolivier: Yeah, absolutely. So when we started building out servers, we obviously looked at the market and looked at the tools available. Opa policy agent, as you don't know is a very successful Cncf project. If you're writing policy for.

62
00:10:27.460 --> 00:10:33.509
alexolivier: and controllers inside of Kubernetes, you're most likely writing open policies, those kind of things.

63
00:10:33.620 --> 00:10:35.570
alexolivier: and OP is a very powerful tool.

64
00:10:35.650 --> 00:10:39.719
alexolivier: and it can kind of do anything which makes it actually very easy to then shoot yourself in the foot.

65
00:10:40.141 --> 00:10:53.720
alexolivier: So where we kind of see opus, and when we see service used is open policy. Agent is is used very much for the infrastructure level. So be it the actual infrastructure itself, or the the cluster level side of things.

66
00:10:53.810 --> 00:10:59.389
alexolivier: and then, where service is generally used, is at the application level, because it's a much more focused use case.

67
00:10:59.460 --> 00:11:06.490
alexolivier: And what we did with Cerbos when we 1st started our initial hypothesis behind Cerbos was Oprah was in the right direction.

68
00:11:06.600 --> 00:11:10.769
alexolivier: But the language you have to use something called rigo is very.

69
00:11:11.240 --> 00:11:26.240
alexolivier: let's say it has a learning curve associated with it, and for the kind of the application use case. We wanted to make sure that this is something that was accessible, not just to a developer, but also to the people that ultimately hold the requirements, which is the product owner, the product manager, the security team.

70
00:11:26.586 --> 00:11:40.319
alexolivier: So we kind of originally took the open engine and then wrapped it and put our own policy language on top, which is just Yaml. And we didn't invent language. We just use something. People know. We extended it with cell a common expression language for defining conditions.

71
00:11:40.480 --> 00:11:47.590
alexolivier: and that kind of that got traction, and it kind of proved the model. And we ended up ripping out Oprah to generate our and created our own much more focused

72
00:11:47.760 --> 00:11:53.110
alexolivier: and performance ultimately engine, because we were already targeting the application permission use case.

73
00:11:53.270 --> 00:11:58.710
alexolivier: And so we very typically see Opa used alongside servers just at different parts of the stack

74
00:11:58.840 --> 00:12:00.730
alexolivier: and effort, and it gives a very kind of

75
00:12:01.160 --> 00:12:07.350
alexolivier: different experience. One's very devops focus one's much more business and security team focused, which is what servers does.

76
00:12:08.280 --> 00:12:30.599
Dewan Ahmed: Thanks for clarifying that. So now that we have some idea about voice servos, let's switch to the developer productivity. It's a common dilemma that like developer wants speed. But also there's security teams not so fast. So how do you see? Because you are in this space? How do you see this dilemma, like

77
00:12:30.790 --> 00:12:34.600
Dewan Ahmed: making developers move fast, but also with security.

78
00:12:35.040 --> 00:12:36.530
alexolivier: Yeah, absolutely. So.

79
00:12:37.250 --> 00:12:43.169
alexolivier: The alternative of not using some sort of policy engine of which, you know, there are some great solutions out there is you end up building it yourself.

80
00:12:43.670 --> 00:12:54.180
alexolivier: and you're going to end up wasting realistically a few months at minimum. Having done this myself, I've seen it take anywhere from a couple of months to a full year to build these systems out properly.

81
00:12:54.576 --> 00:13:00.379
alexolivier: And that would be to build a system that meet the requirements that come from the business or the security team

82
00:13:00.920 --> 00:13:12.250
alexolivier: at some moment in time, what inevitably will happen is, as your business grows and evolves the application of all permissions. So we're not talking about the infrastructure, but the actual application, the external service that you're providing to as a business.

83
00:13:12.280 --> 00:13:13.999
alexolivier: The requirements in there will change

84
00:13:14.300 --> 00:13:23.449
alexolivier: you. They'll change because you're adding functionality. And your sales team want to package up access in different ways based on how they want to sell it that particular month

85
00:13:23.940 --> 00:13:42.670
alexolivier: hopefully, not month, maybe twice a year. They might change the packaging. You might be scaling out the business to other parts of the world. And you need to start enforcing data locality and data access controls based on location. You might start reaching a point where you want to go and get your compliance certificates. So your sock twos, your iso, 2, 7 0 0 1. Those kind of things, both things. I've been through multiple times. Now.

86
00:13:42.790 --> 00:13:52.759
alexolivier: there's requirements in there that you have to meet from a security side of things. So you have to go and implement audit logs as part of that. So you'd be able to demonstrate, not only have, but also demonstrate to your auditor.

87
00:13:52.850 --> 00:13:59.520
alexolivier: I used to get dragged down to a dark, dingy basement every year by an auditor in a previous life, and had to demonstrate our access logs, which

88
00:13:59.650 --> 00:14:02.530
alexolivier: at 1st was grepping through S. 3, which wasn't a good look.

89
00:14:02.540 --> 00:14:08.210
alexolivier: I will admit but these are all kind of capabilities, you need to add, and if you spend time building that yourself.

90
00:14:08.670 --> 00:14:31.809
alexolivier: it's the same old story that every dev tool will provide you is you're going to waste time, and it's undifferentiated. You really should focus your engineering team on what you do as a business. And that was kind of the approach like you shouldn't be building. This thing to that extent servers the engine. The policy decision point this is called is fully open source. Grab off Github, fork it, Apache, 2 license. You're free to do with it as you will, and we have

91
00:14:31.940 --> 00:14:35.069
alexolivier: thousands of companies out there. Running services is today.

92
00:14:35.260 --> 00:14:47.459
alexolivier: So from a like a developer productivity perspective step one is, we save you building a whole engine. You just go and grab it. It runs another service. It's a little go. Microservice, Grpc. Or Http interface. You just hook it into your application

93
00:14:47.720 --> 00:14:57.060
alexolivier: at that point. Once you've done the integration once you can essentially hand off to the product team or the security team, or whoever wants to manage those policies.

94
00:14:57.320 --> 00:15:16.779
alexolivier: And you can basically give it back to the people that had requirements. Say, cool, we've implemented it. You're now free to evolve and change what these policies need to do. Obviously there's guardrails in there you can write full test suites against it to make sure things don't break, but really from a developer productivity, it's a 1 1 small piece of work which is to do the integration and have your devops team deploy it as a

95
00:15:16.870 --> 00:15:19.650
alexolivier: it's a helm chart or a cycle, or whatever makes sense for your system.

96
00:15:19.820 --> 00:15:22.200
alexolivier: And then you can basically hand it off to the people that

97
00:15:22.720 --> 00:15:43.879
alexolivier: are making the business decisions around what the policies need to be, and also can update those and evolve them and change them without having to come back to the Dev team. Every time you want to change the packaging or add some new clauses or checks in there, based on some new regulation you're relying on. So really, it's a developer productivity boost in the sense that you now have a 1 off job to do which is set up an integration.

98
00:15:44.070 --> 00:15:48.440
alexolivier: Once it's done, you can effectively be hands off. You don't need to think about authorization

99
00:15:48.620 --> 00:15:50.219
alexolivier: in too much detail ever again.

100
00:15:50.260 --> 00:15:51.959
alexolivier: There's always going to be edge cases. But

101
00:15:51.980 --> 00:15:53.490
alexolivier: that's primarily

102
00:15:53.610 --> 00:15:57.879
alexolivier: how we see servers being used in businesses, small and large. Today.

103
00:15:58.800 --> 00:16:05.129
Dewan Ahmed: And I'm sure, like you have seen many, many implementation of service, and like similar tools by engineering teams.

104
00:16:05.130 --> 00:16:05.830
alexolivier: Absolutely.

105
00:16:05.830 --> 00:16:10.560
Dewan Ahmed: What sort of like the right time to to

106
00:16:10.878 --> 00:16:15.050
Dewan Ahmed: out of this tool. And the context of the question is, so let's say

107
00:16:15.070 --> 00:16:43.729
Dewan Ahmed: I'm an engineering manager. I'm making my new hey? Like, you have to build a web app. Okay? Now we have the Poc. Now let's see if we can add a Ci, okay, now we have a Ci, so let's say, what's the right registry? And okay, now, CD, okay, now, let's make sure that we're using secret managers and so on. So like, slowly, this is evolving right? And then, maybe, like the Nirvana would be like, we're having everything from from metrics to logs and policy and authorization. So where do you see? Like the the sweet point

108
00:16:43.730 --> 00:16:45.790
Dewan Ahmed: point of adding these kind of tools.

109
00:16:45.790 --> 00:17:00.100
alexolivier: This is an excellent question that I don't get asked very often, so we generally see the adoption of what's referred to as kind of an industry and by the analysts as externalized authorization or runtime authorization solution at 2 points in time.

110
00:17:00.370 --> 00:17:10.910
alexolivier: 1st point in time is you're at the start of a new build. You know you've done your 1st Poc. You've kind of got an idea of what's going on. But now you want to kind of build it properly, as it were.

111
00:17:11.030 --> 00:17:17.130
alexolivier: And this is where we see the types of engineers and engineering managers and developers and product teams who

112
00:17:17.260 --> 00:17:31.100
alexolivier: have felt this pain before, and have in previous companies had to gone in and rip out how their access controls or permissions, or overhaul their permissions, worked previously. I know how much of a time sink, and how much of a pain and how much of

113
00:17:31.190 --> 00:17:39.259
alexolivier: unnecessary work you end up doing. And so it's like right, we're going to put something like servos or one of these other solutions in from day one.

114
00:17:39.580 --> 00:17:52.160
alexolivier: Initially, it's going to be a very dumb. It's going to do a simple rule based check. That's it. It's not very complicated, but the foundations are in there, and then you can kind of forget about it until your requirements change, and maybe you have to update the checks a bit. But

115
00:17:52.300 --> 00:17:53.670
alexolivier: the the

116
00:17:53.900 --> 00:18:02.590
alexolivier: muscle, the the muscle. Memory, is there in terms of having your application code, call out, do a permission check and get an answer back, which means you're now kind of decoupled

117
00:18:03.330 --> 00:18:10.609
alexolivier: the second time, and the second kind of cohort of people we see and come to us and and start adopting this and externalized authorization approach

118
00:18:10.720 --> 00:18:21.444
alexolivier: is when businesses are either going through a bit of a re-architecture so monolith to microservices, or we're now in this world. Or actually, we're going back to monoliths. But anyway,

119
00:18:21.900 --> 00:18:31.699
alexolivier: And essentially, you need to start breaking down your application into sensible components either to make them a modular monolith or to make them microservices either way.

120
00:18:32.100 --> 00:18:33.999
alexolivier: And one of the 1st components

121
00:18:34.050 --> 00:19:03.989
alexolivier: that you pull out is authentication. So you go and set up an Idp, you know. If you want to keep it open, source, you can go and use something like key cloak, super tokens, or many other ones that are out there today. And then once you start bringing kind of extracting that out, then one of the next is like, Okay, well, then, how do you manage permissions? And as soon as you move to microservices, you now potentially have services written in different languages. You might have something in Java. You might have some stuff in Python because you don't do AI.

122
00:19:04.060 --> 00:19:14.730
alexolivier: Then you now need to. Okay. We need this sort of common service that handles the permission checks. And this now, by the fact, you're in a heterogeneous

123
00:19:14.750 --> 00:19:16.319
alexolivier: microservices architecture.

124
00:19:16.330 --> 00:19:35.009
alexolivier: It can't be like something you just put in code inside of each service itself, because every time those requirements change, you're going to have to go and update that if else case switch style logic across N number of languages which is always going to cause a bit of a pain. So that's the next point where externalized authorization kind of comes up as a kind of key thing to do.

125
00:19:35.010 --> 00:19:50.710
alexolivier: So it's the new builds. Get it in from the front day. One not worry about it again, or it's the re-architecture phase. There's a bit as well. If you work in regulated industries. The importance of doing this sooner rather than later will vary. If you're going to. You know, we have case study with

126
00:19:50.950 --> 00:19:52.350
alexolivier: a Fintech company

127
00:19:52.430 --> 00:20:05.949
alexolivier: in Southeast Asia. They actually managed to get their banking license 3 months faster because they were using surbos for permissions because of the audit log, which is just such a hard requirement for those industries. So there's always a bit of an industry and a vertical lens to apply on the importance of such things.

128
00:20:07.290 --> 00:20:12.649
alexolivier: and kind of those are the 2 points we generally see this kind of approach being implemented.

129
00:20:13.900 --> 00:20:15.709
Dewan Ahmed: Yeah, I I can.

130
00:20:16.080 --> 00:20:30.939
Dewan Ahmed: I can totally understand, like the experienced eye point, like you felt this pain before. And then whenever you start a new project you start to look for for that further. So I don't want to get burned by this. Oh, yeah.

131
00:20:31.020 --> 00:20:44.149
alexolivier: Yeah, like. And like, today, if you go back like, 10 years ago, you need authentication in the system cool, I'll go and create a user table with a username and password column, or hopefully, a sort and hash column and all good. But then

132
00:20:44.200 --> 00:21:00.650
alexolivier: you fast forward to be now in a world where you have to support single sign on. You have to support social logins, you have to support passkeys. You have to support. Xyz. Are you going to spend time building all that? Or are you going to go and pick a solution off the shelf that has all that baked in, and you just plug it in, and more often not. Those solutions are actually open source, much like servos, which is great.

133
00:21:00.850 --> 00:21:02.690
alexolivier: And you know

134
00:21:02.720 --> 00:21:19.580
alexolivier: we're if you think kind of where things are financially in the global markets, money isn't necessarily as cheap as it used to be. So you really need to make sure, as a business. What you're spending your time on is really focused, and you're not reinventing the wheel for these components that you can just pluck off the shelf and plug in.

135
00:21:20.610 --> 00:21:23.870
Dewan Ahmed: Totally. And then we're also not talking about our human users only.

136
00:21:23.870 --> 00:21:24.430
alexolivier: It'll be more.

137
00:21:24.430 --> 00:21:41.369
Dewan Ahmed: Was primarily our human users. Now it's human users and machine users which would be like 10 x, or 100 x, or even 1,000 x, and those are short lived. So you constantly keep creating short, lived tokens short lived services. So that authorization layer just becomes that more complex.

138
00:21:41.730 --> 00:21:46.549
alexolivier: Yeah. And you know the buzzword around this. I say, buzzword, it's quite an old idea now, but 0 trust

139
00:21:46.650 --> 00:21:52.839
alexolivier: never trust, always verify. You need to do authorization, preferably policy-based authorization everywhere in your stack.

140
00:21:52.930 --> 00:22:10.939
alexolivier: And those identities like you say, aren't just necessarily humans. They could be non-human identities. They could be agents, and we're seeing more and more service to service authorization as well. But you want to actually pass through the top level. You know, the end user making requests, pass their identity down the chain, but then also have each service authorized to each other.

141
00:22:11.000 --> 00:22:20.989
alexolivier: And so there's an explosion of identities and different surfaces to authorize across from the bottom of the stack all the way up to the end user

142
00:22:21.120 --> 00:22:23.150
alexolivier: and having a a

143
00:22:23.470 --> 00:22:36.179
alexolivier: policy language and a policy engine that is kind of agnostic to whatever the identity is, is going to be a real advantage to you, because you'll have one way of doing things that works across human, non-human AI agents, etc.

144
00:22:36.330 --> 00:22:37.990
alexolivier: In your in your architecture.

145
00:22:38.900 --> 00:22:45.279
Dewan Ahmed: And what would you say? The options? Because nowadays what we don't lack is we don't lack options.

146
00:22:45.620 --> 00:23:03.110
Dewan Ahmed: Many options when it comes to dev tools, security tools, scanning tools. So let's say, a team wants to get started with their the triple. A like there are, although you're in in the specialization of authorization. You have experience with the other 2 A's as well. The.

147
00:23:03.110 --> 00:23:03.630
alexolivier: Yeah, so.

148
00:23:03.630 --> 00:23:11.029
Dewan Ahmed: And auditing. So let's say, what are the? And again, if we stick towards like the open source side, like, what are the options they have.

149
00:23:11.890 --> 00:23:33.440
alexolivier: Yeah, so thankfully. We are quite lucky now. In the authentication space there are a plethora of vendors. Your existing cloud providers, if you're deployed on cloud will have things like Enter Id or Google, IP or Cognito in the Amazon world. If you want to look at a pure, open source solution.

150
00:23:33.440 --> 00:23:42.940
alexolivier: Key cloak is the one we probably see the most. It's a Cncf backed project for those of you that haven't heard of it. But there's also things like supertotu and citadel

151
00:23:42.940 --> 00:24:02.850
alexolivier: as well, and it feels like there's a new authentication provider every other week appearing on Hacker news or Ics backing. So it's a very kind of rich, rich world. On the authorization side of things. There's really 2 camps for this. There is a policy-based approach, which is what service is. It's what Oprah policy agent is

152
00:24:02.970 --> 00:24:09.990
alexolivier: as well. And then there's the Zanzibar based model. So Zanzibar was a white paper Google put out

153
00:24:10.490 --> 00:24:21.049
alexolivier: 8 years ago. Now, which kind of explains the permissioning model behind Google Drive. So you have millions, if not billions of resources. And you want to be able to give arbitrary access to any point of the tree in the hierarchy.

154
00:24:21.200 --> 00:24:30.360
alexolivier: And there's open source implementations of that as well. If you need that kind of model, it really just depends on your business requirements.

155
00:24:30.420 --> 00:24:34.010
alexolivier: and then on the audit side of things, a lot of time. This is

156
00:24:34.110 --> 00:24:46.740
alexolivier: kind of baked in to a certain degree to your authentication or authorization layer. And but there's also some great sort of standalone audit systems as well. Boxy. Hq. Is one that we've kind of worked with in the past and partnered with

157
00:24:47.050 --> 00:24:48.689
alexolivier: as well, which gives you this kind of

158
00:24:48.760 --> 00:24:54.779
alexolivier: nice sort of audit capability of tracking actions, and works very nicely with the authorization and the identity layer.

159
00:24:56.560 --> 00:25:19.919
Dewan Ahmed: Shifting gears. Let's talk about service playground. Back in my red hat days we had openshift playground. Now there's a OP. Playground service playground. Talk to me like how the team they thought about like building the playground, the need for such a playground, and how other companies can learn and build this playground for developer self onboarding.

160
00:25:20.580 --> 00:25:22.319
alexolivier: Yeah, absolutely. So

161
00:25:23.320 --> 00:25:32.870
alexolivier: when you're building or when you're kind of building out at least any sort of infrastructure or developer sort of operations, developer tools type offering.

162
00:25:32.960 --> 00:25:53.079
alexolivier: Yeah, there's always going to be some level of effort to basically get a local instance stood up whether that's just like launch docker container or apply a hell manifest to a mini cube instance, or whatever. And there's that kind of friction to kind of get to seeing the actual value of the thing you're playing with, or get into that Aha moment with my product on that I'm always focused on

163
00:25:53.240 --> 00:25:59.290
alexolivier: so very, very, very early on with servos. We said, Right, we've got this engine.

164
00:25:59.420 --> 00:26:05.190
alexolivier: We know it's functional. But how can we get more eyes on it? How can more people to like kick the tires. How can we get more people to try

165
00:26:05.300 --> 00:26:13.260
alexolivier: the policy format because we took a bit of a gamble with Yaml? But it's paid off. People know, Yaml love it or hate it. It's very much here to stay. There's great tooling around it.

166
00:26:13.300 --> 00:26:21.180
alexolivier: So it was like, Okay, well, if we rather than this, what can we do to remove the requirement? To stand up an instance locally? What can we do to give that instant feedback?

167
00:26:21.310 --> 00:26:32.460
alexolivier: So the servers playground is, this is just a web-based ide, and it looks very similar to Vs code. Behind the scenes. We actually run a version of servers, and you can interactively write policy

168
00:26:32.750 --> 00:26:46.219
alexolivier: and also define like reference fixtures. Okay, here's an example user. Here's an example. Admin, here's an example customer. Here's an example manager. And then also define some reference fixtures for different resources. So here's

169
00:26:46.350 --> 00:26:59.439
alexolivier: a purchase order that's approved in the Us. Here's a purchase order that's pending in EU. Here's a report which is published, etc, and you define kind of what those objects look like, what the attributes associated with them are as well.

170
00:26:59.720 --> 00:27:12.300
alexolivier: And then in this in this playground, as you're working on your policy, you're getting that real time interactive feedback loop of what access is denied or granted for those particular combination of users and resources.

171
00:27:12.350 --> 00:27:16.199
alexolivier: So literally as you type in a browser. Not only are we evaluating your policies.

172
00:27:16.370 --> 00:27:19.980
alexolivier: and once you have a valid policy file, it will sort of start showing you what's allowed

173
00:27:20.230 --> 00:27:23.160
alexolivier: and denied. But also, the moment you change it, it's going to update.

174
00:27:23.420 --> 00:27:38.699
alexolivier: And then one of the other kind of components in there as well is with servers. We also not only that you write policies, but you can also write tests against those policies. So you take those reference fixtures and resources, principles and resources, and say, Okay, what's the expected

175
00:27:38.860 --> 00:27:46.709
alexolivier: decision here? This should be allowed. This should be denied, and you can do a full test, driven development approach. And then every time you change your policy, we rerun those tests and give you that instant feedback.

176
00:27:46.890 --> 00:27:58.690
alexolivier: and of what's going on. So that playground really is allowing you to play with what your business logic is, and making sure it's matching those requirements that are coming from your product team or your security team and make sure your policy is really reflecting what's going on.

177
00:27:58.990 --> 00:28:08.099
alexolivier: And then it starts giving you a bit of a hint of like, Okay, what does it actually look like in real life? So you can start seeing what the Api calls would actually be between your application

178
00:28:08.130 --> 00:28:09.409
alexolivier: and your

179
00:28:09.810 --> 00:28:26.030
alexolivier: service instance. And what is the chatter over the wire looking like? So you can really understand and get a feel for what's going on. You can see what the audit logs look like. You can see what a query plan looks like, and we even allow you, with like one click, to start up a service instance on your local machine. That's connected real time to that playground.

180
00:28:26.200 --> 00:28:36.609
alexolivier: So you can interactly in your browser update policy. And your local instance, is now updating live. So you can start testing out the actual integration between your application and the service instance without having to spin up a production instance, somewhere.

181
00:28:36.680 --> 00:28:45.370
alexolivier: And so it's all about getting to that moment where you go. Okay, yeah. I understand this works now. I've played with it enough. I've tinkered with it enough. That's at least how I learned the best.

182
00:28:45.430 --> 00:28:51.129
alexolivier: and we wanted to make sure we had that from sort of day one, and we've been evolving it ever since. So

183
00:28:51.270 --> 00:28:57.379
alexolivier: the original Kobos I wrote about 4 years ago, which thankfully has been rewritten many times now.

184
00:28:57.520 --> 00:29:04.890
alexolivier: and we've been building and improving it based on kind of feedback and usage, and as we add more features to servos, they appear 1st in the playground for users to test with.

185
00:29:05.850 --> 00:29:16.950
Dewan Ahmed: And when you mentioned about like writing tests for servers as well, I thought the Java developer is telling like, I have to write unit test, and I have to write the test for for the policy tool.

186
00:29:17.230 --> 00:29:22.789
alexolivier: Well, if you if you kind of, I'll tell you why we kind of did this so obviously, you want to make sure your logic is correct

187
00:29:22.960 --> 00:29:24.410
alexolivier: and

188
00:29:24.780 --> 00:29:28.799
alexolivier: testing authorization. Logic, if it was hard coded in your application, gets tricky

189
00:29:28.870 --> 00:29:38.050
alexolivier: because you now you need to actually have the whole application working. You need to have the database cool. You need to have the authentication system work. You need to have. XYZ. So it was like, Okay, well, what's the smallest

190
00:29:38.270 --> 00:29:41.350
alexolivier: footprint we can do to allow you to test your policies in isolation.

191
00:29:41.360 --> 00:29:44.640
alexolivier: And so that's essentially what we have with the Service Test suites. They are

192
00:29:45.010 --> 00:29:51.709
alexolivier: essentially kind of unit tests for your policies. They are isolated, and you can run them in your Ci, etc. In isolation.

193
00:29:51.990 --> 00:29:58.910
alexolivier: without having to worry about spinning up the entire application for an end to end test, which you still should do. But this allows you to iterate much faster just on your policy.

194
00:29:59.640 --> 00:30:06.650
Dewan Ahmed: Yeah. And also with the Llms. We don't have to like, write by hand all the test for the policies as well

195
00:30:07.050 --> 00:30:11.690
Dewan Ahmed: generate the test, and then just validate that that those are working as expected.

196
00:30:11.690 --> 00:30:12.560
alexolivier: Absolutely.

197
00:30:13.180 --> 00:30:22.529
alexolivier: Yeah. The I quite regularly check all you know, chat Gpt and Claude, and all these ones to see how well they can generate sales policies, and they're getting pretty good now.

198
00:30:23.250 --> 00:30:25.830
Dewan Ahmed: Yeah, yeah. The more data points you're getting

199
00:30:26.000 --> 00:30:29.210
Dewan Ahmed: switching gear to the trends.

200
00:30:29.800 --> 00:30:35.039
Dewan Ahmed: Of course, like, whenever you talk about trends, there's it's very difficult to avoid

201
00:30:35.120 --> 00:30:39.089
Dewan Ahmed: the Ml and AI and all those. Yeah.

202
00:30:39.820 --> 00:30:56.309
Dewan Ahmed: I don't know the what the right adjective to use. But thinking about the devops trend, let's say, if we take one more generic approach, not just the the authentication or authorization the devops trend in general. So before we, we used to have, like Qa team like.

203
00:30:56.980 --> 00:31:25.150
Dewan Ahmed: Groups of people who test the code. But nowadays, for most startups, you don't see like a team of Qa. You see, developers writing their own code and also testing that code. So how do you see see the trend in devops for developers? More and more? They're sort of owning and managing their authentication and authorization for apps rather than having the devops, person or devops team doing that.

204
00:31:27.410 --> 00:31:43.700
alexolivier: Good question, and my view is very much tinted from being in small startups. So previous one, when I started, there is what 30 of us one after that I was employee number 6, I think, after that, and so always being quite small, I've never had the luxury of a dedicated Qa. Team.

205
00:31:43.840 --> 00:31:46.879
alexolivier: And when I look at it through that lens.

206
00:31:47.090 --> 00:31:49.900
alexolivier: it's always been very much like, let's create A.

207
00:31:49.960 --> 00:31:53.259
alexolivier: It's such an overused term these days. But like a full stack team

208
00:31:53.470 --> 00:31:56.740
alexolivier: and aligning around features and capabilities.

209
00:31:56.880 --> 00:32:06.330
alexolivier: So within that you might have someone in that team. You got a product person. You got a ux person. You've got front end back end and and devops all working very closely together.

210
00:32:07.510 --> 00:32:12.259
alexolivier: on it. And really you're what you're trying to do is trying to reduce the amount of.

211
00:32:12.270 --> 00:32:16.989
alexolivier: do some work, hand it off to another team, wait for them to do something, and then come back. And by

212
00:32:17.030 --> 00:32:22.130
alexolivier: the teams I've built in the past by having that kind of full stack team. We've been able to actually ship much faster.

213
00:32:22.230 --> 00:32:23.430
alexolivier: And I think

214
00:32:23.670 --> 00:32:37.999
alexolivier: you talk about AI and all the Llms. All this all the stuff. There's some, you know, pretty scary, but also great tech coming out. And ultimately what I look at it as as is, how can this make us as a full stack team.

215
00:32:38.180 --> 00:33:07.020
alexolivier: produce better content, faster, or better applications faster. So that's kind of the way I view things, you know. Shift left is a term that's used quite a lot, and having those common functionalities authentication, authorization as something needs to own it, but you shouldn't have to build it. I think it's going to become more and more, and we'll start seeing more off the shelf components being dropped in to systems. And into these full stack teams who can actually just set up once it's integrated and move on to kind of the next thing

216
00:33:07.409 --> 00:33:11.000
alexolivier: and have a system that kind of can iterate and move quite quickly on top.

217
00:33:12.730 --> 00:33:13.300
Dewan Ahmed: And

218
00:33:13.900 --> 00:33:25.529
Dewan Ahmed: by by now our listeners and viewers must be thinking like, how can I get involved like what's next for Cerbus? What's coming next for Cerbus, and how can folks get involved.

219
00:33:26.140 --> 00:33:29.220
alexolivier: Yeah, absolutely. So there's kind of 2 things here I want to talk about. One is

220
00:33:31.060 --> 00:33:42.710
alexolivier: In the past year or so there's been a real drive amongst authorization vendors and thought leaders around, how can we start standardizing what authorization looks like?

221
00:33:43.234 --> 00:33:52.979
alexolivier: And there is an ongoing effort called the authzen working group part of the openid foundation which servos were a part of. When it's all about kind of standardizing the interface

222
00:33:53.140 --> 00:34:19.099
alexolivier: around authorization, how it integrates into applications. Our hope here is the openid connect. Moment will happen but for authorization as well. And the reason why that is important. If you look at what's happened with login and single sign-on identity. You can now today go to some Saas vendor, some commercial off the shelf product and plug in your own Idp plug in your own Saml and Openid connect type interfaces. And now you have that federated identity, and that's done over a standard interface

223
00:34:19.460 --> 00:34:21.400
alexolivier: where authorization.

224
00:34:22.040 --> 00:34:26.960
alexolivier: in my view goes, is that similar kind of interface? So if you were to go and buy

225
00:34:27.320 --> 00:34:56.169
alexolivier: name some big box software that you use inside of a business, be it Crm Erp, or some Saas product you're using as part of your onboarding. You go step one, connect my Idp and do federated identity and single sign on and step 2 plug in my business's authorization system as well, because building authorization just for the application layer is one thing, but really as a business. You also want to have that same level of control of other systems that as a business you're using, so there should be a single point where you define

226
00:34:56.170 --> 00:35:16.489
alexolivier: what a manager inside of a business, what a user in the North America office can do, what an auditor can do, and you should be able to find that centrally, and then every system you build, be it an internal tool or an external system, should be able to hook into that authorization layer. So you don't have to go in and provision access in 10 different systems whenever someone joins, moves or leaves a business.

227
00:35:17.320 --> 00:35:23.550
alexolivier: So I guess the the ask there is if you're listening to this, and you're thinking around like, Oh, I'm building a system.

228
00:35:23.600 --> 00:35:27.479
alexolivier: and it's and this kind of interesting how we could hook into authorization. Please

229
00:35:27.590 --> 00:35:29.510
alexolivier: come along. There's a

230
00:35:29.550 --> 00:35:38.410
alexolivier: open forum, the openid Authors and working group. We're always looking for software vendors to kind of bring their use cases and requirements, so we can make sure the standard fits that.

231
00:35:38.620 --> 00:35:43.719
alexolivier: And so the Api on top of servers will be authoring. Compliant as we start ratifying those versions.

232
00:35:44.130 --> 00:35:54.810
alexolivier: And that's all about how we can make sure that authorization is as easy as possible to integrate into any application. Not necessarily ones you build yourself, and you can find out more about that on the service website as well.

233
00:35:55.160 --> 00:36:06.350
alexolivier: And then where we're going with servers itself, we have kind of a number of releases coming up shortly. The thing we've just rolled out recently is a view inside of our management control plane, which we call servers hub

234
00:36:06.460 --> 00:36:13.800
alexolivier: which aggregates all your audit logs into a single interface. And that's really designed for security teams to use.

235
00:36:13.960 --> 00:36:24.489
alexolivier: you know, up until now we've very much developer focused. And we've started bringing on product managers to kind of manage policies themselves in that kind of playground style environment. And then the next and the next kind of

236
00:36:24.720 --> 00:36:32.400
alexolivier: set of users inside of a business that are like asking for like help, you know, to do their job ultimately is these security teams.

237
00:36:32.440 --> 00:36:34.100
alexolivier: and, for example.

238
00:36:34.780 --> 00:36:37.849
alexolivier: Ciso, at a large business, they kind of get

239
00:36:38.100 --> 00:36:46.469
alexolivier: identities that have had a suspected breach. They need to go and pull out all the actions that have been having inside of their application in order to fulfill their own

240
00:36:46.720 --> 00:36:47.630
alexolivier: and

241
00:36:47.800 --> 00:36:50.309
alexolivier: compliance. Or so. Maybe it's an external customer.

242
00:36:50.640 --> 00:36:54.160
alexolivier: A lot of the logs, and the kind of the audio of triple A

243
00:36:54.270 --> 00:37:02.140
alexolivier: is kind of just dumped out to some log capture system. Be it something inside of your cloud provider or elastic, or datadog, or those kind of tools.

244
00:37:02.360 --> 00:37:17.989
alexolivier: And that's very like developer focused. It's just like the application. The raw application logs. The Ui is designed for someone that's happy to write. You know, Json, paths, style searching and those kind of things. And the data retention as well isn't is going to be based on data volumes. You might have only 30 days with the data

245
00:37:18.120 --> 00:37:22.480
alexolivier: from a compliance and a security point of view. You need a firstly, it's a very different Ui, you need something.

246
00:37:22.780 --> 00:37:26.339
alexolivier: someone that isn't necessarily a dev or a devops person can operate.

247
00:37:26.360 --> 00:37:33.970
alexolivier: And you also need data retention. That's much longer than that. There's legal requirements of multiple years, if not longer, depending on your industries and verticals

248
00:37:34.160 --> 00:37:49.939
alexolivier: to kind of keep authorization and access control logs. So that is something we've rolled out and we're building on top of right now inside of servos. So you get that ui, you get that interface as part of our managed control plane that complements the open source decision point that runs in your stack.

249
00:37:53.150 --> 00:37:55.530
Dewan Ahmed: Sounds great, and

250
00:37:55.960 --> 00:38:19.970
Dewan Ahmed: in in such a short time you're able to to tell our listeners, like the the past, present, and future, or trends of of service. What would be like a few words you can use to summarize service? Would it be like the the authorization layer, friend, for the developers like, do you have any catchy phrase that you used to explain? Let's say service in a few words.

251
00:38:21.300 --> 00:38:37.540
alexolivier: My go to is, don't reinvent the wheel, and I think that's just general advice. Authorization is one of those wheels that you could get stuck reinventing with kind of what's going on with your application, how the checks are done! But I would say, server is fine grained access controls in days, not months.

252
00:38:37.580 --> 00:38:39.080
alexolivier: all years. In some cases.

253
00:38:40.010 --> 00:38:48.359
Dewan Ahmed: That's a nice tips to end the podcast. That don't reinvent the wheel, Alex. It was an absolute pleasure to chat with you.

254
00:38:48.620 --> 00:38:50.110
alexolivier: Likewise thank you for having me.

255
00:38:50.430 --> 00:39:05.260
Dewan Ahmed: Thanks, everyone. Thanks for listening. This was ship talk, podcast, and I'm your co-host. Dewan Ahmed. I work at a company called Harness, the AI, native software, delivery platform. Thank you for joining and find us wherever you find your podcast thank you.

256
00:39:05.690 --> 00:39:06.290
alexolivier: Thanks.