Security is a subject across domains. So, there must be a balance between pushing some risks and responsibilities back to the technology team and some to the incident responder. But the action taken is an internal decision that you need to discuss, says Jimmy Mesta, co-founder and CTO of KSOC, in his conversation with ITSecurityWire.
- How does Kubernetes help fight emerging threats, especially due to the fast innovations that are happening today, given the advent of AI and many other tools that organizations have? The threats and the risks have also gone up. So, how does this particular product that you work with help companies keep themselves safe?
JM: There are two sides to that question. Because if you give a high-level overview, Kubernetes is a container orchestrator. We like to describe it as a data center inside your data center. So, we can likely have one or more Kubernetes clusters with an overarching public cloud like AWS.
That is where the workloads, configuration, secrets management, network controls, and access controls live. So Kubernetes itself isn’t secure or insecure. It’s just what you make of it as you build your infrastructure. From a security standpoint, the Kubernetes project has much to offer out of the box, but it’s up to you to ensure every flag is turned on.
The containers are configured in a way that allows the least privileged access. And we have a lot of batteries included in the options to make Kubernetes secure. But the reality is that it’s not working out that way.
The last two years have seen exponential growth in the number of clusters and nodes and critical workloads running in this environment. It is, however, mixed with maybe less domain expertise than we need on the security side. That and its complexity make for a recipe for disaster, as we keep scaling something out that doesn’t have the repeatable security patterns we’ve had in the past.
So Kubernetes can be used in a very isolated, secure, observed way, but that’s just not what we’re seeing today, given the state of the industry and how fast this project’s moving.
- So then, how do you make sure that it is helping organizations?
JM: Step one is at the ground level, and you need to do some in-house education if you have a security team. If you’re doing threat modeling with your infrastructure, ops teams, and DevOps teams to understand the plan for getting code, the developers are writing through the pipeline and then into a runtime state.
There is often a lot of complexity, and building guardrails is essential. So, you must get a lay of the land from day one. From a security perspective, asset inventory is hard. We don’t have it figured out yet. We don’t always know where our endpoints are, let alone individual containers, nodes, clusters, and all the components that build Kubernetes. So, figuring out where your clusters are and who has access to them is critical.
At KSOC, we take a very identity-centric approach. That’s very important because humans access Kubernetes and their service accounts. They also can talk to Kubernetes. That’s dangerous.
We want to ensure we are always doing an inventory of the cluster and identity components. We keep you updated on where your logs are headed and if there is a logging setup. We track if you are doing anything with those logs and how your container or workload configurations are configured.
Are developers able to deploy workloads that are completely unprotected? Are privileged accounts running as root, and they have no networking controls? Do you have third-party components running in the cluster? That could be risky since the supply chain is still inside of Kubernetes. So all of those things come to building an actual top-down.
So, we have a specific roadmap for Kubernetes security, and we are taking this pretty seriously because we’ve decided collectively to run our most critical kind of business-centric workloads in this environment. So, it needs to be treated as such.
- So how can businesses secure their identity access management? What is the best way to do it, especially under the current circumstances?
JM: We work with CISOs daily for identity access since it’s top of mind. It’s one of the top three concerns, and for good reason. Now that everybody is accessing everything from all over the planet, Kubernetes included, identity becomes even more important.
So, when you think about identity and access management or entitlements in general, you usually have a single sign-on or identity provider. That will onboard a new user who just started the company. They will get access to some SaaS applications and maybe some infrastructure. Your identity provider isn’t. That’s just going to be the gate to the door, right?
When it comes to cloud infrastructure, it’s not going to give you everything you need to understand what a person or a service account is doing in the depths of Kubernetes, specifically or even in your cloud. So, the first step at the ground level is taking an inventory of identities.
So, when analyzing your cloud IAM, whether it’s AWS, Azure, or GCP, there are a lot of RBAC components inside that kind of bind users and give them access to things in the cluster.
Kubernetes doesn’t deal with users as much. So basic 101 would be running an inventory, which is not enough, but it’s a start.
Secondary to that would be some important questions- what are these identities doing? Do they have the proper entitlement management? Are they generating anomalies? Are people logging into things that they shouldn’t be? Are there excessive denials? Are there suspicious logins? And then correlating that with the entitlement pieces maybe even more important. That’s because getting a credential and logging in is usually simple.
But for Cloud IAM, that isn’t very easy. You need to have some tooling in place and start ingesting logs, connecting them with the actual identities to see if they are at the right level of privilege or entitlement the account should have.
That flows back into Kubernetes as well. So, even though compliance rules may be happy with a quarterly assessment, this has to be ongoing, continuous, and real-time.
Continuously, you should reassess that level of access. This way, you are building detections, and then the detection engineering team can be involved to watch for abnormal behavior.
There are anomalies in log-ins, so the SOC or the detection engineering team will maintain and respond when it comes to identity management. It is a kind of zone defense approach or the classic security onion. You have to do all of it and continuously and consistently.
Also Read: Dangerous Cyber Security Incidents Forecasted in 2023
- What challenges do business leaders face in integrating Kubernetes into their security posture, and how can businesses overcome those bottlenecks? How would Kubernetes help to strengthen the security posture, if at all? So that’s an opinion we want to know from you, doesn’t it? And if it does, then how?
JM: The challenge that business leaders in a large enterprises face today is treating Kubernetes like we treat the rest of our cloud infrastructure. I’ve been saying this for a long time: the tide is shifting, and we cannot treat a Kubernetes cluster as a line item in the regular old scanning program you used ten years ago. This is because, within that Kubernetes cluster, they could have a whole separate world. You have massive risk there, and you simplify it too much.
So, I think business leaders need to understand that Kubernetes is not a line item. It’s an enterprise piece of infrastructure.
We are not a side project. This real enterprise piece of kit needs to be top of mind for CISOs because it will come back to cause problems. And when it does cause problems, whatever it may be, you need to be clear on how your Kubernetes environment exists. That’s the biggest point.
The other challenge there is who owns it. We see this all the time. There is a question mark: is it the security engineering, compliance, or platform teams? That is problematic because if nobody owns it, nobody owns up to Kubernetes security. Then, nothing gets done. And then it’s the same story repeatedly where we see over-permissive users and service accounts and a severe lack of visibility into a high criticality level of access.
Some of these clusters have crown jewels running inside of them. They can access other parts of your cloud, which is a good jump-off point for an attacker. So, we need to tighten up the identity and authorization components. But then, where do I do it?
There’s a whole shift left that we have been talking about for the last five years. So we’re not doing anything at runtime, and then there’s something in the middle of Kubernetes called mission control. You have to do all of it these days; it’s a big part of the process to catch things early, but there is a runtime component that cannot be replaced.
So, I think that there will need to be a balance between pushing some of this back to the developer and then some to the incident responder. But the action taken is an internal decision that you need to discuss.
To read on, please see the part 2 of this series: Security Needs to be Joint Leadership Responsibility
For more such updates follow us on Google News ITsecuritywire News. Please subscribe to our Newsletter for more updates.
