Container Security – 3 Red Flags to Watch For
According to Forrester, 58 percent of developers have reported that their companies are either currently using containers or plan to use containers within the next year. However, in a survey by CNCF, 43 percent say security in enterprise adoption of containers is a huge challenge.
We are assuming this challenge has arisen due to a lack of knowledge of the vulnerabilities that containers may introduce. And that’s understandable since containers started to become mainstream when Docker was introduced back in 2012.
Luckily, we’re well-versed in the world of containers, and to help you prevent your containerized application from being exposed to hackers, we share the 3 red flags that you need to look out for and the solution that goes with it.
Flag #1: DevOps Teams Passing the Buck When it Comes to Container Security
While DevOps have introduced a philosophy of collaboration between those who write the code, the developers, and those who implement it, the operators, and introduced a range of practices such as containerization, microservices, and CI/CD, the conversation of security and compliance doesn’t happen very often.
When security protocols and procedures are being monitored by a separate entity, we get another siloed scenario; similar to how things were with developers and operators before the introduction of DevOps. That is, whenever a flaw is picked up, the team that is solely responsible for security would have to relay this information back to the DevOps team to make the necessary amendments.
However, with this scenario, there is potential for when a flaw is picked up, it might be too late to do anything, and the flaw has gone on to become a widespread issue. This is especially the case with containers since it is harder for security teams to pinpoint the root of the flaw when you have to go through clusters comprising of thousands of containers.
Failure to iron out any flaws as quickly as possible can really damage the reputation of your company, and you can see churn rate reach sabotaging levels.
Rather than placing the responsibilities of security to a separate team, it is better to transition your DevOps team into a DevSecOps team, where your team will assume a greater role in security matters. This will increase the accountability for developers who write the code and ensure their code is rigorously tested before being released.
For DevOps teams that don’t have a substantial amount of experience with security, you can place a security engineer into your team and get them to collaborate closely with each other.
If you have a CI/CD pipeline for your containerized applications, you can bake-in and automate container security and compliance with tools such as Twistlock. This will help you discover flaws earlier in the pipeline, making them less costly to fix. It is important to note when implementing security and compliance into your pipeline, it will require an all-round effort from those who are involved in the development pipeline, this will include developers, testers, and administrators. This is something that we advocate here at K8sGuru.
Flag #2: Testing is Undertaken at a Later Stage of the Development Cycle
While container vendors have been increasing their security profiles from 2015 onwards introducing tools like SELinux and OpenSCAP to make the container themselves more secure, the container marketspace hasn’t done much to ensure the code that makes it into the container is flawless.
While dynamic testing does exist, more often than not, code that is going inside the container is only tested once, and that is at a later stage in the development stage when the software is in production, or close to it.
Having testing done at such a late stage can really slow down your time-to-market. If your testing stage has identified any issues, it needs to go back to the developer for review and amend, undergo testing again, then deploy it to the container.
Plus, only having a single stage during the development for testing doesn’t really guarantee that all the flaws will be identified. Things can go amiss, and engineers may not have sufficient time to thoroughly check everything. Therefore, flaws can easily slip through the net.
Rather than testing at a later stage, teams should adopt “shift-left security”, a concept where software testing and security operations take place early (to the left) in the linear software development chain. The concept encourages developers to become more proactive and enables them to test their code early and continuously. Similar to DevSecOps, it increases accountability in developers, making them strive for continuous improvement.
However, shifting your entire security procedures to the left does require a change in culture. It involves building the right team who are prepared to be involved in regular and rigorous testing during the early stages of development and be more transparent. Also, you would need to collect various metrics to determine whether the shift-left approach is leading to better results and identify any areas that need improvement.
Flag #3: Container Sprawl
The common issue that I keep coming across in containerized applications is seeing developers becoming overwhelmed in having to manage a massive application consisting of thousands of containers.
While containers have been hailed for its effective use of resources, portability, and speed of application runtime, it is difficult to avoid this scenario unless your application is small and is comprised of a handful of containers.
Container orchestration platforms like Kubernetes and Docker can help teams to automate container deployment and resource allocation at scale, but by themselves, they offer relatively limited functionality when it comes to enterprise-grade container security.
To resolve this red flag, you can utilize a service mesh tool such as Istio which can work in tandem with Kubernetes, Mesos, Consul, and other containerization tools. Istio provides all the essential tools to run a distributed microservice architecture, even if it has been containerized. The tool helps you better manage traffic and isolate any failures, preventing it from affecting the rest of the system. It also allows you to better manage authorization, authentication, and interaction of microservice interactions at scale.
You can also use Kube-hunter, an open source tool which looks out for security issues, by running automated penetration tests, based on the IP or DNS name of your Kubernetes cluster. However, we do advise caution when running active hunters with kube-hunter, it may change the code or state of the cluster. That said, kube-hunter is an excellent tool to identify any weaknesses before it gets exploited by malicious hackers.
These Red Flags Can Be Avoided By Adopting New Practices and Tools
Even though containers have seen rapid adoption, it brings with it, a whole new dimension when it comes to security concerns. Most of the security concerns revolve around the coding that is deployed in containers, running tests at a later stage of the development stage, and seeing your team becoming overwhelmed in having to manage thousands of containers.
However, by getting your team more involved in security, adopting a culture of running tests early on in the development chain, and utilizing the right tools, you can squash these red flags early on.