Basic Principles Key to Securing Kubernetes’ Future
As organizations increasingly adopt a cloud native approach to develop and scale up applications, containers and Kubernetes are playing a critical role in managing growing complexities and enabling workloads to be deployed in multicloud environments.
But a recent survey of DevOps professionals found that 94% had experienced at least one Kubernetes security incident in the past year, and 59% consider security to be their biggest concern when it comes to using Kubernetes and containers. While more and more DevOps teams turn to Kubernetes to keep up with their organization’s scalability demands, basic principles like security and data protection must not be overlooked.
Deploying Kubernetes
Developers are being asked to build bigger and more scalable applications across more dynamic environments. So for the operations or infrastructure team, it can seem like a full-time job keeping up with changing software development practices. Kubernetes is just the latest (and arguably more complex) challenge, but the objective stays the same: How can we reduce risk, minimize costs and provide an overall better business outcome?
Development teams are the “pioneers” — they explore new ground and build something where nothing existed before. Operations and infrastructure teams, on the other hand, are the “settlers” — coming in a second wave to consolidate new developments and to make sure it survives long term. This is exactly the case with Kubernetes. By the time Kubernetes is at the virtualization or adoption stage, it’s normally up to the operations teams — the responsibility of the real business outcome lands with them.
But it’s a big ask to expect these teams to understand the intricacies of Kubernetes and containers. Even with new technology, basic principles need to be adhered to. Security, backup and recovery are all still needed, but the unique technical requirements can present challenges.
Security in Kubernetes and Zero Trust
As a cloud native program, many of the security challenges for Kubernetes come from the dispersed nature of cloud architecture. Different workloads can be running across several different locations, including multiple clouds as well as both off- and on-premises servers. Not only does this vastly increase the “threat scape,” where an attack or mistake can occur, but it can also mean visibility challenges, making monitoring containers and detecting issues more difficult.
While Kubernetes is designed to be secure, only responding to requests that it can authenticate and authorize, it also gives developers bespoke configuration options, meaning it is only as secure as the role-based access control (RBAC) policies that developers configure. Kubernetes also uses what’s known as a “flat network” that enables groups of containers (or pods) to communicate with other containers by default. This raises security concerns as, in theory, attackers who compromise a pod can access other resources in the same cluster.
Despite this complexity, the solution to mitigate this risk is fairly straightforward: a zero trust strategy. With such a large attack surface, a fairly open network design, and workloads sitting across different environments, a zero trust architecture, one that never trusts and always verifies, is crucial when building with Kubernetes.
The principle of zero trust architecture is to move the focus of security away from the perimeter of an application while applying those principles throughout. All internal requests are considered suspicious, and authentication is required from top to bottom. This strategy helps mitigate risk by assuming threats exist on the network at all times, and so strict security procedures are constantly maintained around every user, device and connection. For the fluid and decentralized architecture of Kubernetes, this is a must.
Backup and Recovery
Backup and recovery are a well-known concept, but there are unique considerations when backing up Kubernetes and containers because Kubernetes is fundamentally different from other architectures. For example, it doesn’t have mapping applications to servers or virtual machines.
Kubernetes backup systems also need to be application-centric rather than focused on infrastructure. This is due to DevOps philosophy and “shift left” principles, which essentially mean the developer has more control over infrastructure and deployments. Other unique requirements for Kubernetes backup are the application’s scale, protection gaps and ecosystem integration.
When recovering Kubernetes environments, a detailed execution plan is needed that identifies cluster dependencies, updates applications to reflect new storage components and translates the plan into relevant Kubernetes APIs. While backup does require a more bespoke Kubernetes native solution, such recovery processes remain critical to the long-term health of the business. Efficient restoration and disaster recovery are non-negotiable in today’s environment, with outages costing an estimated €1,459 per minute. (Roughly $1,440.51/minute)
Beyond this, however, backup has huge value in terms of testing and development purposes, and enabling application mobility. Application mobility refers to the ability to migrate an application to a different environment — across on premises, clouds, clusters or Kubernetes distributions. This is increasingly important as IT environments become more complex and businesses need to respond to new business requirements, adopt new technology platforms or optimize costs.
Preparing for Change
Despite Kubernetes’ new technical challenges, ultimately the more things change, the more they stay the same. Operations and infrastructure teams are accustomed to incorporating new tools into the ever-expanding tech stack, and core principles like risk mitigation via modern data protection still serve their purpose.
Once these capabilities have been established, Ops teams can begin to look further afield and explore leveraging the value of their data through activities like testing and optimization. Through a robust backup that supports app mobility, teams can also go a long way to future-proofing applications by ensuring that services can more easily ride the next wave of change. While Kubernetes is the current tool that is changing the dev landscape, it most certainly will not be the last.
