Bart Farrell: Welcome to KubeFM, Jim. For people who don't know you, who are you, what's your role, and where do you work?
Jim Bugwadia: I'm Jim Bugwadia, co-founder, CEO at Nirmata, and also a maintainer of Kyverno, which is an open-source policy engine for Kubernetes.
Bart Farrell: Now, in a regulated environment, how do you design policy as code so that developers still have autonomy, but security teams can prove that critical controls were enforced consistently across every cluster and deployment path?
Jim Bugwadia: Three things we typically recommend. The first is you need multiple policy control points or policy enforcement points. Typically, you start with enforcing policies in your pipelines themselves, where developers first interface with the deployment pipelines, GitOps or with CI/CD. The second is you would want to do open reporting in flexible ways where developers get access to the results of the policy itself. And finally, the third and perhaps one of the most critical things is to have proper exception management, which is also in systems that developers can interact with, as well as use across the board.
Bart Farrell: Policy exceptions are inevitable in a bank. What does a good exception model look like without turning temporary waivers into permanent holes in your controls?
Jim Bugwadia: First off, exceptions need to be only used in exceptional situations. It has to be business justified. There has to be some risk-based association as to why that exception is required. And secondly, what we do with Kyverno is exceptions are time-bound by default. Having an exception which is perpetual defeats the purpose. It's no longer an exception. It becomes a standard. And the last thing I would add to that is there always need to be compensating controls. Whenever an exception is granted, you don't want to just blindly bypass policies. You want to be able to have other controls in place, which describe exactly how you are compensating for that lack of policy or that lack of security in that case.
Bart Farrell: Now, for bank-grade Kubernetes, how important is it to treat the policy layer itself as critical infrastructure, protecting it from tampering, tracking changes through GitOps, and being able to prove who changed what and why?
Jim Bugwadia: Extremely. The first thing is, just like any other critical component, your policy engine needs to be hardened, needs to be CVE-free. And Kyverno, being an open-source project, which is used in so many different environments, has a lot of different configuration options. You need to know how to configure this well by default. And through Nirmata, we also provide a hardened version with that security built in and with zero CVEs and with not just the base images, but also the application source code, which we patch and maintain over time across different versions of Kubernetes, as well as Kubernetes.
Bart Farrell: And just as a bit of a bonus question, nowadays, speaking to other financial institutions, one of the things that they're struggling with is the aspect of digital sovereignty. And if they're working with third-party providers, to what extent can they maintain that sovereignty? Is there anything that's come across your radar related to this topic or things organizations should keep in mind if they're going to be working in highly regulated environments?
Jim Bugwadia: Yes, and it is important to have that flexibility. And just as a vendor working with a lot of regulated environments too, we've designed our architecture and the different components we offer in a manner where that's completely possible. Everything we do, we're very focused on the Kubernetes ecosystem. Even commercial components run completely air-gapped. Thank you. Kubernetes as required, which is the standard form of deployment in these regulated environments.
Bart Farrell: Excellent. Jim, thanks so much for sharing your knowledge with us. Always a pleasure. Look forward to speaking to you in the future. Take care.
Jim Bugwadia: Thank you, Bart.
