Kubernetes is fast becoming a cornerstone technology for organisational agility, development speed, and business growth. While it was quickly adopted by major technology companies like Spotify and IBM, its deployment is now widespread across a diverse range of organisations including Goldman Sachs, Nokia, Adidas, and the UK’s Home Office. As companies continue the drive to digital transformation and cloud adoption, Kubernetes will undoubtedly become increasingly popular as the default system for automating deployment, scaling, and management of containerized applications.
However, as with many rapidly adopted technologies, there is a point at which businesses will need to find a way to ensure security as these new platforms spread throughout their organisation. Ultimately, is it possible to combine rapid development, which allows teams to innovate and deploy, driving your business growth, with tight, consistent security across an expanding company?
What are the security considerations for Kubernetes deployment?
The complexity and flexibility of Kubernetes is its strength, but can often also be its weakness. You can scale up clusters as needed, and meet huge traffic needs almost instantly. However, there is a significant learning curve, and this makes it less accessible to people who don’t have the right skills to correctly set up Kubernetes and supporting development environments. This, combined with the manual nature of setup, could lead to security vulnerabilities.
There are four key areas to think about:
- A properly configured Cluster ensures all security policies and protocols, (guardrails) are being implemented, keeping the organisation safe. Mistakes made during the process can expose your network to cyber attacks. Automation should be considered when spinning up new clusters to ensure consistency of the security policies enrollment.
- Often organisations will be using cloud providers to scale their apps. These public cloud providers, typically Google, Amazon or Azure, help teams easily manage their containerized applications, costs, and capacity allowances. However, the amount of options when creating clusters adds to the complexity, while having to adjust the default settings to match your organisation’s security requirements.
- Role Based Access Control (RBAC) – organisations should follow the principle of “least privileged access” i.e. you should only have access to what you absolutely need. That approach minimises the risk of the entire company being exposed in case of a breach. Having access to the data that’s not required to perform daily tasks exposes an organisation to unnecessary risk, and should be avoided.
- Having consistent security policies rolled out across the organisation is the best way to ensure maximum protection. In reality, different projects will have different requirements, and exceptions will need to be made. Especially in an innovation driven environment, giving teams the freedom and flexibility to create clusters and environments that enable new ideas, rather than hold them back, is critical.
All of the above means that Kubernetes clusters currently require operations specialists to build, configure and manage them as well as ensuring they have the right security profiles that meet the right needs of the teams. Not only is this a time-consuming process, it is also high-risk as mistakes can lead to serious security or stability issues – especially if you consider the possibility of human error in this environment. This manual process is slow, but the pace of change in the world and in business is anything but slow. Teams need a better way to meet the needs of the organisation.
Why automation can reduce the burden on teams, without compromising security
Automation is a way of guaranteeing an end result in a repeatable and verifiable way. When it comes to security, that is key. Knowing that you have a known configuration outcome on what you are building, especially with something as complex as Kubernetes is essential. Using platforms that provide a way to guarantee a repeatable automation of Kubernetes for a team, makes it more commoditised and secure.
Essentially, it’s allowing the developer team to set up clusters with all the security configuration rolled in, so they don’t have to worry about how secure their applications are inside the infrastructure they are deployed to.
This means that developers can then get Kubernetes simply and easily, without relying on specialist resources to provision it for them, set it up and give them access credentials.
As with anything in life, there is never a one-size fits all approach when it comes to applications, some of which you may not get to control as you didn’t write them but have a business need for it. Setting out the right trackable policy and knowing what cluster(s) it is applied to for that specific exception helps manage and visualise risk easily. Also, commoditised Kubernetes may make it easier to put more risky services inside their own cluster to reduce the blast radius of a potential compromise.
When it comes to allowing teams to override non-contentious settings like the number of nodes in a cluster or the instance type they might want to use for specific application workloads, then baking in that flexibility with automation means that you can oversee what’s happening on your platform, without causing tensions between teams who feel they don’t have the freedom to innovate.
In organisations who have hundreds of users, keeping manual tabs on each person is time-consuming, mundane, prone to error and opposite of scalable. Automated cluster creation provisioning provides the right security profiles for that specific development team in minutes.
Secure innovation, or no innovation
Having a cloud-native strategy and leaning on products that automated repeatable but secure solutions is a huge enabler, especially when it comes to application security. Being able to give teams automated ways that encrypt secrets and cloud service data by default means you know these are happening at a platform level regardless of the development team.
Kubernetes is unlocking a whole new world of rapid growth, innovation and pressure to quickly meet consumer and business needs. Without a secure, scalable platform it means developers are slowed down and hence innovation is hampered, security teams have to manually govern changes and have no easy central view of risk and DevOps teams spend time engineering custom solutions inside the business, who is left owning the technical risk and debt.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.