But a 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 organisation’s scalability demands, basic principles like security and data protection mustn't 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 their objective stays the same: how can we reduce risk, minimise 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 make sure it survives long-term. This is exactly the case with Kubernetes. By the time Kubernetes is at the virtualisation 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 it’s the unique technical requirements that can present challenges.
Security in Kubernetes & zero-trust
As a cloud-native programme, 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 authorise, it also gives developers bespoke configuration options, meaning it is only really as secure as the RBAC (Role-based access control) 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 constantly maintains strict security procedures around every user, device and connection. For the fluid and decentralised architecture of Kubernetes, this is a must.
Backup and recovery
Another basic principle that is needed to mitigate risks for Kubernetes applications is backup and recovery. This is a well-known concept but there are lots of unique considerations when backing up Kubernetes and containers. These different requirements for data backup are 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 application programming interfaces (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.
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 optimise costs.
Preparing for change
Despite Kubernetes presenting new technical challenges, ultimately the more things change the more they stay the same. Operations and infrastructure teams are well-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 optimisation. Through a robust backup that supports app mobility, teams can also go a long way to future-proofing applications by ensuring 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.
.jpg)
.jpg)
.jpg)