• News
  • Posted by George Wainblat

  • July 22, 2020

Akeyless Vault Secrets Management on the Absolute AppSec Podcast

We were thrilled to get the chance to introduce Akeyless to the Absolute AppSec podcast! Our CEO, Oded Hareven, told the story of Akeyless Vault, explained the challenges of managing and securing secrets - and how Akeyless tackles them.

Thank you, Seth Law and Ken Johnson, for a great opportunity to introduce Akeyless secrets management.

You're all welcome to watch the podcast:

Below is the transcript from the episode:

Ken Johnson: And we are live with our 103rd episode of Absolute Appsec. I'm Ken Johnson @cktricky on Twitter joined by my co-host Seth Law, @sethlaw on Twitter. Seth, say hi.

Seth Law: Hey everybody! Welcome back once again. We are excited to have Oded with us today to discuss secrets management and how we actually handle those in Akeyless. We’ll get into that shortly. We’ll do full introductions here as well...

Ken: I didn’t have anything else other than to introduce the man of the hour. Oded Hareven from Akeyless. He’s the CEO and founder, and basically it’s actually Seth that was just like-- was it? It was just you and I right?

Just a day or two ago somebody was asking us about secrets management or something like that. Somebody was asking about it and it’s just funny because this is the conversation we always have. It’s how do I do secrets management securely? And it’s very, very confusing for a lot of people.

And anyways, I happened to come across this technology and got introduced to these fine folks and figured, maybe have them on the podcast and they said yes - and I’m super happy about it. So yeah, we’re going to learn more about the technology, about Oded, and basically just get into it. Before we do that, Seth?

Seth: I was going to say like this is definitely a very common issue that we see across the board, right? I can’t tell you how many reports I’ve written when I’m doing a secure code review where I’m like, “Guys, you can’t put your AWS key in your Github'' instance.

I know Github tags that now, but I still see it pop up from time to time. And it may not necessarily be AWS keys anymore, but at the very least database passwords have always been an issue. Like those database strings that are sitting in the settings files or in web.config or whatever settings file your framework happens to use.

It’s very common in my space. You guys have probably solve that a little bit on your side better, but most of the small and medium-sized companies struggle with this because the developers have so much trust and the security team doesn’t necessarily have a purview into what they’re doing with those secrets and how they’re connecting to other systems, so it’ll be a good discussion.

And the question that popped up was from someone that had been in one of our courses and it was just honestly, what’s the recommended way for an application to store passwords that aren’t used for logging into but for accessing other things like API’s?

So, how do we store passwords not for our user, but for when we want to access things? And I think that’s specifically what Akeyless is about. And I know there are other technologies that are out there that solve problems and we can talk about how Akeyless compares to AWS secret manager, right? That would be an interesting discussion to have because that is a technology that I know people are familiar with, and they do have a tendency to use it.

So first off, Oded let’s have you introduce yourself. You’re the founder of Akeyless, is that correct?

Oded Hareven: Co-founder.

Seth: Co-founder.

Oded: Yeah, this is important you know. We’re a group. We have three founders here that founded the company, but we're a great team of management and lead team and product and marketing so it's teamwork as you know.

Seth: Cool, and so before we get to Akeyless let’s talk about your background a little bit. What led you to that point? You’re in the security space now, have you always been in the security space? Or how did you get involved?

Oded: Well, that’s a great question. Well it was back when I started in the Israeli Defense Forces, started on my way. It was, believe it or not, 2001. Okay, so back in 2001, I started my way in the programming course in the Israeli Defense Forces. And I was also a lecturer -  I stayed there to teach others how to program, how to code, back then C++, the fundamentals of programming, and I found that fascinating.

And, I was kind of attracted to two things. One was communication and networking and the other part was infrastructure. So, both of them, as you know in the cybersecurity world, that was back then, most of security-- there were some people that were starting to talk about application security back in 2000, but still it was not widespread.

Application security has been having a great time in the last few years from dealing with vulnerabilities in code and in the CICD, testing and so these days in the last few years that’s a great place for application security. Anyways, so I started from infrastructure and my first project was identity and access management, and we started with a product by a vendor that I won’t reveal the name.

And it turns out to be not a very good product that we didn’t want to implement inside the Israeli Defense Forces. And pretty soon we understood that we needed to code it on our own. And that was the beginning of my career with the cybersecurity program - identity and access management system. As time evolved, I had the privilege to touch many types of information security infrastructure to include endpoint security and SIEM/SOC and antivirus and PKI and a lot of hardening and access management, SSO, and all of those.

So, that’s the core of where I come from, infrastructure and information security, and this is how I got into that world. Not to mention, the last four years before Akeyless where I stopped with cybersecurity. Besides that I’ve been with cybersecurity all along.

Ken: Wow, that's a long time in this field. I think a lot of people I know did-- Seth when did you start?

Seth: I can neither confirm nor deny that I was also doing stuff in 2001, but mine was more on the Java side on that point. That’s what I was going to ask but it sounds like it was C++ where you started in there. And then I moved over to the pen testing space in 2004, 2005 and went more of the consulting route until I made my way back to application security. Because there was no application security at the time it was all just-- yeah. But exactly what you’re saying, we have a lot of power to change things because we understand. And then I love to hear, okay there are other people that were in the space back then that did programming and are still in the space, right?

Ken: What were the issues with the product that you didn’t like?

Oded: Well back then, wow.

Ken: Yeah, well I’m sure there were a lot of things but yeah.

Oded: Identity management, well that was the major first wave of identity management back in the year. The end of 90s, the beginning of 2000s where infrastructure guys understood that - hey, what’s happening? We have lots of users and we don’t have a comprehensive workflow to unite all of those. But back then, workflows were very bad, workflows products were very bad. A lot of polling and queues that were stuck. A lot of LDAP engines, LDAP databases back then were quite a few that were very good but all the rest were, I don’t want to say ******.

Seth: You can, it’s a podcast go for it.

Oded: Okay, no problem. There was, especially something in particular that I remember, we had to have some exits, some program exits in order to enhance the product and the only option that we could have done it was using a C++ DLL on windows. And that was not something that you couldn’t have done.

That’s basically the experience with SDK C++ on DLLs back then so pressing wrong buttons and hoping that it would work.

So anyway, that was a ******thing. Lots of memory leaks and dumps, and it didn’t go well, so we understood that we need to make so many enhancements that we should’ve just gone back and build it from the ground, zero up and have it within using .NET and any other technologies that were, back then, that we were using and we took four weeks.

That was my, basically, first startup experience inside the army to take four weeks and to meet a deadline that was very important back then. And we were able to meet that. We didn’t sleep, ate lots of pizzas and other cool stories that most of us have. And this is how we’ve done it, we just built it and it was a great experience.

But you know what Seth, you’ve reminded me with the application security and penetration testing that I must share with you. Back then 2004, the WebGoats of the beginning of the versions of WebGoats were trying to hack things and the easy back then the SQL injections and I was like, “Wow! I can do this and I can do that.” And yeah, I’ve had a great experience with building for a short period of time, one year with the architect and consultants team, it was very small at the beginning, to start consulting projects within the army about how they need to do their security. I actually remember how we really wanted them to go into the application security world. And again back then, it was like talking with walls, it was so hard.

Seth: And I was going to say on the identity management side, right? What you’re talking about, the period that you were talking about, identity and access management was a huge thing. And I remember my first security job at the bank they were trying to solve it by bringing in all these vendors and no one had any idea what they were doing, like they’re backending.

And I still see this, I will walk into clients and I’m like, “Okay so who’s your identity provider?” and they’re like, “Oh it’s our mainframe.” and I’m like “It’s your mainframe?!?” Like, is this 2004? But that’s exactly what they’ve done, they implemented it and they can’t get away from it.

Oded: In a way it is a mainframe, to have an SSO project, that’s your mainframe. So I understand why they’re saying that, I totally get it. We’re talking back at the beginning of 2000 where SSO-- people were starting to talk about it. And the beginning of SAML, not to mention Open ID. With identity management the big word was about provisioning.

Today, when we say provisioning, that’s a completely different concept, right? Provisioning your containers. Provisioning the production environment. That’s a much sexier word and most suitable these days. But back then, you had to have some provisioning engine to provision accounts to any LDAP, Active Directory or whatever ****** novel thing that you’re using or whatever that was back then.

I actually had a very recent thought about it, how things evolve in terms of how great things are with plug-ins and things that are much more standardized. And today with SAML and Open ID, you’re just using some links and you’re connecting with, what was back then, heavy to configure. Today, you can configure Okta and any similar applications very easily. And instead of provisioning your identities, you’re basically having the permission to look at an external identity provider. And that’s a great move that we’ve done in the last 10 or 15 years.

Seth: Yeah, I think about some of the IDPs that are out there. And as we started into that space, exactly what you’re saying, it was all LDAP backends. And we were trying to wrap all this and figure out how SSO was to work as SAML and Open ID came out, and it was a painful, painful multi-year process for a lot of these large organizations. And nowadays it’s like all you have to do is import this plugin into Okta and here’s the webhook and boom, you’re going.

Oded: How great it is, right? And you know what, there’s a very interesting trend by the way. We say history comes back- I don’t know there’s a phrase in Hebrew that says history repeats itself- and I see the same with, back then, in Active Directory, and you still see a lot of organizations that work with Active Directory.

But the cloud brought so much of Linux to the world. And suddenly what you used to have such a comfort zone with managing your windows servers within a corporate large enterprise environment, and suddenly you’re getting again most of your servers with containers and Kubernetes and so on, you’re getting Linux a lot within your environment and suddenly you don’t have a domain to manage them.

So the history repeats itself with what we thought we had a solution with Active Directory domain, but suddenly you’re getting a new problem, which is kind of the same problem, but today it’s with SSH keys once again. And you’re swamped with those SSH keys and how do I manage them. And there’s also the easy solution of interconnecting your Linux with an LDAP repository, but it’s not secured enough and there’s all kinds of other things there.

But you see trends that come back and again the identity management problem and Privileged Access Management problem with the DevOps tools like Chef, Puppet, Ansible, Kubectl, and SSH access. And all of those tools suddenly are not getting a lot of good responses or good solutions from the old legacy identity management solutions, not to mention the old days and old solutions of privileged access management.

So there are great new opportunities with the new environments and the new tools of DevOps, and  the new opportunities with the cloud that makes basically a great gap with secrets management entering into that field. And I’m mentioning human to machine and not just machine to machine, right?

Secrets management is a generic term most times. I say that term where people mostly say that it’s machine to machine. How do I manage my API keys and secrets within my code? How does my code authenticate to the secrets management system in order to fetch secrets?  And my Kubernetes cluster, how do they protect secrets? Is it with using Kubernetes secrets or an external secret management solution? And all kinds of solutions.

But when you think about it, secrets management is about any type of secret - API keys and passwords and encryption keys also. And if you’re looking on the leaders of this field in this secrets management and the innovative solutions in that realm, basically you tend to see that when you’re analyzing it from the eyes of the IT DevOps, SRE eyes, and all of them together the security architect and the CSO that looks on the security problems, basically it’s the same technology of the ability to encrypt very important object that are being made in order to authenticate and authorize.

And suddenly password management for humans and privileged access management becomes very close to that. So imagine that we could have had an all in one solution for all of those problems. I don’t want to take the end and the punchline, but eventually this is what we’re doing, this is where we’re going, this is where Akeyless Vault is all about.

You talk about the secrets management problem from a comprehensive view where we look at these many secrets types within the organizations and say, okay what’s the use for that and what’s the use for that? Either it’s an encryption key that is being used by an application or sometimes what about the SSH keys that is being used by the DevOps engineers, how do we protect that? Because it’s a big hassle and a great vulnerability.

Ken: Yeah, like an SSH key to get into an EC2 instance or something like that for instance just whatever it may be. I mean, one thing I like about Akeyless when we were talking about the technology was, specifically, the zero knowledge aspect of it. And I was hoping you guys could talk a little bit about that but-- well the other thing I liked was your-- I don’t know why this is the way it is, Seth, but we’ve talked about on the podcast before with security vendors who won’t put pricing on their page. Like they created a product but won’t put-- and Akeyless actually has the pricing on theirs.

But back to the technology aspect of it, I did like the zero knowledge aspect so I don’t have to trust like it reminded me of One Password. They don’t actually ever know what the value is of whatever you’re storing securely. There’s like a couple different keys and I think you keep the master key on your end. So it’s basically, the concept of that whole zeo knowledge on your end of our secrets essentially is what I really did like and was interesting, very interesting.

Oded: Thank you for that. So, in order to explain the zero knowledge or zero trust encryption, as we call it, that basically means that we can manage secrets and keys for our customers and at the same time we don’t have access to those encryption keys and we don’t have access to those secrets. That’s the secret sauce of our secrets management, especially when we provide is as-a-Service.

So in order to talk about this in maybe two sentences about where we come from and where we started. So our story begins with our beloved CTO, Refael, when he was working a few years ago in a large, American Fintech company in the cryptography and the R&D security here in Israel, where he saw the major hassle of managing encryption keys and secrets on a large, very large scale, and the amount of resources that they had to invest in order to provide keys and secrets management to all of their internal projects.

So after quitting the company he thought about, “How can I solve it much better?” and he was lucky enough to go and think about an innovative and patented technology that we call DFC, Distributed Fragments Cryptography, that, in short, allows us to perform cryptographic operations using fragments of encryption keys that are spread in different regions, in different cloud providers, and when we perform the cryptographic operations, we never need to combine those fragments. That’s the complete opposite of what you might have been familiar with - Shamir Secret Sharing in that sense. With Shamir Secret Sharing you’re creating a whole key then you’re splitting it and then when you need to use it you need to combine once again and this is, talking about security, this is where a malicious attacker can gain access and grab your key when it is exposed and game over.

So what our CTO has basically invented is a way to perform cryptographic operations using fragments without ever combining them. I know this sounds impossible but this is how it works. And by the way, we use completely standard cryptography. It’s all standard cryptography. This is why we’re very fast to get NIST FIPS 140-2 high level of cryptography because it’s all standard.

But the innovative part here is about managing those fragments. So after we talked about this, then this is the time when we can talk about zero knowledge or zero trust encryptions as we call it.

So first of all, what’s the problem? The problem is how can you manage encryption keys within cloud environments. Basically you need to share your encryption keys with your cloud provider. That’s the most basic part. And of course, when you want to also manage secrets, when you wish to manage your secret within Akeyless, then how can you trust Akeyless?

So, we have used our abilities to perform those operations of encryption without combining those fragments and saying one of the fragments will be created and stored locally on the customer environment. Now, locally it can be on their VPC, on their on-prem, whatever they wish, on their internal perimeter where we, Akeyless, don’t have access to. So now you get let’s say, for the sake of example, you have three fragments that are being managed by Akeyless on three different regions, they are not connected with each other, they’re not communicating with each other, they’re not even aware of each other, and all the time they’re constantly refreshed on their mathematical values.

So it’s very hard, you need to attack them simultaneously, plus there is another fragment that is stored on the customer’s side. So Akeyless doesn’t have all of the fragments of the key, right? We don’t have it. We only have several percentage of that. And because we’re using standard cryptography, 99% of the fragments equals to 0% of the key. That’s the beauty of it.

So if someone either tries to steal those keys from us or the CLOUD Act like a federal warrant or whatever, they are trying to attack our system. We don’t have all the keys, and it’s harmless in that way. And so this is how we provide our customers the ability to keep their exclusive ownership of their keys and secrets, we cannot decrypt their secrets. That’s basically the story of it.

Seth: Cool. So basically their portion of the key ends up kind of being their master secret, right? That’s what it takes to decrypt those values is something in those lines.

Oded: This is a great point you’ve just mentioned because the fourth element- and by the way we’re agnostic to the number of the fragments- that fourth element I’m now mentioning or it’s a sexy term to say fifth element. So that the fourth element, the golden piece here, it’s not a password, it’s not an authentication, it’s a real fragment of the key.

What’s great about it is that if someone is hacking into the customer’s environment and somehow is able to grab the customer fragment, because they only have that fragment, nothing will happen. It’s not that you have one fragment that is more important than the others. The main target or the main use of that customer fragment is basically to protect the customer from us, not from malicious attackers. For malicious attackers, the whole model is safe and constantly refreshed between those fragments.

By the way, just to mention those fragments are being stored in node environments which are in different availability zones within multiple regions, so everything is replicated between regions. That’s a great thing by the way that we are so happy to work with the cloud, with such a technology because it just suits, it works well. Because when you have an encryption key as a whole, you never want to replicate it. That’s the whole thing about encryption keys. You want to have one encryption key and you don’t want anyone to have a replication of it.

But suddenly, when you have such a great model, where you’re working with fragments of keys then you can even do much greater things with having much higher resilience and much higher availability for your entire key management system infrastructure. So suddenly we can be multi-region available. So if one region is down we’re still running, if one cloud provider is down we’re still running. That’s part of it.

Ken: Cool. How do they interface? Is it so if I wanted to do this in my application is there a library to include or do I make API calls manually? How does it all--?

Oded: Lots of it. Basically we’re providing lots of plugins. Maybe I’ll start with this. Vault Open Source Project, I guess that most of our viewers are familiar with that. So, Vault Open Source Project has a huge community, very good community, of contributors that are creating plugins and connectors to multiple types of platforms.

So we have developed an API compatibility with Vault Open Source Projects. That means that in order to work with us, you can basically download whatever plugin that you’re finding out there from the Open Source Community and you can work directly with us. So boom, you suddenly have all of those platforms that are natively supported to begin with.

On top of that, there are SDKs in multiple languages, command-line interfaces, and obviously RESTful APIs. Whatever you’re convenient with. And of course web user interface and we have a browser add-on for human access, because although everything today needs to be API driven, eventually we’re working with people, so it needs to be colorful and it needs to be a great user experience.

Ken: So if you’re already hooked in with Vault, you can already use the technology in a sense that you’re kind of plugging into what you’re already hooked into with Akeyless, so if you’re already set up for Vault then you can build on top of that using Akeyless?

Oded: Basically yes, because imagine that you have a Vault Open resource for some usage of yours and then it starts growing and growing and scaling and scaling, and then you find yourself dealing with multi-region replications in multi-environments and leader elections and all kinds of things. Sometimes we like that, that’s fine, but we find that lots of enterprises don’t want to mess with that and this is where we come in the picture.

We’re saying, either have it with our on-prem package, which is a soft appliance that is very easy to work with, or work as a service where you don’t need to mess with the infrastructure whatsoever and you can basically take a Gateway API, which is a status Docker container, work with it and keep your current endpoints with the Vault Open Source that you’ve been using and the switch is very easy.

So yes, this is the target. Not necessarily with all. Despite the fact that Vault OSS is widely known, most of the organizations that we work with haven't implemented that yet. Some have it and some don’t have it. So it’s a large market.

Ken: I think most of the businesses that I’m familiar with that are similar to the one I work for, GitHub, have some of our own modifications to Vault, right? So it’s a fault, but it’s got some heavy modifications that I would say-- which is again why I liked it. I think there needs to be something that’s easy that’s distributed, and again, one of the things that I really like was the whole zero trust sort of model. And Seth, before I ask the next question, you look very pensive like you’re going to ask a question, so I want to make sure I give you the mic.

Seth: I was wondering, so we’ve talked about (HashiCorp) Vault and how Akeyless compares to that. I also wondered what more of the secret management API to API or computer to computer, the SSH access and like the human element that you keep talking about, Oded. How does that necessarily function? Is that one of those you sign into Akeyless first or is it integrated with SSL with your local system?

Oded: The second, yes. Our goal is to save a lot of time for the infrastructure and security guys, DevOps guys. And on the other hand, to change as little as we can, not to change the ways that people tend to work. So if the organization is already working with the identity provider, that's a plus. We don’t want to be an identity provider.

We do have a solution for the secret zero problem with Universal Identity, I can talk about that later. But in terms of humans of course, we don’t want to change the way that you used to work. So using any identity provider that you have, imagine that you’re running your Open SSH, your native supported SSH that’s working but without using SSH keys, and whenever you’re firing a necessary request then what you have is basically an identity and any provider request to authenticate.

Behind the screen that you are already familiar with we are creating an SSH certificate. Now that SSH certificate is created for a short-lived period of time and it is being provided to and created to the client's side and then provided to the target host. Now the only configuration that needs to be done on the target host is the trusted--

Seth: Certificates, yeah.

Oded: Certificates -- that’s a great solution. No agents whatsoever. You know what, you’ve mentioned the differentiators between us and the Vault OSS that is able to create SSH certificates to issue SSH certificates, but they never wrapped it into a one complete solution of SSO with SSH or privileged access management for Linux servers or for SSH access.

And that’s just an example where we said, okay, there are capabilities of managing the secret, but we want to go even deeper, we want to manage the secret through its whole life cycle when it is being used. So for that sense we are also leveraging our ability to act as a Certificate Authority and provide certificates also for Kubectl. Kubectl by default is using short and long-lived TLS certificates so the same solution for SSH, as I’ve just mentioned, with identity provider and short lived certificate for certain sessions, again, works well for Kubectl access.

And this is where we provided a 360 degree solution for privilege access and secret management for Kubernetes. Because it’s not just that we’re managing the secrets for Kubernetes cluster by integrating into the community secret mechanism, rather than also managing the access to the Kubectl management. So either the secrets that are being used by Kubernetes and also the secrets that are being used in order to manage the Kubernetes clusters. That’s just an example we do that for other places also.

Seth: Yeah, I would assume if you’ve worked that out then you’re also doing that for things like AWS keys like access, like the AWS command line, Google or Google Cloud, GCP.

Oded: Exactly. And when you mentioned those, this is where a great-- that’s a very interesting trend that’s happening in the last few years, very recent, that is called Just-In-Time Access. I guess that some of our viewers are familiar with the dynamic secrets approach but the father of it, the grandfather of dynamic secret, is basically coming from the privilege access management world and identity management.

This is why, for me, it’s a great area. I like that I can see the whole development of the whole market, how it changes. So Just-In-Time Access was invented a few years ago, and the goal of it is basically to go to the place where you have zero standing permissions within your environment.

So imagine that you have a database, for instance, that has lots of users within the users table or Linux server with lots of public keys for SSH, so those are lots of credentials that most of the time most of it are not being used. Problems with compliance and audit and those kinds of stuff and when someone leaves the team, no one really knows what kind of credentials we can delete and we find a lot of places where people are living the organization that we’re working, with SSH keys that are still valid and you all know that hassle.

So, basically when you combine all of that you can say, we want to work in a world where there are no standing credentials, zero standing privileges and for everyone to include human identities and also machine identities, they are all getting on-demand, Just-In-Time Access whenever they need to.

So imagine if a user or machine wishes to access a certain database or an AWS service or Linux server whenever they wish to access, they are asking Akeyless, please give us short-lived, short-time credentials, access, certificates, whatever in order to access that machine, and this is where Akeyless takes place and provide those temporary credentials. So eventually, not machines and not humans are working with static credentials for them.

Although you have very powerful DevOps guys, in the target host, in the endpoints you basically don’t have any credentials whatsoever, right? No public keys on Linux servers, you don’t have accounts on SQL servers and so on and so forth, rather than having those credentials created on the fly only when you need it and they are automatically deleted.

Seth: I mean, I’ve always been a fan of the Just-In-Time Access and it feels like what you guys have come up with is a very elegant way of-- we always talk about that layered security approach from applications. Authentication and authorization is more and more that’s where we find more of the problems with instances.

And so having the ability to basically turn off access when it’s not needed is a huge plus, right? That’s all that I see from an application perspective, because it takes me away. I’ve always said that I would much rather the amount of login forms and user databases that I’ve created in my career is ridiculous, right? I shouldn’t have to create the same thing over and over and reinvent the wheel and we’re getting better at that with identity like the IDPs, but this just takes it one step further because it’s not just IDP, it’s also IDP and you only have access when you need it so that those credentials don’t sit around.

Oded: What you’re now saying it’s wonderful and I’ll tell you why. You know, one of our great aha moments when we talk with customers is that we’re doing the following: let’s say we’re demonstrating a lot with Okta, obviously it’s a very known and famous solution. So we’re talking a lot with DevOps guys and we’re telling them, “How much time do you currently invest with organizing permissions for everyone?” Like someone is asking from you, I need access to that Linux server, I need access to that resource, I need permissions with my Chef, with my Jenkins, with my Kubernetes cluster.

How do you do that and provide permissions, permissions, permissions? And they are wasting a lot of time on that and that’s a great headache and we want to help them. So the big aha moment was when we’re saying, you see that group of Okta? When you will add a certain identity to that group or if you want a user within your Active Directory group, but when you do that, because we are looking at that group - we’re not synchronizing it, it is not provision to us or something, we’re just monitoring that group - just by doing that, that particular user or machine will automatically gain the permission to ask for access.

Then, the next time that individual identity would ask to enter a Linux server for a certain IP, the backstage would make sure that they have the permission to do so and then automatically provide short-lived certificates or credentials to the database etc. But eventually that’s it, so you don’t need to do much more than just organizing your users as you are convenient with, which is with organizational groups, team groups, application groups and things like this - all the rest is being done by Akeyless. Both for human identities and both for machines.

Seth: The Just-In-Time Access, I mean if we go back to the earlier conversation that we had about identity and access management solutions and we’re talking about the provisioning process and that’s, realistically, what you’ve done away with because it’s auto-provisioning based on a role, it’s role-based access. Auto-provision when you ask for it. If you’re not in the right group, you’re going to get booted obviously. So your manager has to put you in the right group, but other than that, like I was saying it’s an elegant way of handling identity.

Oded: I’ll tell you this. God bless the sub-claims of SAML, that’s basically it. There are a lot of different ways and alternatives but basically, when you already have a token coming up from identity provider—and by the way, I keep talking about identity providers for humans, but the same exact way working with Azure Identity and AWS assumed role, and GCP, CIM and so on, the same action, it’s very similar - this is JWT and that’s other things, but you get the concept.

So because you’re getting a token of an external identity provider you can say that, okay, if that token is within that condition then what does it mean in terms of permissions, dynamic permissions, within the great bucket of secrets, certificates, encryption keys, signing keys, API keys, SSH certificates and so on and so forth. So that's the beauty of generalizing that problem of secrets.

Seth: Yeah, the auto stuff is where the power really shows itself for sure.

Ken: I gotta say, this is really refreshing to see a CEO of a company getting this technical, it’s amazing. You don’t see this very often so I’m just sitting back like this is awesome.

Oded: I’ll take that as a compliment, thank you. Some people won’t take that as a compliment.

Ken: It’s very much intended to be a compliment.

Oded: Okay, thank you very much.

Ken: Sorry if I interrupted--

Seth: It’s fine. The other question that I had in that case, I mean you’re integrating with AWS, you’re integrating with GCP, but maybe for some listeners you can explain or just give us a rundown of the differences between what Akeyless provides as opposed to using something like secrets manager or certificate manager out of AWS.

Oded: Great, great. So, the two families of current solutions today are one provided by the cloud service providers as a service secret manager, certificate manager, parameter store, Key Vault by Azure and so on and so forth. The other family is the self-deployed solutions, OSS solutions, other big names in the industry that require you to have a complex IP project basically.

So let’s talk about the cloud service providers, basically those are walled garden approach, design, product, AWS. And that’s legit they are talking about their own environments. Organizations are hybrid, and if you wish to work with your AWS KMS, AWS secret manager within your third party tools, which are our own DevOps tools, right? It’s not natively connected. If you want to synchronize the secrets to all of your tools, some of them have maybe plugins that someone had but are not widely used, so they are pluggable in a very good way to DevOps tools, they’re not pluggable very good into the on-prem or legacy environment or the private cloud. How do you interact within a service or database that you’re having within your legacy, on-prem private cloud environment- to a resource that is on a public cloud?

You don’t have a mutual IAM to do so. So that’s basically it, so it’s all about the walled garden approach that creates a lot of hassle in terms of operation and a lot of architecture and designing some solutions. The other thing is that some of them are not replicating secrets and keys between regions. They have security concerns, to remind you, we’re working with fragments. We don't have any problems replicating fragments of keys between regions and to be available from within any region, so you don’t have to replicate your own secrets and keys, and so that’s another thing.

Some issues with-- I know it might be surprising, but there are limits to the cloud service providers, usage in terms of key management and secrets, 1500 per second, things like this. Some of them are more extendable than the others, but basically there are some limits and that’s, by the way, sometimes because they have hardware behind their software, they have hardware secured models behind their software. We’re a completely software solution and we’re FIPS 140-2 certified and that’s because of our technology.

So everything starts from our technology that enables us to do more and more things that the cloud service providers cannot do. And eventually security, which is you don’t want to necessarily share encryption keys with the cloud service providers because you are basically prone to CLOUD Act and there are large organizations, some Europeans, some U.S. that are having concerns about federal authorities that can have their hands on their encryption keys. And again with our solution, we’re agnostic that’s okay, we can have a warrant from a federal authority. We can provide fragments but we can never provide all of the key because we don’t have it.

Ken: Hitting those limits in production is fun.

Oded: Yeah, yeah. We have heard that from large customers that we were talking with. Actually, we were surprised on our own. We were surprised that there are those kinds of limits. But you know what, you can understand that. For us secrets and keys, this is our business, so we must be highly scalable and we must have an infinite ending and whatever resources that the customers are asking for and to have some local caches, some local cache solutions, local proxies that we can have.

We think about those problems of interconnecting environments. We think about how to make it very easy to work in a hybrid and multi-cloud environment. Now, for a cloud service provider-- and I don’t blame them by the way, I have a lot of respect for those guys, they’re doing a great job-- but in terms of what makes them busy, maybe it is less about interconnecting with other cloud providers and hybrid, they’re saying that they are, but we’re a startup. We can move much faster and I’m talking with a lot of modesty, that’s the reality. I hope you got an answer to your question.

Ken: Yes, sorry I think I lagged out.

Oded: Yeah, I said I hope you got an answer to the question.

Ken: Totally did.

Seth: That’s just what I wanted to clarify because we do have a lot of people-- I mean the majority of what we see is definitely AWS, that’s the 500-pound gorilla right now. Everybody’s in AWS, but there are some in GCP involved. But I think the most interesting one that I run into the most is what you called out as far as private cloud to public cloud. Because most of the large organizations, and even small organizations, have some sort of an internal network of computers that they use or servers that they use that are not integrated with AWS, IAM and with secrets manager and everything else that is in the public cloud. And so they’re having to go to something like an OSS fault or a different solution to do the same thing, or in most cases they’re just not doing anything and it’s all static. Especially if they’ve been around for any period of time.

Ken: When you say cloud can you verify that real quick, private cloud versus public cloud just for anybody who may not know, including myself, what you mean by that.

Oded: When we say private, basically it’s either your own infrastructure and your own Kubernetes clusters on top of it, it’s not managed Kubernetes. There’s virtual private cloud on top of public cloud AWS, GCP, and so on. Private cloud is basically for-- maybe the most easy way to explain it is to think about air gapped networks. They want to have their own Kubernetes, OpenShift, Dockerized environments. They are entitled to do that, although they are air-gapped. So they are entitled to go to the future and we love that and we encourage that. So this is where they are building their own private cloud.

That’s basically how it works. And this is why I’m mentioning that, so when you’re  talking with that private cloud, so it’s not and air-gapped solution but it’s a, let’s say a bank that already invested with their own infrastructure, so they’re saying, we’re moving to containerized environment, we’re moving to Kubernetes to OpenShift and so on. And we want to communicate with our other environments, which brings me to another very interesting point with how do you authenticate, how do you authenticate within a private cloud or any legacy environment where you don’t have identity management in particular two machines?

So back to stage one, you need to hold an STS token or you need to hold an AWS identity or Azure static API key within your internal environment or your whatever legacy that you wish in order to interconnect to external resources. Which brings us to the beginning again, I’m having a secret within my code, secrets within my CI/CD pipeline and I am having it inside in order to communicate with the external work. So how do I do that? There are no identities.

This is where we provide Akeyless Universal Identity exactly to solve that. I won’t get into too much details because part of our IP is how we do that. But, basically we provide an identity to a machine that doesn’t have an identity and that particular identity is not a secret. I know it sounds like, again, something-- I have a lot of contradictions today, but this is part of the magic that we do right otherwise it was not interesting. So this is what we do, we provide an identity that in case it is being stolen we recognize that and we are identifying that and we are having some event go to SIEM/SOC operation and this is where we provide machine identities.

So, for an SDK that is running within your legacy environment or your on-prem environment or whatever CI/CD process within Jenkins, suddenly they have an identity but they can access the secret management system to fetch other secrets without compromising the secret zero. That’s basically how it works.

Seth: Yeah we have been going for about an hour. We want to be cognizant of your time on it as well as-- we’re all busy still. Even though everybody is in quarantine. What is the best way to interact with you online, just find you at Akeyless.io or Twitter?

Oded: Akeyless.io as you can see right now on the screen. We’re on Slack also you’ll find it on our pages. You can just go ahead and sign up. It’s SaaS and we also have on-prem but it’s SaaS and a free package that you can start using and playing with it. We have support within using Slack or emails if you wish. So whatever you’re convenient with, feel free. Akeyless.io, this is the first place to go and we can hop on a call, whenever someone is interested.

Seth: Yeah, great. And I would encourage people to reach out. I mean obviously it’s a problem. I know even the projects that I work on. Open source and otherwise, it’s one of the things that we always end up fighting with. We’re deploying something to AWS and then it’s even a different cloud provider and we start to think about secrets in dev, QA, prod, all the different environments and it’s just not necessarily an easy problem to solve without a solution in place. We’ll push people in your direction and we’ll keep the discussion going because it feels like you’ve got a good foundation and you’re moving into spaces that are crucial to security and in Appsec like in general.

Oded: Thank you very much guys for this opportunity. It has been a very interesting talk. And we’re privileged to be on your show. And I hope to see you live here in Tel Aviv, mostly welcome. We’ll grab a coffee and a beer next time you’re around.

See the Akeyless Vault in Action