A security report for the first quarter of 2020 published by Threat Stack, a provider of tools for ensuring security and compliance in the cloud, details some of the most common security issues organizations are encountering when they deploy Kubernetes on the Amazon Web Services (AWS) public cloud.
The report suggests IT organizations that have deployed Kubernetes should address the following issues when employing AWS Elastic Kubernetes Service (EKS):
Orphaned security groups for some EKS load balancers: Load balancers serving as EKS Ingress Controllers are assigned a default security group. AWS automatically cleans up these permissions after 90 days. However, Threat Stack suggests organizations should be proactive in removing them once the load balancer is no longer used.
Multi-tenant EKS networking mismatch: EKS clusters use the Amazon VPC CNI plugin for Kubernetes, allowing it to represent pods on the AWS Virtual Private Cloud (VPC). This is not enough to support Kubernetes network policies unless organizations have also deployed an instance of Calico network virtualization software, the report finds. Because of how the container network interface (CNI) plug-in maps down to the AWS elastic network interface (ENI), the CNI can only support one security group per node. This can potentially create problems when EKS schedules unrelated pods on the same node, warns Threat Stack.
Intruders using aws-iam-authenticator for EKS reconnaissance: Suspicious users have downloaded the legitimate aws-iam-authenticator tool used for accessing EKS clusters via identity access management (IAM) credentials into the /tmp directory in a container on EKS. The users then accessed EKS information using the AWS CLI to probe further into the cluster.
Sam Bisbee, chief security officer for Threat Stack, says the shared responsibility approach to cybersecurity that most cloud service providers employ can be especially challenging when it comes to Kubernetes. Most IT teams assume they are responsible for securing cloud applications while the cloud service providers secure the infrastructure. However, when it comes to container platforms such as Kubernetes, cybersecurity responsibilities are still not quite as precisely defined. As a result, those uncertainties may be acting as a drag on the rate at which Kubernetes clusters are being deployed in production environments.
None of this means Kubernetes is not being deployed in the cloud. Kubernetes services are among the fastest-growing in the cloud. However, cybersecurity teams are starting to apply increased levels of scrutiny to these services now that more production applications are starting to be deployed on them. The challenge, of course, is containerized applications behave very differently than traditional monolithic applications, which requires time for cybersecurity teams to understand, says Bisbee.
In general, organizations that have embraced best DevSecOps practices deploy applications on Kubernetes clusters in the cloud tend to be further along the cloud security maturity curve than those that have not, notes Bisbee.
It may be a while before cybersecurity professionals are completely comfortable with containerized applications. In theory, containerized applications are more secure because it’s much easier to rip and replace containers that have vulnerabilities than it is to patch a monolithic application. The issue, of course, is that given the complexity and relative lack of container security expertise, there are plenty of opportunities for mistakes to be made.