Bart Farrell: First things first, who are you? What's your role? And where do you work?
Ashwath Kumar: Hi, my name is Ashwath. I work as the head of security at Razorpay. I've been with the company about five and a half years. I'm based out of Bangalore, India.
Bart Farrell: You've made the point that isolation should be a property of the infrastructure, not something you trust application code to get right. In a financial services environment, where should that security boundary actually sit? Namespace, node, cluster, network, cloud account: How does authorization move it outward?
Ashwath Kumar: Very interesting question. Two answers. The first answer is, as we speak, there's a huge influx of AI and AI is writing a lot of source code. With that, the number of applications, the amount of code running in the environment is going to drastically increase. With that, we need to go back to point number two, which is defense in depth. We need to have multiple layers of security. It's more like a layered security approach. One is at the cloud account level, we need to have a base level of shift left security controls like service control policies and so on. And at the next step, when it comes to the cluster itself, we need to have the cluster configuration be super solid. That should be taken care of. And the next piece is, there should be a lot of rigor when it comes to the namespace. The cluster, namespace, and the node should have some base set of controls or a base set of rules. Then when it comes down to the actual container, there have to be a few runtime controls that have to be added. And also the base configuration checks should be more of policy as code. That way, even if a change has to happen, or something bad were to happen, there are multiple checks at multiple layers, and the damage is minimal.
Bart Farrell: When you run a Kubernetes platform, which controls tend to look reassuring on an architecture diagram, but prove much weaker once you actually try to cross the boundary?
Ashwath Kumar: On an architecture diagram, when you put things out, things like the ingress and the egress network piece, it looks super interesting when you look at it, especially on the ingress piece where you might have a box, which is a web application firewall. It might look super interesting, but once you get inside a particular pod, that's when things start changing really quickly. And you need to have a good control over the roles and the kind of access that this particular container has. That's where a lot of policies are required and also network restrictions are required between what you would call the east-west traffic that is inter-cluster communication. So there's a good level of control that would be required at that particular piece. And also on the secrets that are present, right? By default it might look like I'm putting everything on the secret store might be super reassuring but who exactly has access on those secrets you know this is something that also has to be looked at i think these two pieces so one is the network moving around piece and the kind of roles and the access that are present and secrets i think these two would be like the main pieces where a lot more control and a lot more attention has to be paid though it might look good on paper. There's a lot of lateral movement that can happen. There's a lot of exfiltration that can happen because if these two pieces are not done.
Bart Farrell: For a workload with powerful credentials and access to sensitive systems, what would you need to continuously prove about identity, egress, and authorization before you'd call the platform genuinely audit-ready rather than simply configured securely?
Ashwath Kumar: Let's start with identity, right? Identity is the easier one. So here, the idea is to have what the cloud providers usually provide by default. You can go have a particular secret and kind of keep the secret, let's say in a key management store or a secret store. But the key piece is every container needs to have its own identity. And this particular secret needs to be typed with this particular identity, right? And it should not be like any container within this cluster should have access to this particular secret. So setting up those rules to say, hey, you know it is kind of restricted to this particular secret, that piece is super important. And I'll get to the RBAC piece right away. So once this is done, the reinforcing factor has to be the principle of least privilege. Compliance is one piece, but also securing the environment is another piece. So let's say if a secret has to be read by three containers and only one container is going to go update the secret, that particular piece has to be keyed into secret piece. The whole concept of principle of least privilege has to be enforced. On egress, the one piece that kind of works well is the policies, but the policies are very difficult to manage. So as and when applications are getting deployed, it's super difficult to go keep up with the egress because you don't want to be the bottleneck or security people don't want to be the bottleneck when something has to go public, when a particular service has to go public. So this is where we looked at an open source solution called CrapTrap. So what this did was, there was a whitelist which said, hey, now here are the list of websites that are always allowed. So for example, deployments happen from ECR. So ECR is always allowed. And here are five of the internal services which are always allowed. But here are a list of services that are not allowed. So for example, a production cluster does not have to reach out to Discord or Slack or so on. So these are the list of services that are not blacklisted. There's a whitelist there's a blacklist Anything that does not check the whitelist or a blacklist goes through an LLM where there's a prompt that says, hey, you know, if this particular, so this is the thought process behind this service. And if it does not match here of the five criteria, if it does match these five criteria, then go ahead and allow it. If it does not match these five criteria, then you can go ahead and reject it, right? So that kind of allows innovation and speed along with security. I think that's kind of a good piece to kind of solve and achieve and on a similar concept is also the identity piece because if we keep the identity and the secret at the container itself then there is a possibility that in an agentic workload the agent could go grab the secret and you know then ship it out to a third party whereas the whole concept of keeping the secret also at the egress layer is something that you know we were thinking about which could be like an interesting solve right if you keep it out there then the agent does not see the secret and only when the secret is getting shipped to let's say a secrets manager or let's say a particular let's say send grid right so before it's getting shipped to send grid that's where it would go decrypt the secret and you know add the secret there only for send grid whereas for any other service it would not pull the actual secret only the token would go out right so That could be like another innovative thing that could come in.
Bart Farrell: Excellent. Thank you so much for sharing your time, knowledge, and experience with us today. Look forward to speaking to you in the future. Take care.
