 כן, אוקיי. היי, everyone, thank you for coming. My name is Dov Hershkovitz. I'm a senior product manager at GitLab. This talk was mainly inspired by many conversations that I had with our customers and users, also some of the best practices that we've been implementing in GitLab. And hopefully by the end of this conversation, you'll better know how to secure your DevOps process using OpenStandard today without waiting for anyone to build any integration for you. Basically use the tools that you have today. So let's just start, but before we'll get going, a quick definition of what is a secret. A secret is an object that enables the process of accessing restricted data or a resource, meaning that the data itself or the environment that you want to access is not a secret, the data is protected, but the way to access the data, the key, is the actual secret. Now we all know that software is all about speed. Any software organization wants to develop and deliver features to our customers as quickly as possible. We want to react quickly, we want to close vulnerability holes and fix bugs as fast as we can. This is why DevOps becomes such a wide practice in our industry. It was widely adopted because it allows us to automate basically everything and speed up our process. But we also know that our pipelines and our software need to be secure. And sometimes it feels that security and the security priorities will reduce our cycle time and will not speed up our processes. And this is because security is more gate-driven, it's heavy on process, and let's be honest with ourselves, there is a lot of lack of knowledge around security because we don't know where the next vulnerability will come from, so we don't know which holes we need to close first, and there are always holes that we need to close. This is why DevSecOps as a concept had emerged, basically putting security at the heart of DevOps without compromising. Let's not compromise, let's optimize. Let's optimize speed, let's optimize security. Eventually what we'll gain is speedy and secure pipeline. So in order to achieve that, first of all, we need to understand that secrets need to live in a dedicated secret solution. This is why there are so many secret solutions out there. All the cloud providers have different secret management solutions and key management systems to store and handle secrets. And also there are the dedicated secret management solutions that you all know, like HashiCoVolt, Conju, Akiles, and more. There are a lot of tools in the market and a lot of solutions to choose from. But as we mentioned, we want to make sure that we are integrating this with our DevOps platform, meaning our CI-CD pipeline, because we want to pull those secrets and use that as a part of our processes to allow us to manage our infrastructure or deploy our application in a secure manner. And now we are facing with another dilemma. Which tool should we choose from? Should we simply choose our secret management solution based on the available integration? Doesn't make sense, we want to use the best of breed. What if my organization is using a tool that simply does not support my DevOps platform and cannot integrate me with my CI-CD pipeline? Or if I have a multi-cloud strategy and I want to integrate with all the different cloud providers? What should we do? What should you do? Well, if there is a native integration, if one of the vendors builds a native integration for you, then great, you can simply use it. But as a product manager in GitLab, as much as I would love to integrate with all the secret management solutions that are out there, I simply can't. So there is something that we can do until someone will build that integration for you. And to do that, we need to familiarize ourselves with two concepts, OpenID and the JWT. Now the OpenID is an open standard for decentralized authentication. The JWT is a token, one of the ways to implement OpenID Connect. It's a short lived ID token. And the good news is that all the cloud providers or the secret management solution and many of the DevOps platform support the OpenID with the JWT implementation. In fact, I still haven't seen the tool that does not support that. I think it's practically a standard today. The fact that it is a standard. So if we have that in our disposal, what can we do? The solution will be in the form of integrating our OpenID with our DevOps platform. So in order to do that, we need to do the following step, or you need to do the following steps. And it's practically the same, and it doesn't matter which tool you are choosing, but the steps are more or less the same. Number one, you need to configure trust relationship with OpenID collecting in a declarative manner. You need to tell your cloud providers or your secret management solution any service provider I want to authenticate using an OpenID Connect with a JWT token. And then any DevOps platform, or if it's Github, Github, CircleCI, all of them are capable of generating a JWT token and send it to your provider. Then it gets authenticated. And if it's get authenticated, you'll get an access token back. Once you get that access token back, you can go ahead and retrieve any secret that you like in order to implement it as a part of your CI-CD pipeline, as I mentioned, to manage your infrastructure or deploy your application. And that's it. This is how you set up an integration between any DevOps platform to any secret providers. Now, like anything in our industry, any solution in our industry, there are pros and cons for both. So let's work them quickly. The benefit of using the JWT in DevOps workflow is, first of all, it's way more secure because you're using a short-lived ID token. Even if the token gets leaked, it has an expiration time of five minutes, so there is probably not a lot of things that an attacker can do in a course of five minutes. You have no vendor look. You don't need to wait for anyone to build an integration for you. You can go and build that integration right now. And also, secret are stored and secure in a dedicated system. You gain all the features and all the benefit that the secret provider brings in. The downside of using the JWT in DevOps workflow is, first of all, you need to know how to configure OpenID Connect. And also, the setup or the configuration in your CI pipeline, also a little bit complex. I thought this is something that you need to do one time and then the entire organization can use. Still, someone needs to do it for you. Even in GitLab, we have, like, a handful of engineers that really know how to do it. And the rest of the engineers are simply using it. And also, there is an associate cost with storing secrets in cloud providers or any secret management solution. Lastly, if there is one slide that I want you to remember from this lighting talk, is this one basically recapping the entire presentation. The challenge, the way I see it, that secret are typically stored in a dedicated management solution. But we know that secrets need to integrate with our DevOps platform, meaning our CI-CD pipeline. The solution, in case you don't have a built-in integration, go ahead and configure OpenID Connect on your provider and set up your pipeline to use JWT to retrieve those secrets. And the result, the secrets are securely stored and integrated with your existing DevOps tools. Now, in this lighting talk, I don't have the time to go into the depth of how to build that integration, but I've created one slide with a lot of working examples that you can simply use. And it's very easy. I mean, all you need to do is go to your documentation and just look for OpenID Connect or OIDC and you'll immediately see it. With that, I want to thank you and hopefully you enjoyed this talk. Bye-bye.