Since Kubernetes is a container management tool, it is important for teams to secure their application at the start and end of every activity – in the pre-production and deployment stages. DevOps and automation are a great way to do this.
What is Kubernetes?
When talking about microservices and containers, any conversation is incomplete without Kubernetes. In microservices architecture, typically, an orchestration solution like Kubernetes is deployed to monitor the health of the pods or containers.
Kubernetes is a container orchestration platform developed by Google, which is now open source. It allows web hosting of applications at scale, by automating deployment and management of containerized applications.
By identifying request patterns, it’ll direct you to an alternative path in case of heavy traffic, just like in Google Maps. It does this by automatically scaling up and deploying another container which is a replicated version of that particular container. Itcan also downgrade containers, keeping them on hold until a requirement arises.
Why is Kubernetes so popular?
Kubernetes has gained popularity as it is open-source. It is not restricted only to enterprises but also leveraged by SMEs. Moreover, Google has adopted this for many services as a back-end orchestration engine to maintain their containers. Prior to Kubernetes, Docker came out with their own orchestration tool – Docker Swarm. However, there were some limitations with Docker Swarm where Kubernetes shone. Certain features were not available and it was not scalable.
One area where Kubernetes shines is that it is not restricted to a certain set of environments. Organisations want the flexibility to build and deploy real-time production instances. This can be on-prem, hybrid or on multiple cloud technologies.
Luckily, Kubernetes is highly adopted across cloud service providers. They have the set of services required for delivering and maintaining the micro services application stack even on cloud.
High adoption makes it easy for companies to leverage these services from cloud service providers to deploy their applications in the hybrid approach – where they have on-prem, on data centre, on cloud. There is a highly mature community actively participating to bring in more features and enhance the existing orchestration solution. As this community is being managed by Google, Kubernetes becomes a very promising solution altogether. This is why many organisations are keen to have it as their main orchestration engine. Hence its popularity compared to other orchestration solutions.
Ensuring application security in Kubernetes-based deployments
When you are dealing with Kubernetesor any other orchestration solution, there will not be any programmatic challenges. Unlike when you deal with applications, there can only be security misconfigurations. Majorly, there are some code-level vulnerabilities that could be exploited.
If they are choosing an orchestration solution other than Kubernetes, they have to ensure its backed by a highly mature community. Also, that there are relevant security standards they could readily adopt to make sure they are secure.
If there are no standards defined, it can be a very challenging task for the internal operations team. They have to do a lot of research to figure out how things are configured in that particular orchestration solution. In case there are security guidelines or any documentation relevant to that orchestration solution, they must refer to all these checklists thoroughly before deployment.
Since most enterprises and SMEs have adopted Kubernetes, there is widespread understanding and maturity when dealing with this subject. Several experts in the community also provide insights and feedback, helping others to secure things.
Common scenarios: Ensuring Security during build and production stages
When Development / Operations teams are trying to build an application, they package all the relevant files, solutions or tools required into a Docker image. Docker images are stored in repositories such as Docker Hub. There are also a large set of images readily available, created by third parties. You can then compile your own version of the image based on the tech stack you are working on and on the use case – with customisations and your own set of applications and frameworks built in. You can again store these images on Docker Hub, which is a public repository. You could also have a private repository on Docker Hub.
Some companies even maintain their own repositories on-prem, on collocated servers. When you say build, the Docker image would be run on a particular instance, server or any worker node. Once executed, it is called a container wherein you have the running version of your application.
In the build phase, it is critical to ensure that the entire application or base image taken from Docker Hub or any other repository is a hardened version and completely secure. Development teams usually pull any image they wish to. They base their choice on the functionality they wish to achieve without emphasising on security. This is the major area where most organisations tend to be complacent.
Internally, teams must ensure that their applications are secure by doing Source Code Analysis, Software Composition Analysis (where in third-party modules or frameworks are being thoroughly reviewed). They need to dig deep into every activity in the pre-prod stages – when they are trying to build the Docker image and their application stack or software components being used. Whatever security issues need to be addressed must be done right at that point, before moving on to the next phase. Otherwise, there is a good chance that the Docker images are highly vulnerable in their production instances. During deployment, the Docker image should be thoroughly scanned once more in the production instance. It is critical to filter out all the security vulnerabilities to ensure that the final version is always secure.
DevOps is another key area where organisations can engage automation at every stage for a streamlined process. All necessary checks while building micro services applications can be addressed through automation. Any issues must be reported to the teams before they release these changes to production instances. Highly complex applications are divided into multiple smaller chunks of functionalities in terms of containers. With several containers deployed, this is impossible to do manually.
There should be an increasing number of security solutions integrated into DevOps because in micro services we are dealing with multiple containers.
Security standards: An imperative
When it comes to security standards, mature communities always follow best practices in terms of securing their orchestration solutions. Centre for Information Security (CIS) is one such community which maintains security baselines for every major software component or solution that most enterprises would typically use. It could be Windows OS, G-Suite or Microsoft Office Suite, SharePoint, Active Directory, Kubernetes, etc.
Companies can also follow industry best practices to ensure that their entire security stack is hardened. Hardening means tightening any weak configurations. This is to ensure there are no gaps where an attacker could exploit or compromise the system or a particular application.
For Kubernetes, there are some checklists where in the CIS provides all the baseline security measures for containers between, say, 50 to 100. ‘Baseline’ means these can be configured for any organisation in the micro services infrastructure where in containers are orchestrated based on Kubernetes. The Development / Operations teams are instructed to configure Kubernetes without security misconfigurations and no gaps in production instances. Majority of the industry follows standards set by the CIS to deliver a secure container orchestration solution.
Embedded security solutions – the way forward
Kubernetes excels at managing scalability with reliability factors readily baked into it. Their focus is about bringing in more automation features in terms of deploying and managing things.
Though Kubernetes is backed by a large community, unfortunately, they haven’t embedded security solutions or toolsets. Customers have to rely on third party solutions in order to bring in security features and complement the Kubernetes offer.
As the containers themselves are a different technology or are handled in a different layer, this is not the responsibility of Kubernetes. Kubernetes only has to deal with strong security configurations. For instance, when containers are running, Kubernetes has to ensure they are not running in a route privilege or admin privilege.
Majorly, the vulnerabilities exist in the development process or in the Docker images. This has nothing to do with Kubernetes. So, they don’t deal with the security aspect of the other layers.
Research is on to bring out more Kubernetes-based security solutions. With this, security issues could be addressed within no time using the DevOps process. No matter which container technology you use then, Kubernetes will address every security aspect.