Kubernetes Security in the Cloud
For most organizations that have made investments in Kubernetes, ensuring the security of their Kubernetes environment is turning out to be a significant concern. As an example of why, consider the Kubernetes privilege escalation flaw (CVE-2018-1002105) announced in December 2018.
The bug allows any user who has access to the subpath volume mounts to access files outside the volume as well. As a result, it was possible for an attacker to escalate their privileges to gain full administrative access on any compute node running in a Kubernetes pod.
Although that particular vulnerability has now been addressed, its seriousness highlighted the importance of Though Kubernetes’ Product Security Team addressed the bug, it still highlights several concerns related to the vulnerabilities in Kubernetes.
Risks with Kubernetes Implementation
With the increase in adoption of Kubernetes among companies, there is an ever-increasing risk of exposure of the hosted business applications. The stakes are getting higher. Cloud-based multi-environment and hybrid deployments have made Kubernetes configurations more complicated than ever. With the increasing number of complex configuration controls, chances of human error in the administration are gradually increasing, leaving the entire environment of an organization vulnerable to cybersecurity incidents.
In Feb 2018, Tesla witnessed a cyber attack on its infrastructure due to an exposure in a Kubernetes deployment. The attackers targeted a particular Kubernetes console, which was not protected with any password, and allowed access to Tesla’s larger AWS environment. It was discovered that attackers had executed some cryptocurrency mining scripts on the unsecured Kubernetes instances, which enabled the attackers to gain access to Tesla’s AWS compute resources.
In June 2018, the global fitness and weight-loss services provider, Weight Watchers, also suffered a security breach due to an exposed Kubernetes instance. It was determined that the Weight Watchers IT administrators forgot to set a password for its Kubernetes server, allowing attackers to connect to the company’s internal IT infrastructure and access sensitive details, including the AWS access keys, Kubernetes pod specifications, as well as several Amazon S3 buckets that were holding the company’s data.
Cybersecurity incidents like the ones at Tesla and Weight Watchers provide a glance at the increasing risks associated with Kubernetes. This puts a lot of pressure on organizations to immediately take strict steps to ensure the security of their Kubernetes clusters. They need to strictly follow best practices and also look for ways to automate security.
Security Best Practices with Kubernetes
To ensure the security of a Kubernetes implementation, the Center for Internet Security (CIS) has provided a set of guidelines that organizations can follow as best practices. Additionally, most Kubernetes vendors and operators offer their own set of best practice guidelines. Based on the specific requirements within the implementation environment, organizations can identify and enforce the right set of guidelines to reduce the risks of a security incident.
Here are a few security best practices that organizations should consider for a secure Kubernetes environment:
Kubernetes’ Product Security Team keep releasing new security upgrades, which are not just bug fixes, but also enhancements to existing levels of security. Since the discovery of the major Kubernetes bug CVE-2018-1002105, Kubernetes revisions v1.10.11, v1.11.5, v1.12.3, and
v1.13.0-rc.1 were released. Organizations must upgrade their Kubernetes environment on a timely basis to mitigate several associated risks. Many Kubernetes vendors today offer automatic upgrades, which is one of the key advantages of using a managed service rather than managing your Kubernetes stack on your own.
Instead of having a single large namespace to host all application workloads, use separate namespaces. Each aspect of an application or a microservice can run in a separate namespace, having its own set of access permissions and limitations, without having any impact on other namespaces.
Control the permissions to access Kubernetes resources at a granular level. Avoid having single super-admin access for the entire environment or the cluster, and rather have dedicated admin roles for separate namespaces, and provide the access permissions on a per-task (like debugging) or per-request (like new application deployment) basis. Instead of using the traditional Attribute-Based Access Control (ABAC), implement and use the Role-Based Access Control (RBAC), which is enabled by default in Kubernetes 1.6 onwards.
Organizations should create and define Cluster Network Policies (like restricting access from other namespaces by default) to keep control over the access in and out of all the containerized applications. Also, Pod Security Policies can be defined using the Pod Security Policy admission controller, which can help prevent some types of network spoofing attacks.
Automated tools for configuration check
Use a tool which can scan the entire Kubernetes environment to assess its conformance with established guidelines like the CIS Benchmarks. This can help ensure secure configuration for all deployments and greatly reduces the chances of human error.
The Alcide Advisor tool
To automate Kubernetes’s security-related processes, Alcide provides a continuous security automation tool. The Alcide Advisor tool for Kubernetes & Istio can automatically scan for a wide range of compliance, security, and governance risks and vulnerabilities. In addition, it provides detailed insights and actionable recommendations for the administrators to ensure that the Kubernetes clusters, nodes, and pods operate within the provided security guidelines and best practices.
Alcide Advisor can monitor the entire Kubernetes environment and provide alerts for any misconfigurations or loopholes left behind due to human error or otherwise. It reports on how compliant and secure your Kubernetes cluster is, pointing to specific vulnerabilities that need to be secured. Additional key features include a Kubernetes Center for Internet Security (CIS) benchmark check, checks on ingress controllers, security measures specific to cloud vendors like AWS, and checks related to the service mesh tool, Istio. It can also hunt for misplaced secrets, and check for workload hardening from Pod Security to network policies.
Alcide Advisor simplifies the security assessment of the entire Kubernetes environment, by providing a single window to monitor all relevant risks, covering network policies and topology, and auditing related checks. The entire process is carried over in the background without having any significant impact on any apps or other operations. The key motive behind Alcide Advisor is to ensure continuous security of a Kubernetes environment without impacting DevOps agility.
About Twain Taylor
Twain is a Fixate IO Contributor and began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces, and resolving issues affecting both customers and the Support team, and handling escalations. Later, he built branded social media applications, and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications.Vince Power is an Enterprise Architect at Medavie Blue Cross. His focus is on cloud adoption and technology planning in key areas like core computing (IaaS), identity and access management, application platforms (PaaS), and continuous delivery.