The Need for Open Source Access Management with Passbolt’s Kevin Muller

This is Textron tv. Hey guys, thanks for the throw. We're here with Kevin Mueller, who's the CEO of Passal, and they just picked up $8 million in initial funding for an open source collaborative password and access software initiative.

And I'm gonna let Kevin explain what exactly that means. But Kevin, welcome the show. Thank you very much.

I appreciate it. It's a pleasure to be here. So what exactly is the issue we're trying to solve here?

I mean, we've been kinda haphazardly maybe doing management of access for a long time now and with mixed success, but what are you guys up to? And, and how's it gonna change everything? Yes.

Maybe I can start with the history of the software so that you understand exactly why we, we decided to build it. And I think it'll explain by itself, uh, what it is that we are building. So the, we basically decided to build passal, uh, quite long ago.

It was in 2012, so it's not a new project. And by the way, it's not our initial round of funding, uh, that we just did. It's a series A.

So we had, uh, previous round before, uh, we incorporated the company in 2016. But back to the, uh, story of the company, we decided to build passal because we were a web agency, uh, based in India back then. And we were scaling very fast.

Uh, as we were scaling, we're trying to store the, the credentials that, uh, we needed on a day-to-day, uh, basis. You know, the customer credentials, uh, thousands, sometimes hundreds of them. Uh, be it SSH keys, be it, uh, FTP, uh, credentials.

It was still, uh, there back then. Uh, API token, uh, and sometimes simple username and passwords, or even certificate. The problem of digitalized teams is that they need to collaborate a lot because you have, uh, a lot of movements within the team.

So you're working on a project and then suddenly your DevOps engineer will change, will be replaced by someone else, or maybe you're adding someone to the team and you need this person to, uh, quickly, uh, have access to all credentials you're gonna use. So this was our, uh, main use case. And on top of that, we were using only open source software.

So we're using like, uh, systems like Drupal, WordPress, uh, GitLab. And obviously we liked this aspect of having control in ownership on the stack we were using. So when it came to looking for a credential manager for us, we wanted the same property.

Some something that is also open source, and that would give us ownership in the sense like we can host it ourselves, uh, because if you host it yourself, it's also easier to plug with the, the other tools of your infrastructure. So all this brought us to using KeyPass. And as we're using KeyPass, which is a fantastic tool because obviously it, uh, checks a lot of boxes.

Open source on-prem really allows you to, uh, manage a large volume of credentials, you know, with folder sub folders, icons, uh, metadata, flexible metadata. But the prime of kipa is that it's not collaborative. So it's just a file, uh, and spread static.

So for a lot of teams who start with kipa, and there are a lot of them because Kipa is downloaded, uh, somewhere between two to 5 million times a month, which is huge even today, uh, all these teams in Kipa are basically trying to, okay, now we have this pass file with thousands of credentials in it. How do we split it? How do we make this specific folder accessible for this specific team In the context of this project?

And this is exactly the, the position, uh, where we're at. Uh, and we decided to develop Passport for ourselves because after checking the password managers available in the market, realize that they, they were not built for this. Most password managers are built with a more consumer centric approach and, uh, mostly optimized for web-based credentials.

And you can see that very clearly when you're using most of the password managers are available because the only way you can share a credential is by creating a shared vault and putting the credential in the shared vault and then sharing the entire vault with the entire team. But if you work in a digital team, you will know that this is not how people, uh, want to collaborate. They need a more fine grains permission system.

They need to go further, uh, with the way that they are sharing, uh, credentials or resources. And they need also to have very reliable traceability and visibil, uh, observability on top of it. And this is something that Passport is, uh, uh, incorporating, At least in my experience.

I think people, they get maybe lazy is the word, or maybe not, but you know, they basically over-provision people the access. 'cause they don't wanna constantly go back and forth to give them additional permissions. But then when they do that, these people wind up having more access than they need and then the bad guys come after them to get those credentials.

'cause they're like, Hey, now I can go anywhere too. So is this part of the problem? I mean, is this the core issue we're trying to get at?

Yeah, absolutely. It is the, basically for a technical term, it comes down to the privilege, the principle of this privilege. So you just want to give people access to what they will need, and you want a very instant and effective revocation, uh, when this person is leaving the team or should not be able to access to this project.

So this is part of the problem. And I would say another part of the problem is, um, um, if you look at the classic digital team, you will have at one end people who like to work with a ui. Uh, typically developers, you know, they like fancy ui, ux, uh, they, they like to be empowered by the UI of the tools they're using.

And at the other other end of the spectrum, you will have people who are more like system administrators or DevOps engineers will be more using key value, uh, or secrets like for example, SSH keys. And most of the time they will use it, uh, from the command line. But if you look at the, uh, password managers that are available, most of the time, they will give you a password manager at one end and a secret manager at the, the other end.

And these two tools cannot, uh, discuss with each other, which will leave the DevOps team, uh, stuck on their own tool, and they will be unable to share secrets, which sometimes are needed by the developers. And it's creating silos in collaboration. And in the case of passports, this is something we, we've tried to unify and you can already use possible to store all type of credentials.

So your secrets with very fine-grained, uh, permissions as well as your web credentials with the same type of permissions for the same teams. Hence it's only one platform for everyone Whom drives the adoption of this type of platform. Is it really gonna come from a DevOps slash DevSecOps team?

Or is it the security people who are gonna show up and say, this is how this needs to be managed? It is a really good question. And uh, in our case it's both.

Uh, so the classic user journey for, uh, a passport user or customer would be the system administrator. Uh, sometimes they're using kipa, sometimes they're using a spreadsheet, sometimes they're using another platform manager that is not scaling in the sense of they don't have the granularity that they need for the sharing, so they cannot apply this principle of this privilege, uh, or they cannot go, they cannot have proper traceability, like the lack of visibility as of who has access to what. Hence they look for replacement.

Uh, then they find pass vault, uh, 'cause they're sensitive with open source, self-hosted. These are properties that, uh, they're looking for. They would install the community edition, which is fully free, uh, can be installed in one minute.

We support all type of Linux servers massively. So it's really one common line a PT get installed, or on Docker, it's classic Docker. We also provide hand charts.

Uh, we know some people have installed it on the Raspberry Pi, so it's very lightweight, really easy to, uh, to go ahead with it and they start using it. But the, the beauty of the solution is that it's really built, uh, to be effective for collaboration. So from two or three engineers in the company using it very quickly, they will like, oh, they will be like, oh, but this team will also need it, so let's onboard the DevOps.

Uh, oh, let's onboard the CSOPs. Oh, but you know, now we have this security guy who wants to know what's happening with the accesses. And uh, it happens that in passports, these reports are there.

So let's also invite him. And as they scale, at some point they will realize, okay, cool, this is a tool that we can actually adopt not only for the one technical team, but we can probably scale it, uh, beyond the technical team. So that's the, the typical journey.

Do you think that regulations are becoming stricter and ultimately will force this issue? Because it seems like, especially in the eu, there's a lot more conversation about rules for developing software that must be fault. Yeah, EU is a very specific world, it's own rules.

I would agree to that. And yes, it's a, um, it, it's a really good engine of traction force. Uh, so typically in Europe we are selling passports, uh, quite a lot to governments, public institutions, defense, and one of the reason they are going for it.

So there are multiple reasons. One of the reason is that we are European. So they know that, you know, the digital IGN key is there, but another reason is definitely the compliance, the governance.

It's like they are, uh, they own the technology, they install it behind their firewall, uh, they own their data. So absolutely the compliance is, is a big question here for them. So as we kinda move from that whole thing, how are you gonna make money?

Because, um, it's an open source project and a lot of people are always a little bit more concerned these days to make sure that the open source project is gonna be around when they need it. Yeah. Why, why would it be around when they need it?

Like is your question, They're worried that it'll fade away because they're not enough people working on it, or there's only one company behind it, so they wanna know like, what is the long term viability and what's the business strategy? Well for, you know, open source business is a business, so it needs to be financially sustainable. Uh, just being open source is not enough, obviously.

So in our case, uh, we're already profitable before raising. Uh, so we were like financially profitable before raising a service. A and we have always tried to keep the company healthy that way.

So not growing too fast, making sure that, uh, we have good growth, healthy growth that we can pay for the salaries, uh, before trying to bleed scale or, or take too many risks. So the way it works, uh, in the case of passal, it's a very classic open source business model, uh, very similar to what companies like DU are doing. DU is a European company, not sure if you heard of them, or GitLab is also functioning in the same way.

It's a typ typical land and expand business model. So we are lending into companies by a free open source version that is solving the problem of collaboration with all type of credentials, passwords, accesses, secrets. And we are trying to do this job very well for unlimited users and unlimited usage in the community edition.

But we know one thing, we know that the most mature companies are gonna expand their usage within the community edition. So we know that the most mature of them, once they will reach the threshold of sometimes it's a hundred user can be 500, they will start being like a, but you know, we need more advanced reports or we need to plug this thing into our active directory, otherwise it's a nightmare to manage our users. Or in some cases it's like, we need this specific type of SSO that is not in the free version, and this is what we are selling in the paid edition.

So in other words, the paid edition of AL is targeting the more mature type of customer and the larger type of customers, uh, the ones who are not like a small team of 10 users, but they will have like, uh, 200 or 500, uh, engineers. Or in the case of governments, we have, uh, currently full rollout, uh, at the scale of 15,000, uh, users inside, uh, an entire government. So I'm assuming that means there'll be some sort of enterprise edition of the platform in the future that you guys might support for, uh, on a more commercial basis.

Is that kind of part of the thinking along with maybe support and services? Yeah, it, it's, it's already there. So we have entry level pro version, and we also have an enterprise edition that comes with, um, a support with SLA, you know, high availability setup.

We send engineers, uh, to, you know, really do things properly, uh, at a set up time. And obviously this is the addition that, uh, governments or armies go for even currently. How might we think about using AI for some of this sub day?

Is that gonna play a role? Is that something we can think about? Can there be a, an agent that will manage access and control for us?

I mean, it's, it's not like everybody loves doing this, so maybe this is an ideal candidate, so, Uh, I'm gonna disappoint you, but no, that is, so, you know, in case for ai, we've really thought about this. You know, mainly when you are fundraising, you want something that's, uh, that's fancy. You know, you want to use all these buzzwords.

So it would've been really cool to come up with AI credential management, but we don't see any use case. Actually, we saw one use case, uh, which is like, you know what, one of the problem that lot of web-based platform managers have is how to position properly the autofill to be able to autofill username and passwords in forms because it's a nightmare. Not all websites are respecting the standards.

And some, you know, there are multiple ways of doing a form for authentication or password recovery, and most password managers are failing at recognizing what is an authentication form or not. So we had this idea of using AI in order to, um, autofill properly those fields, but that is, that is the most advanced use case we came up with. So what's your best advice to folks about how to make this a higher priority in their organization?

'cause one of the challenges always there's competing priorities. There's all kinds of things that people are gonna work on. So why should this kinda move up the ladder and be at the, the front of the brain as it work?

Well, you know, I can only speak from what we know at pabo. Um, as I said, it's a learn and expand type of project, so we are not trying to convince people to install it. Usually people installing Passport, they are feeling a pain point.

They already know, uh, what they need. They know that they would want to go for open source. They know that they would want to go for self-hosted.

I mean, we also have a cloud offer, which some customers decide to go for, but initially they know that they, they want ownership. They know that they want really a strong collaboration, and they know that they want a more sophisticated platform that can handle more use cases compared to a, a basic platform manager. So they have identified their needs and they're looking for it on Google.

And these days I would say it's a lot of, of charge GPT searches. They find us, they don't talk to us, they install the community edition, they go on their own. Uh, they see if it's working and if it's working for them.

At some point we will hear from them. So the the pain point comes from them. We, we don't try to tell them that they have it.

All right folks. Well, you heard in here there's a new way to think about this and boy, and we've tried a lot of different things over the years, so couldn't hurt to maybe find one that maybe actually works. Hey, Kevin, thanks being on the show.

You're welcome. Thanks for the invite. All right.

And back to you guys in the studio.