 My name is Karen Elder. I'm from CyberArch Software and today I'm going to talk to you about a problem that I'm sure anyone who runs OpenShift or any other tool in your IT environment have bumped into which is secret management. And how do you trust your containerized applications when they run within OpenShift or Kubernetes and how do you free on the other hand your developers from the headache of dealing with secret management? So I'm sure a lot of you have heard about many initiatives in the last few days of digital transformation and with the move to the new cloud native environments obviously we have much more infrastructure applications, much more automation running in your IT environment whether it's in the cloud or on-premise or in hybrid environments. If in the past we were much looking and security looked mainly on human users that need to access different resources and looking after what users can do, monitor them, take care of access control. In today's environment where there is much more operation the new privilege is actually code. Many tools are doing what people used to do in the past and now automation is taking care of that and we should be looking to see how are we securing that, how do we put a solution in place that will allow us to control and understand what all these tools and automations and applications that are running in our environment can access or can do. And why is that so important? So with all of those users and code that in tools that are running in our environment there are much more secrets and keys and tokens and passwords that are scattered all around. Just try to count in your organization how many for each tool or each user that is working in the environment how many different systems or resources or cloud services it can access. For each of these they need to have a certain secret, a certain key that will allow them that access. Now tie all of that together that's a huge risk to your organization and anything left open like that basically leaves a door to an attacker to come and gain control in your environment. So I like calling all those new tools the new domain controller or the new ID administrators because basically that's what they do now and if now a DevOps person is now controlling your Ansible or your OpenShift basically this has become a human controller to your risk. If an attacker gains control on your Ansible or your OpenShift they can easily get access to almost your entire environment and we don't want to make sure that we can help you protect that. So some of you may ask or say but I am using Ansible Vault or I'm using the Kubernetes secret solution isn't that good enough. So that may be a good local initiative but when you look at it from an enterprise perspective a large enterprise that needs to manage and control and secure a very large environment on premise or in the cloud we don't want you to have those security islands and why is that a security island. First you can't really share secrets or credentials between such local tools and second from a security perspective these are solutions that were not built really with security in mind with all the capabilities that are needed for secret management. Things like central audit or rotation of credentials and secrets they do not provide that. So we want to really provide you an enterprise wide solution that can be deployed and applied to our environment whether you're running today on premise tomorrow on AWS and maybe next year in Google Cloud or in Azure. Okay we want to be we don't want to be locked to a certain environment. So cyber arc is really positioned in a unique place to do that as the undisputed leader in privileged account security and with more than 3,500 actually it's today 3,800 customers globally all around the world and more than 50% of the Fortune 100. We've been dealing for almost 20 years with challenges related to privilege access, secret management, applications and humans and in the last couple of years what we have been doing is helping our enterprise customers, larger enterprise customers all around the world to go through that digital transformation journey and to be able to think ahead you know how do you design your environment, your applications, your tools that are going to run in those new environments from the beginning to work in a secure manner. If everything is all about automation let's put that into let's automate security as well and let's put that into our pipeline and build it correct from the first place and not to just increase our technical depth. Now the good news is that probably all of you are somewhere in this journey so that's a great opportunity to deal with that. Okay now you can decide how you want to deploy and apply good security methodologies into your environment and we'll see an example for OpenShift today. So first we have CyberArchondra which is our secret management solution for the cloud and DevOps environment. CyberArchondra was really designed and built from day one to address those challenges of cloud elastic dynamic ephemeral environments and also integrating into all of those tools and platforms. On the one hand it's supposed to address the need of the security teams that need to have the controls in place but do not necessarily know you know all the technologies and new tools very well. On the other hand we provide native tools to developers we really want to remove the headache of secret management to developers. We want to deliver a very seamless solution to them that they will simply focus on writing code we will take care of securing all your secrets and also auditors can benefit from it because they will get like a central audit for and proof for everything that is happening in your environment and this is mainly relevant to highly regulated organizations the audit piece. So what have we done with OpenShift that's what I'm going to focus today we have integrations with many tools and environment today we'll talk about OpenShift and how we can deliver secrets into applications running within your OpenShift environment in a highly secure manner and on the other hand really as I mentioned free the developers from dealing with that. So the integration goals were really around security and how do we securely authenticate each container each application that is running we don't want to replace your outcoded credentials with a password to our solution because basically that will not solve the problem that's shifting it from one place to the other we want to solve that bootstrap problem want to solve that secret zero problem so what people call it in different names and still provide central audit provides segregation of duty so which application can access only the secrets that is supposed to access and not other things we believe in least privilege model and of course also secret rotation so once in a while based on a policy you want to be able to rotate those secrets so even if someone has put his hand on any of those secrets after a while it will not be relevant anymore okay so before we go into the demo of how this integration works so you can run conjure within your OpenShift environment we have a master with high availability called and hot standbys you can choose to run them outside or inside the OpenShift environment based on how many environments it serves but we also have this unique component that is called follower the follower is an active replica of our master so it includes all the secret and it sits close to your application so for example you can put one or more followers in the same cluster of your application and that means your application will get secrets in a very high performance in a scalable way it will be close to it and even if for some reason the connection to the master is lost it will still continue to serve your application so that's a very robust and scalable architecture and highly available architects that we provide there we realize that secrets if they they are not delivered to your application basically it would stop working so that's a critical piece we understand we're a critical component in that whole process and so let's see a short demo of how this works we'll get back to that diagram so first we'll see within the OpenShift environment as I mentioned we have the master running and the two followers they're already deployed in this environment and the first thing that we will do is define the conjure policy and so the policy as I mentioned we're trying we want to provide developers the tools that are native for them that will not hurt the velocity and we'll remove that headache so you can see the policy is a yamal file so you can write it with your application check it into your code repository and basically it's a declarative policy and what we do here at the beginning we define an application and that needs to access a certain database so it needs the secrets to that database so we just give permission to that application to access the database we'll also run it in two pods in our OpenShift environment so we define those pods as hosts and we provide access to our application and we say it will run in those pods okay the first thing we do we load this policy into conjure we will now go to the conjure UI I mentioned it can serve admin security we see all the policies that we have we'll enter this policy that we just loaded we see all the entities the permissions who can access what and all the related audit to that policy so everything that is related to this policy is available here everything is also available via REST API of course so we can also see the secret that we loaded and its value we'll see it later from our application this is the secret now we'll go back to our OpenShift environment we didn't run our application yet so there are no pods that are running when we will now run our application it's a very simple and dummy application just for the demo it basically you ask it to retrieve secrets and it will show it to the screen not recommended for a production environment so we're deploying our application we'll have two pods that are running this the same code so we'll see now we'll list the pods that are running in the environment so we have two pods that were deployed with different names and we can see now in OpenShift that these pods are actually running in our policy at the beginning we defined those pods with application name now we call our stupid command of retrieving passwords to the screen we see the secret that we saw before and now we'll go change the secret value so we will believe me that it really gets the right password from conjure if we retrieve the pen they ask it to retrieve the passwords again then we see we have the new password here with the AAA that we just added so what happened here let's go back for a second to our diagram so we have these two pods running the application okay these application need to get access to secret the secrets are stored in conjure we want to make sure that if we're delivering the secrets to those application we actually authenticate them these are really the applications that they're saying they are and they are authorized to get those secrets so what we do here our solution comes with this code that you run in a sidecar container okay this sidecar container before your application starts will basically ask and will authenticate itself against several conjure based on its characteristics that we also defined in our policy like the name or the namespace the name of the pod the namespace or and there are other attributes that are supported we will authenticate and check that this pod is really the one that is allowed to that is really the one that it's saying it is and that it's allowed to access the secret that it asking I may have several applications and each of them will be able to access different secrets it doesn't mean if I run in the same cluster I must be able to run a tool to access all those secrets so we have that segregation of duty what's also nice about it that we have this tool someone it's an open source tool that will deliver the secret to my application container so if today you have applications that already consume secrets from an environment variable or from a file you don't need to change anything in your code you can simply deploy the solution and it will deliver the secret to your application so remember we mentioned we want to free developers from dealing with secrets that's the way you can just configure it deploy it and that's it your applications don't need to change a single line of code and they can consume the secrets from a secured repository with the audit with the segregation of duty with the access control and of course with the ability to also rotate secrets that cyber has a lot of experience with and is capable of changing and rotating hundreds of types of secrets that are out there for different systems so let's go back to our demo now I want to add a third pod sorry the last part that I had I'll skip it basically I wanted to show you like if I run my application in a third pod that I didn't define in my policy at the beginning where we defined a policy with which applications are allowed to get secrets if I run my application now in a third pod that was not defined which is unauthorized we could have seen that it's basically fails and will not be able to get the the secret so only really the authenticated and predefined applications can access them okay so I haven't mentioned that cyber are conjure has an open source version that you can start with the or in like a local initiative and you can go to conjure dot double double double conjure dot org you can download it there's also like a tutorial that will take you through the initial step you can try it out and of course there's also a supported enterprise version that also includes all the high availability and and capabilities when you really want to operationalize it and go wide to your enterprise it also integrates with a cyber are privileged account security a solution which was again a leading solution in the market for privileged account security so if you're already a cyber our customer and many of our customers are here you can basically leverage your existing investment and still manage all your secrets within the cyber vault and get it directly to your open shift containers and many other tools whether it's Ansible Jenkins or whatever it is so first thank you very much for your time and for my attending my session I'll be happy to answer any questions if you have after we finish here I think we're just at the time to wrap it up thank you