 Hey everyone, thanks for the opportunity to present to you today a very important topic really fast. There's a lightning talk 10 minutes We want to go hit the key points and then get right on to things So my name is Andrew Block. I'm a distinguished architect with red hats My co-predecessor couldn't be here shubik bose He is obviously very much, you know in spirit as they say with us here in the room as well as virtually So any questions that you have in virtually, please go ahead and put it into the questionnaire chat So that you know, he might be able to answer to so a very important topic in get ops is security Why is security important? because traditional models of get ops or just traditional models of managing infrastructure is typically managed via people and For that standpoint you want to you typically focus on physical security You want to keep people out of buildings out of systems when you move over towards a get ops model you have to shift your thinking to where it's more autonomous and Changes just occur through the systems and there's a lot of things that you need to think about that you might not have thought about before Everything from and we're going to talk about those All these different principles everything from physical security to Securing your get ops engine to repository security things that you just had not thought about before You now need to think about it. So first of all, we're not talking about anything new These principles around security are things that you probably should be taking advantage of automatically in your current day Whether you're using get ops or not everything from Understanding where source the source of truth for your content making sure if you're using a get ops engine You know that's in the container making sure you're getting container images from certified locations You're going ahead and scanning for vulnerabilities inside these containers You want to make sure that you enforce regulatory compliance You also want to be able to monitor your systems So that things don't go bump on the night things that you should have already been doing We want to make sure we continue to do them in a get ops world First let's go ahead and let's start with we want to secure the get ops engine This is going to be an Argo CD a flux if you're not even using containers and Kubernetes You can have an automation tool like Ansible or Terraform We want to make sure that you secure your get ops engine You want to make sure that you have proper authentication and authorization on them So only certain individuals can access your get ops engine You want to make sure that you regulate the source of content Where is your source of content for your get repositories? Are you you're pulling from just some random repository on GitHub or are you going from a certified source? You also want to make sure that if you have multi-tenants in your get ops environment So in a Kubernetes environment it's multi-tenant by default You can have multiple get ops engines in a single cluster Making sure that you limit the amount of access that you give your get ops engine Or if you happen to be leveraging a single get ops engine You can have multiple teams inside that get ops engine Ensuring that they are going ahead and limiting the types of access that each one is given That's securing the get ops engine Next is with get ops you're going to typically go ahead and leverage a repository of some sort A get ops repository that's on a server It could be hosted on a public fast solution like GitHub, GitLab But you most likely in an enterprise organization is going to be leveraging one that's internal You want to go ahead and embrace common best practices for managing infrastructure You want to make sure it's highly available You want to make sure it's monitoring and alerting So if things will bump in the night you won't go ahead and be surprised about it And very important make backups really regularly Access control making sure that nobody has access to the infrastructure that shouldn't And if you are leveraging Git make sure to only enable the protocols you're going to leverage If you're going to use HTTP you're going to use SSH Disable the ones you aren't going to use because they could involve some backdoors or some vulnerabilities Next we'll go into securing the get ops repository Making sure that only certain individuals have access to your get ops repository So if you have a CI CD system you won't make sure that you have separate access controls for that system Or your get ops tools or any individual You want to make sure you limit the amount of access that is given to those tools And then inside the repository itself enforcing branch protection Since your Git is your source of truth for your entire infrastructure You don't want to have some individual accidentally pushed to master When they want to protect, we go to a non-prod environment Because that could then get rolled out and infect your entire system You want to utilize a typical contribution workflow like the fork and pull model from GitHub Or something along those lines And then finally perform content verification of anything you are introducing into your environment We're going to talk about that in a future slide Restrict the get ops engine, restrict exactly what the tool can do In a Kubernetes environment if you're going ahead and just managing certain components in a certain namespace Don't give an entire cluster admin access Because someone could accidentally push changes that affect the entire cluster Make sure you lock things down, utilize a non-user account, a dedicated service account For your get ops engine As well as I mentioned, employ the policy of least principle Pardon me about that Ensuring that only it has access to what it needs to do And make sure that you are able to audit the amount of permissions that you are given to your get ops engine Finally, secure your get ops content The content is the brains behind your entire operations If you give it bad configuration, it's going to spit out bad configuration So if you in a Kubernetes environment give it bad YAML Well, if you had good YAML when you first started and you gave it bad YAML That's going to be downtime potentially Depending on how you have your rolling updates, etc. in the Kubernetes environment But make sure you enforce good content in your get ops environment So utilize code-linting schema validation So in Kubernetes, you can validate different schemas So if your deployment has a field that it doesn't recognize, it will fail validation Integrate these type of processes into your typical get ops workflow, your CI CD process As well as leveraging policy enforcement engines like OPA, Kyverno You can go ahead and enforce state and compliance before you even get anywhere near to emerging to master Or your target branch for your individual deployment And finally, the last thing, which is a bane of everyone's distances How the heck am I going to manage my secrets? Every environment is going to have sensitive data How do I manage that in a get ops world? Well, number one, never store ever store secrets in plain text Plain and simple We're not plain and simple Number two, Kubernetes secrets themselves are not encrypted If you didn't know that, that's a big, big thing It's base64 encoded anyone with any tool on their laptop We'll probably be able to go ahead and decode that Utilize an encryption strategy if you're going to store content inside your repository Or just don't even store it inside Use a secrets management tool like a hashtag or vault A cyber arc, you know, cyber arc, et cetera Or, you know, AWS or Azure depending on what cloud provider you're using Utilize secret storage is there and then reference that inside your applications Certain plugins are available to help with your get ops tool Like Rgo CD can integrate with Vault And Flux has similar tools as well And then, once again, utilize code scanning tools To be able to be detected and notified If it detects any type of content that might be a password Or anything around those lines And finally, the last thing is security is always continuous What may be good today isn't going to be good tomorrow Make sure you go ahead and design appropriately Implement it when you are beginning Always start with security first Don't go ahead and bolt it on after the covers Because at that point, you're already too late in your process You're going to have to go ahead and rework a lot of things Make sure you enforce it and then monitor and then adapt accordingly Be able to refer to it, adapt and be very agile These are a lot of different things and a lot of different topics That I went through in this quick lightning talk I hope that I was able to provide some thoughts, some insights And how you can enforce proper security inside your get ops workflow I will be around the entire conference Feel free to go ahead and come up to me Also, for those of you in the virtual audience Feel free to hit me up on my social media accounts You know, Twitter, Facebook, LinkedIn Happy to go ahead and have a conversation there Thank you for the time today Thank you