Secrets Management in Complex Environments at Scale

Secrets management is becoming increasingly important but remains difficult to implement, scale, maintain and secure in complex environments that can include multiple on-prem and cloud instances. During this informative session, you’ll get to hear from an industry-leading panel on what the key challenges and considerations are when choosing and implementing a secrets management solution. Why Progress chose Akeyless for their internal projects. And how Chef and Akeyless are working together to simplify the implementation of multi-cloud secrets management for Chef customers.

So let's start by understanding a little bit about what secrets management means. Oded, do you want to give your perspective on what is secrets management, and why is it important?

The greatest beginning of the question is handled to me. So secrets basically are objects that are being made to authenticate and authorize between-- in any computerized environment. We're talking about passwords, credentials, certificates for SSH, for TLS, to identify machine identities. We're talking about SQL credentials, about encryption keys and signing keys.

Basically, this is the realm of all of those different types of objects. This is defined as a secret, something that you would not want anyone to know, which is not necessarily related to the data itself rather than the access to the data itself, OK? So this is what defines secret.

Now, the managing or the management of those secrets is about the process of either the ability to store, protect those objects, the ability to provide those objects whenever they're needed, and also to be able to create those objects whenever they're needed on-demand, on a just-in-time manner, to be able to create credentials for SQL that are temporary, or to create short-lived certificates whenever they're being needed.

Now, the whole purpose of what is being done, and why is it even important, right, is that when you think of those objects that you wish to protect, currently, those objects are being shared as sprawled secrets. There's a phenomenon of those secrets that you can find within source codes that leak within public repositories. You find those secrets, credential, certificates, and keys that you'll find them within configuration files and within script files.

And the problem in the last few years was basically several trends that have made the usage of those secrets to become-- to have a major increase. So we're talking about automation, the DevOps movement, the use of cloud, the cloud transformation. We're talking about zero trust, which has increased the use of those authentication and authorization objects, right?

So all of those trends basically made the rise of the number, the increase of the number of secrets and authentication objects. Then this means that they are now-- that the risk of having those credentials is basically increasing. And this is why they need to be managed and to be completely deleted out of your environment.

As a summary note, the future of secrets management for that sense-- and we'll have a better maybe dive into that-- would be in the zero standing communities, to basically to be able to completely eliminate those secrets from your environment, to be able to provide them on real time. We'll get to that later on.

Thanks. That was crisp and actually extensive, as well. So from what I understood, you are saying that secrets is actually a collection of different artifacts, keys, credentials, and like that, which are used to secure different information or different data, aspects within an organization. And we need to keep this secure. And that's where secret management is important. And the fact that the scale is coming-- it makes it even more important.

Richard, maybe you might have seen this a lot in your practices. I think Oded kind of eluded that these days, there is more and more emphasis on secrets management. From your perspective, why are we seeing that secrets management is important? And why should someone consider having an active secrets management implementation or thinking?

Yeah, it's a great question. I mean, just take your personal passwords, right? So I use a personal password manager. I logged into many websites today. I just looked at my vault of passwords-- I have like 120 passwords that I keep. I don't use the same password across all my logins, because that's really bad practice, right?

The same thing, same problem in a corporate environment. You're logging into APIs, you're logging into servers, you're logging into CI/CDs, you're logging in-- and the more this all automation, it's going to continue to grow, right? And I think that's the sprawl that Oded was talking about is that secrets are everywhere.

And if I was an attacker, right? Like if I was an attacker and I want to get my footholding, that is the very first place I'm going to go for. I'm going to try to get into your account, I'm going to try to get a token, or I'm going to try to get an API key.

And if you don't have a good way to, one, manage all those secrets, and also dynamically change it to say like-- you know, just coming from the SOX days, we found that, say, like a secret was compromised. How quickly can you change that password or that secret on a dime? And with the solutions today, with what Akeyless is providing and other competitors, they're able to do that. And that's why secrets management is so important.

Thanks, Richard. And Chris, you meet with a lot of customers and organizations. Do you see this trend-- do you see it this awareness now? And if so, why do they seek for a secrets management solution now?

Yeah, I see a lot of customers who are interested in trying to figure out that particular problem. And I think it's arisen due largely to the fact that most folks are trying to migrate into using containers in different sets of data, therefore having different sets of keys, not unlike, say, an apartment building, where you have different apartment rooms with different keys, right? And then you have a master key that could get into all of them.

But part of the problem, the bigger problem, is the fact that they do multi-environment production systems, right? So they've got-- they're using a little on-prem, and they're using a little OnPrem and maybe they're using some in AWS, all of which might use a different key standard or might need different key standards.

But large in part, when you're trying to develop from this side, when you're doing the actual operation and putting applications and servers and infrastructure out into the environments, you want to build them correctly in the beginning. And so when the developers are trying to move very quickly, you often see exactly what Oded said, right? Many, many times, I see keys, and tokens, and identifiers put into code, which should literally not be there. And that's the quickest way, as a hacker, I'm going to get infiltration, right?

That's the first thing I look for, whether it's a phish from an email, or sniffing out servers that I can have access to or have open access to. Being able to use authentication methods, and using those keys to get into those things can help you, number one, meet the regulations that the government has put forth across everyone in the industry for the web. And then two, ensuring that, just simply, your user base feel like it's a trusted place where they can go and actually conduct business in a secure manner.

So you're saying that there are-- they have to deal with a wide variety of environments and also changes and the transformation that they have made the migration from OnPrem to cloud where containerization and things like that, which has made them a little bit more aware of these vulnerabilities and want to secure those things. Oded, do you see any such patterns where organizations are reaching out to someone like you or your teams on they need to invest in secrets management? What are some of the trends that you're seeing on the intent behind looking for secret management?

Yeah. So very interesting trends that we are noticing-- first of all as Chris has mentioned, Kubernetes, the use of Kubernetes and the containerization is definitely a driver that we see that keeps repeating again and again. Customers that are saying, listen, we have so many secrets that are being used by our workloads, and we need to make sure that those secrets are being protected. And some of them are using the native Kubernetes secrets mechanisms.

And some of them understands that in order to scale, right-- as the topic of our talk-- in order for them to scale, they need to have-- sometimes they are using Kubernetes clusters on their AWS, or Azure, or GCP, and they're also using some Kubernetes on the OnPrem. And they need to have a centralized environment to basically manage, or a centralized system to unify the whole management around those secrets' lifecycle and so on. So that's number one, the containerization.

And by the way, that containerization, the break of the monolith, is also another good driver that basically drives the whole industry of secrets management, because suddenly you've got a much larger number of components that need to communicate with each other, and as such meaning that they need to use much more secrets. So this is number one in terms of trends.

We see a lot of requests regarding the CI/CD tools and configuration management, obviously, right, like in Chef, tools like Chef and others, basically leveraging lots of secrets, lots of credentials, in order to operate. Chef Infra, Chef InSpec, those are just examples of products that are using credentials in order to authenticate to other machines. So definitely in that aspect.

So, yes. CI tools, orchestration, configuration management, and provisioning, those are the drivers that drive the main use cases for secrets management. Just one quick note regarding what Richard was saying, because we've seen that as a very interesting trend, at the beginning secrets management was you might have say traditionally was around workloads, right?

So people were saying, OK, we're keeping our own personal passwords on tools like personal passwords vault, we're keeping our own passwords on maybe even on privileged access management tools for the most advanced part where secrets management specifically was dealing with the scaling-- the scaled workloads and automation.

So secrets management is basically about providing an API-driven channels, right? To fetch for a secret from CLI, from SDKs, from plug-ins to Kubernetes, Jenkins, Chef, and so on and so forth.

Now, we've seen a great trend in the last year or maybe more, of more and more customers that based in organization that we're basically saying, hey, secrets management is so good with providing just-in-time access for workloads and with a higher scale and understanding the cloud environments, why not leveraging?

So the same capabilities with our human to machine interaction, in which overlaps with privileged access management. Just as a side note, this is where we kind of understood that we need to extend our functionality and to have the Secure Remote Access offering. So it's kind of an extension for secrets management.

With Privileged Access management vendors you see actually the opposite. They came from human passwords and credentials, and are trying to extend to the secrets management world of the workloads. Yeah, so this is just as another interesting friends as you've asked.

You called out I think two or three times here how one is extending man to machine interaction to machine permission, and applying some of the privileges that we've seen in one in another. And second, you've called out the monolithic architecture of to a cloud-based microservice or architecture.

And third, you also-- you and Chris both highlighted that there is more adoption towards cloud, so there is more and more multi cloud, hybrid cloud setup. This means that organizations might be thinking about secrets in a traditional way but there are many more factors that are evolving. And they are not-- and on the other side we are also seeing increased pace of application, development, and deployment, but almost our ability to not have a governed architecture because developers decide this architecture deployment model.

So there seems to be a gap in how things were and where things are headed. Richard is that a pattern that you are also seeing, some traditional approaches whereas some current state of the art approaches? There must be advantages and disadvantages on both sides. Do you want to share some of your thoughts and experiences on this?

Yeah, so it depends on-- so from my experience there's still a lot of organizations that are doing traditional OnPrem legacy IT, right? So their passwords are still very static. They're not as dynamic. And so they still have to work that. Like you said, they're still working on very monolithic applications. So now they're evolving, right? Like they're breaking things into market services so that there could be more resiliency and more scalability.

Yeah, I'm seeing more trends of moving from OnPrem into the cloud and that's a challenge itself. That's big for any organization, from moving from a workload from OnPrem to the cloud. Now you've got to-- now you're trusting whether it's AWS as your Google, and then going into Kubernetes containers. It becomes a different workload and different type of workflow. And so now you have all these passwords and all these containers, and it becomes-- it has to be managed, right? It has to be centrally managed. And that's really where it comes down to.

I do like the fact that you have a system that can also work across different cloud environments. So whether you're in Azure, whether you're in AWS or Google, and truthfully a lot of companies are starting to look at that. They know and realize that they can't have all their eggs in one basket and just put everything in AWS or just put everything on Google, they have to be resilient.

And that's why having a solution like Akeyless key and having that ability to be dynamically resilient across different cloud infrastructures. Even OnPrem, a lot of companies are still working on hybrid mode need to have that resiliency and I think that's where Akeyless was able to provide that for us.

Thanks, Richard. Chris, do you also see such concerns or do you see that dichotomy of traditional versus new paradigms? And do you see any pattern emerging where they're trying to bridge this gap?

Yeah, so I think to Richard's point, there are always going to be OnPrem and/or air gapped development areas, and/or production areas, they're never going to go away simply due to the fact of that particular type of data not being able to be released or be at risk of being leaked or whatever that is, right.

So credit card data, personal information, GDP information, whatever that is, we want to ensure that-- and the whole reason, let's be honest, the whole reason for these types of technologies is to section off or only allow accessibility to certain parts of data, right?

So where I come from the biggest, most highest clearance level you could get was called, need to know. Wasn't necessarily a traditional level, but it was at the end, hey, you had all these cool clearances, but in the end it was always with every level, it was need to know, should you see this particular type of information?

And so that remains, but we've never ever before had the ability to scale such as we have today. Whether it be Iron, or microservices, we can literally do hundreds of thousands of transactions at scale today. And most of that is due largely to the backbone of automation.

So when we talk about doing those things that transition you're asking, do you see trends in that transition? Well, yes, right? Because we saw the birth and the practical use of DevOps, and how we start to scale and create resiliency in what it is that we're doing, and now the bigger trends are more towards DevSecOps where we're trying to build that security into that operational model where we're developing things with security or aligned to the security policies and practices that we have.

And groups like Akeyless, the tools that they bring to the market are absolutely essential when we're trying to scale. Here's one big reason why and what I see in the field. You have a number of customers who are creating-- well, number one, breaking down those monolithic applications, but they're creating an enormous amount of sectionalized data that you need to have certain access to.

There is absolutely no way in a traditional format that you're going to keep track of all of these passwords and/or tokens, and/or everything you need to have that access. And to be able to do that and feel trusted about it, is going to take the tools like Akeyless spring.

So those are absolutely essential. If you're shifting way left, they are a big prohibitor, right? I call them the great red octagon of hey, stop right now, let's make sure that you're able to have that access. so you have a need to know for those particular things and you can move on.

Because the reality is, we want this to be fast, right? But what do we talk about being fast, being faster, how do I beat my competition? How do I get that application out as quick as I can, or beat the market, or mission ready, whatever that is? You want to be able to do it and do it in a quick fashion.

A lot of times through automation in this scale business that we have, we tend to create shortcuts, right?

We have group logins, we have group policies, we have group-- and then we're not tracking individuals and what they're doing and how they're doing it. Whether it's harmless or not, if Prashanth, is going to get his son's basketball pictures off a server is quite harmless and maybe not needed, but somebody infiltrating, like Richard, trying to get in and go, well, you know, I'd really like to understand what kind of data you got on that server, 2 completely different things. Maybe you work for the same company, but you need to have the ability to track that and it's easily done through secrets management.

So you're noticing that this kind of OnPrem, and cloud monolith, and micro service Azure scalable architectures are going to be there together for the foreseeable future.

And you're seeing the organizations use some of the approaches like data fragmentation, data segregation, giving privileged access and using the softwares which can be used to manage the secrets across the platform as a way for them to move from where they are to where they want to be, in a planned manner of using automation as one of the tools to help them get there.

Oded, where does the secrets management plug, maybe the question I want to rephrase, where all does secrets management plug-in the automation aspects of application development and deployment?

Yeah, so basically it's in the core of it. secrets management can go into either more classic of IT right behind the scene with Configuration management, and controlling your fleet, and orchestration, et cetera, right? Which is all around the automation there. This is one place where you finding lots of credentials, passwords, certificates, encryption keys, signing keys, that you need to have and to manage.

And the other realm is around the CI/CD and development, and software development lifecycle, which ends at the orchestration platforms, right?

But basically around compiling-- developing your code with clear formatting in terms of not having secrets there, to be able to fetch secrets either via SDK, or to expect the running environment to provide you the secrets within the environment variables or virtual files Or whatever. And to have configuration files to be totally clear out of those secrets. So this is like the first step within the development cycle.

The next one would be on the CI step, which is to make sure that within the CI-- the CI scripts of the jobs themselves you would not have any secrets that would, for instance, the most famous spy is to have an API key for your GitHub or GitLab projects, right? So right now think of the API key not to have within your CI rather than pulling it automatically on real time and dynamically from a ticket.

So that's on the CI. Next, you're getting to the CD, right, basically, the delivery, and also the provisioning, where you're actually creating those other machines with those binaries that you have created and after the testing processes that you've made. So as you can see, secrets is all around our process, and basically to make sure that each one of those steps is being protected by not having static secrets inside, rather than getting those dynamically created or dynamically fetched from your repository.

Thanks. You kind of highlighted on some of the ways to mitigate these challenges, especially when organizations try to solve this by automation, which is a loaded word, loaded term, and also misused in many ways. But you called out how we can plug secrets management in CI/CD, and how secrets management in deployment and automation. But this might not be very straightforward.

Richard, maybe you deal with it more often because you have to not just work with different teams where there are a lot of product lines and each of them have different architecture-- add to that, there are acquisitions that companies do, where involuntarily, they inherit an architecture or a set of practices for which you might not be ready with an approach or a strategy. So how do you approach-- or what are the patterns where you have seen solving these challenges that come in an unplanned and heterogeneous environment?

Yeah, that's a great question. So maybe I'll go into the use case for Progress. We were using an open source solution. And we used it. And I think we got to the point where it could only provide us as much as it can as an open source project.

And you're right, because through Progress's strategies to growth for mergers and acquisitions, and scale, teams are adding new products. One of the things, when I first started here at Progress about a year ago, is I wanted to provide a central service that can be consumed very easily, right? I didn't want engineers and developers to think about, oh, I've got to go and develop or build a secrets service, or consume a different-- I wanted it to be central and very easily consumable.

Not only that, I also was looking for a solution that would help migrate my current secrets into a central solution. And we did find that. And because now I can centrally manage it, just so many much more benefits to the scale, even from a security monitoring perspective. I can see the flow of these secrets being used. I can see where they're being used and how it's being used. But, yeah, for us it was, be able to provide a service back that I can give to the organization that they consume very easily.

It's a self-service, so that's also a big proponent for us is to make sure that it's a self-service, so you don't have to reach out to security and say, hey, we need secrets, and go through this whole lifecycle again. No. Here's the documentation, here's how you get it. You want access to it, just put in a ticket, make the request. We'll provide you the namespace, and off to the races you can go and do what you need to do without security getting in your way.

Because that's-- and unfortunately, security has done that in the past, it's just, we're just guilty of it is we become that speed bump. I'm trying to avoid being that speed bump. I'm trying to enable for engineers to just work faster. So yeah, that's how we've done it and approached it.

So interesting, you've highlighted upon multiple things, at least two things that caught my attention. One, is to identify a solution that meets most of the use cases, hopefully all, but at least most of these cases and can scale to organization needs. And you feel that investing money or spending some dollars, that is worth it, rather than utilizing an open source software which could not meet all the needs.

And second, I think is very important, which I think developers and development teams kind of dread most of the time, which is working with the security team, which you seem to have mitigated by making this as a service, a centralized service, which is available for developers and development teams to self-serve. So is there something that you see as a lot of organizations are doing, is this the way in which they're planning to govern such a sensitive aspect in the whole policy of security?

Yeah, and it's funny, right? So I've been in environments where the pendulum has kind of shifted back and forth. So in the beginning at DevOps, in my experience, developers wanted a lot of autonomy, right? They went through the pains of working with IT, of getting systems, and there was a long lifecycle just to get just the system. And then now, they have the ability to put their application.

So the engineers are like, no, I want DevOps. Give me the autonomy. We'll build the systems. And cloud enabled that, right, to big degree. So then that's that pendulum swing, that side.

But then eventually, engineers realized that there's a lot of work in Ops. Not to take away that developers have a lot of work, but they're also trying to get that feature, they're trying to release that new product. And so they said, well, we kind of want to really focus more on the development. And so that kind of swung.

So depending on your organization, depending on the maturity of the organization, I would say it really depends how they want to-- whether they want to do it centrally, whether they're going to do it autonomously in different teams. I know some environments are completely decentralized, and that's how they operate, and they operate well that way. And that's fine. It really depends on the organization.

Yeah, I think you called out an interesting part, which is organization maturity and organization investment, well said as how serious are they in getting these practices in? And I think that's where policy, and governance, compliance, all of these things come in.

And Chris, are we seeing these secrets management being inculcated as, let's say, through their compliance, or organization security policies? Is that being codified? Is that being enforced through policy as code, or compliance as code? Is that something that you're seeing?

I was just thinking that, Prashanth. It's about circles of trust, right? And the only way you trust is if you're compliant with the regulations or the policies that happen therein. There are a lot of things around what those regulations entail, right? I've got standards for 140-2 compliance. I've got standards for PCI compliance, HIPPA, and it just goes down the scale.

And so once those things are implemented, right, as a standard, then you can start to look around, let's say, access rights and the agileness of how you're doing that development, yeah? Because, as Richard just said, you can do this at a small scale and still keep the old ways of tracking and managing all those secrets and passwords, and things like that.

But once you get into like at an agency level where I live, it's nearly impossible. So those circles of trust start to go out the window, right? Do I know who you are? Do I know what business you want to do?

It's like being at a bar and getting an Israeli driver's license. I've never seen this before. Why should I trust this? How do I know that this is something-- it's not a standard, right? I'm used to seeing the stuff that I'm used to seeing.

And so there's got to be a method by which I can say, well, Oded's a good guy. And I don't know about this Israeli driver's license, but I think he can probably drive. Where would I get that information, or who could vouch for him? There's other methods to do that. But it's a circle of trust in terms of, hey, let's understand my environment, right?

If I don't understand my environment, and I have assessed the risk at which the data is being contained, and/or managed, and/or secured, then I really can't get my arms around a risk management system, right? Because I will have evaluated, hey, so this data in, say, Project B is less critical than, say, the stuff that I've been managing in HR, or through finance. And those scales get higher. And then we start to talk about money, and how much we're going to spend on securing those things.

But yeah, when you're at scale, when you're in those large agencies where there's huge, like big corporations that are doing hundreds of thousands of transactions, and hundreds of thousands of servers, and things like this, you have to understand that, hey, I've got a good method. I understand the way at which I'm generating credentials and keys, and I have standards around that. And they should be built as such.

Akeyless fit that gap for us with the 140-2 compliance that they're doing, especially from a federal sector piece. Those are the types of things that you look for to build in as far left as you can. But codifying those policies to be able to understand and test as you go, really gets you going faster than you might think, right? Because just having direct access doesn't necessarily make you go fast, because you end up breaking things in the end, or you end up putting static keys and things just to gain that access to correct certain things that are broken, to which break dependencies. It can be a very complex mess when you're in a big, huge, corporation.

I think scale certainly makes us think on the solution that we want to take and how we want to implement it. Like, it's been a very interesting discussion. We've touched upon what is secrets management, why are organizations thinking about it, what are the different approaches that are there, and what are some of the challenges and how are organizations trying to solve them?

Let's shift gears a bit and hear from you all on where you think is secrets management going? Oded, you alluded at the beginning of this conversation, so let me start by asking you this question. And then let's hear others' perspectives. Please feel free to jump in, all of you.

Sure. So I'll get to that. Just one note before regarding the scale that Chris had just mentioned, and maybe to add some more, one of the great challenges when we're speaking about scale is about having the hybrid environments, that you're having multiple environments, and you have secrets there and there. And then when you're considering a multi-cloud initiative, then currently that you're having-- suddenly, you're going to have lots of environments. And in each of every one of them, you're going to have your secrets management service, if you wish, like Richard have mentioned, when you're dealing with enterprise-grade environment, right?

It will start basically, from our experience, around 1,000 employees company up to the north, right? You can go up to dozens of thousands of employees companies, where you see all of those environments and dozens and hundreds of those teams of developers that need that secrets management service. So the scale would not be just around having to serve all of those development teams, rather than also to be able to synchronize and replicate those secrets between altering environments, because suddenly you're running application from-- workloads on Azure, and workloads on your OnPrem.

And then you might find some of those secrets need to be on those locations, because suddenly you're running a multiregional application. And then you need to have them both in Europe, and in the US, or US East and West. And this is where it gets messy, because suddenly, you find yourself with-- you know, this is not your main business to have synchronized secrets in a very large-scale manner.

And you find yourself dealing with a supportive system to the production environment that needs to be in a highly available manner, just as your production environment. And usually, that was-- for the security realm-- that was in the network, right? Therefore, security guys, we're providing network security that provided that level of high-- 4/9 of an ability for the production environment.

And suddenly, we're being asked, as security practitioners, to provide application security at the scale of the production environments. And I think that is very unique for secrets and keys management. And this is why, obviously, Akeyless is providing that thing from the external, like SaaS. What we're saying, basically, this is why what we have recognized, and this is why we are offering it as SaaS, to have it like within its our headache. We do that for our customers for them to use. So that was just--

It's an interesting-- I mean, I want to latch on to that point because it's an interesting one, right? Because it's always been a trade off of no access versus secure full access, right? And also one of the paradigm that people generally face is security says no, whereas development says no security. And in this case, I think that context is you've got to secure your data and information. For that, you have to externalize your secrets.

But having access to that secrets is as important as having access to the application itself. So what you're saying is, if you can't access the secret on time every time, you will end up having downtime or degraded service for the users.

Exactly.

And that's another dimension of complication, which scale brings in.

Exactly.

Thanks for kind of demystifying the challenges that come with sale, because scale is something that we always see from application or a user's perspective. But this is something that happens in the background. And it's interesting to know the different dimensions and all of that.

Definitely. Lots of environments, hybrid, and so on, exactly. But I still owe you an answer, by the way.

Let's get to that now.

Yeah, sorry. So after having this thought-- and by the way, Chris' image is a bit frozen. I don't know if, Chris, this is-- maybe it's only on my computer.

No.

Chris, maybe try to turn on the video and then--

Oh, now you're live.

OK, you're back now.

OK, great. OK. So going back to the question regarding the future of secrets management, the things that we see also, where are we heading? So I've mentioned at the beginning of our talk, zero standing privileges, and just-in-time manner. And so it's different dimensions.

Number one is around how to consume the secrets management service or how to consume that. And I've mentioned SaaS. Obviously, there are other alternatives, as Platform has a service, and so on. But we believe in SaaS.

But basically, the way that we consume secrets management is shifting and is more and more around-- if before, we thought about having it like self-deployment, now because of the challenges of the scale, there is a movement to go like to consume secrets management as a service, as a platform, and so on. So this is number one trend, and we're going to see that more and more going into the future.

Number two is around the understanding of zero standing privileges and just-in-time that basically says, instead of working with fixed credentials, which are prone for compromise, those fixed credentials can be exposed via logs that the application is auditing, or any time that there's some kind of malfunction and ills, then our application tend to provide those memory stack and so on, and provide those credentials outside and so on-- so there's a shift to go into dynamic credentials, right, dynamic secrets, temporary credentials, depends on the term that you like the most.

But this is a very interesting trend that we're going to see more and more. It's like adopting the ephemeral nature of the new cloud environments, of the new DevOps environment, automation, and so on. And also to fix and to provide an answer to it also in the realm of credential certificates and keys. So for instance, instead of using long-lived certificates, we're speaking now on short-lived certificates that will be automatically revoked. Instead of speaking about fixed credentials through SQL, we're speaking now about just-in-time dynamically created credentials that would be provided for instance, for a container or whatever it spins up, and then deleted automatically.

So this is the movement towards zero standing privileges and just-in-time. And here, I'd like to add number three, which is-- and this is something that was not yet, let's say, spoken yet. But this is a trend that we see is--

Bleeding edge, I would-- would you say? Is it under bleeding edge?

Yeah, definitely the bleeding edge, which is the overlapping of secrets management, the secure remote access with a human approach, and also the overlapping with a zero trust initiative. And this is something that has become-- we are seeing it more and more. And this trend is amazing.

Like, when we started we said, OK, let's manage those secrets and let's understand well, how can we do that better with SaaS, and so on? And then, the next trend was, you know what, instead of just doing it with workloads, do that with human also. And then they came the overlap with pam. And then suddenly, what shook us-- and we've seen that with another customer and another customer speaking about, hey, you know what, secrets management and secure remote access, and all the realm around just-in-time access is actually overlapping with our zero trust initiative.

This is something that is going to be very major in terms of seeing more and more the machine identities management within the zero trust. Currently, we see zero trust more about the human access. But we're going to see more and more the involvement of zero trust workload access, which is going to be rising. And we're going to see that more and more in other places. And yeah, those would be the three trends in the future that we're going to see more.

This was actually very interesting, intriguing even, especially the third one. Let's come back to that in a bit. Richard, Chris, any other-- any insights that you have? Are you seeing more of any of these trends?

Yeah, definitely, secrets are not-- they're not going to go away. It's going to get bigger, and larger, and wider, and the scale is going to continue to grow. Everything that we touch today digitally has to have a secret of some sort, at some level. So it's always going to be needed.

I really like where Oded's talking about the zero trust, because there is a big movement-- and you hear-- and I know the marketing terms can get overused, but there is definitely movement towards zero trust. And zero trust means-- I know it means different things to a lot of people, but it's about dynamic, just-in-time. You have confidence that whatever connection you're making is secure and trusted, right? And I think having dynamic secrets, and the ability to do that through automation and just-in-time will enable that.

If you can develop like-- going back to the administrators-- if I can make sure that my administrators never know their password, but it's based on a bunch of factors, whether if it's your phone, whether it's the laptop you have, the location that you're coming from, or the browser that you normally log in from, that gives me higher confidence that I'm not being breached. And I definitely see that's the trend where the organizations or the industry is going.

Chris, I'll get to you. I want to hear your perspective. But Heather, would you mind the checking of the channel and see if there are any questions that our audience want to ask? Because this is a very interesting discussion, and we can go on and on. Let's see if there are any questions from any of the attendees. Chris, back to you.

I agree completely with both conversations there. It's definitely a trend where we're going in that area. I would say it's slower moving in some areas than not. And one of the reasons is because when I spoke earlier about that circle of trust, when we're providing our credentials to an entity, or to-- even in machine language, we want to make sure that it's authenticated, we want to make sure that it's coming from a source of which we trust those things, right, and that's what makes that service so important.

And that's with the inhibition. Do I know where this key has coming from? If it was auto-generated, how do I know it's a good key, or was it generated from some unknown entity, or some bad actor that's trying to infiltrate? So being able to, number one, trace all the way back to the source and understand how it's generated, even generating your own keys through automation, obviously, but randomly, I think it's definitely the way to go.

Randomized keys with time limit basis is definitely a big trend now. Yes, it's somewhat cumbersome. I think Richard called it the speed bump of development. But we have to start getting used to-- we've been going at such a high rate, now, we're able to multiply that times 10. And so we have to just start building into our muscle memory those things and practices at which we're building those things out securely, and using the best, latest and greatest tools that are going to keep those applications and infrastructure that we're deploying secure.

Thanks, Chris. Heather, do we have any questions that we should take a moment and answer?

I have to say, you all are like a five-star panel and have been answering questions as quickly as they come in. But I think there is one theme of questions around, in a complex organization, even one with edge locations, a mix of technology, like, you don't know what you don't know. How do you get a handle on even what all the secrets are out there, never mind starting to kind of manage them proactively?

I'll take this one, Heather. Yeah, that's a challenge, that's for sure. I would say don't try to boil the ocean. It's impossible. You've got to start off small.

You've got to get, I would call it believers or champions in your organization. But yeah, in any large enterprise, especially when you're going down this path for secrets management, you've got to start off small. And then just get some quick wins, and then eventually it will, through word of mouth and make it to circle of trust, you will eventually get and find those skeletons under the rug, because yeah, it's tough.

And no one wants to-- I hate to say this, but we don't want to admit that we're practicing bad practices, like that we have secrets in places that we normally would work in. You just need to start off small. And then you build from there. That's what I can recommend.

OK.

Great, I think the other set of questions-- of course, this is ChefConf, and we have all of our Chef users out there. So there's been a few questions about how to do Chef and Akeyless work together? Is there any integration? How can I get started trying the solution?

Chris, would you?

Absolutely.

My answer would be immediately. Akeyless website, sign up, have the plug-in together with Chef, and you'll be immediately ready to start going. Everything is documented, it's ready for you. But please, Chris, take it from here.

Our chat's coming out of the screen. Yes, absolutely. That's probably the number one way I'm going to recommend. And I do that openly. I know Oded can't reach me from here. If he could, he'd probably grab me by the neck.

But, Yeah, so when we build these, and no matter what you're using, no matter what DevOp you're using, whether it's Terraform, or Jenkins, or whatever it is that you're using, you want to build that practice in. Build that API piece.

I actually just posted about a realtime integration using Akeyless. So check out me on LinkedIn. You'll see an actual demo of us integrating in with Akeyless and bringing those points in.

You build it into real time when you're actually doing-- right as you're going in to CI/CD-- which Oded already took the Thunder out of that one-- when you're managing between those sites, it's absolutely essential, right? Because if you can build that API into the code that you're building for the practice, then you absolutely know exactly where you are and what you're doing. Or it will tell you for sure.

My big problem personally that I have is, I'll switch my demo centers in between say, Ireland data center and maybe Oregon, and I don't have the correct images, or I don't have the correct credentials. I need to have my credentials and my certificates in both areas. Do I want to keep them there? No. Do I want to rotate them? Absolutely. Do I want to change them often? Yes, I do. And Akeyless makes that seamless as you build it in. And it's not a headache. Go check it out. There's a lot of ways that you can--

Heather, if I'm not wrong, aren't we having some deep dive sessions a few weeks later or a few days later about this topic? Oh, there we go.

Yes, in fact, we are, Prashanth. We'll be having a webinar later this month, which Oded will be back for, along with Tim Smith, the Product Manager for Chef Infra. He'll be showcasing kind of the new secrets engine we've built in Infra and how that integration actually works together. So if it's something you're interested in, definitely check it out.

Yeah, actually on our side is going to be Ori, our VP R&D and Chris, our Solution Architect. You'll be seeing the whole thing.

Awesome. Looking forward to learn more. And I'm guessing our practitioners are also interested to learn more about this. Heather, do we have any questions or should we try and wrap this up? We can go on and on. So I'm looking for your guidance on where we stand with respect to time.

That we can. I think we're out of questions. And we're about out of time also. So we go ahead can wrap things up.

So before we wrap this up, let me ask my customary question in such discussions. This has been obviously very engaging. And for me, it has been very enlightening and learning experience. I'm sure it is for the audience. But if they were to pick one key takeaway from this discussion and apply it in their practice and their organization, what would that be? Chris, let me start this with you.

One, wow.

Yeah.

One good one, mine would be that I love to see the trend from all aspects, right? Because we all kind of stay in our lanes, our verticals, and we understand our practice from that aspect. But to be able to see it real world, we have an OEM provisioner for SaaS. We've got a practitioner in Richard.

I don't often get to see outside my lane. So understanding the trends and what industry is doing, where we're going with it because it's so hard to stay in front of technology these days, but understanding those trends is a good way to be ahead of the curve. So that's the biggest thing I took away.

Awesome. Thanks, Oded, what would be your key takeaway for our audience?

Start soon, start small. And don't wait for your environment. You already have lots of-- when you feel like you're growing with your dev-ops movement, when you're growing with your environments, either it's OnPrem, cloud, like a private cloud, or moving out to the public one, you need to have some kind of a secrets management initiative. Machine identities is definitely something to look into. Those should start soon and small to go through whenever you go to the future with your future workplace.

I know, Richard, you called it, sometime back answering to Heather, one of the questions from our audience on similar lines, don't wait, start small. Is that the key message or takeaway you have, or is there anything else that you want our audience to take back and apply?

Yeah, definitely start small. So self-bias here is partner with your security company or security department. See why they don't sleep at night because of secrets. But I think this is also a good opportunity. If your organization hasn't partnered with security, this is a great way to bridge that partnership between both departments.

And we're all trying to do the right thing. It's just how do we get there, and what way can we make it easier for each other? And if you work it collaboratively, you could do wonderful things. I'm pretty sure of it.

This is really great. And just to summarize, I think keep your awareness, learn, keep learning about the trends and the best practices, and partner with your security and compliance team to make sure that you don't do things in isolation and bear the burden afterwards at a later point of time. And I think start small, and start now.