The year 2018 was a watershed for containers, container security, and Kubernetes. Tesla got hacked, the most critical Kubernetes vulnerability to date was discovered, IBM bought RedHat for $34 billion (in large part for OpenShift), VMware bought Heptio for more than $500 million, and investors poured money into container technology startups at an ever-increasing pace.
The Following five blog articles capture and distill the big picture trends in container adoption and Kubernetes security in 2018.
1) February 2018 - Tesla’s Kubernetes Infrastructure Falls Victim to Cryptojacking
Since Tesla bills itself as a technology company that builds cars, it makes total sense that the company uses cloud-native computing, including containers and Kubernetes. What was surprising was the seemingly basic security setting in the Kubernetes dashboard that Tesla engineers misconfigured, leaving the company’s AWS-based computing resources exposed to the Internet, which attackers were able to breach to run cryptomining software at Tesla’s expense.
Heptio, a leading Kubernetes company, published a blog post soon after the news broke out, explaining the cause of the Tesla breach as well as providing a detailed guide on how to prevent a similar breach in the future.
Kubernetes is a fast-moving project and it is easy to find out of date information that gets things working but in an insecure way. From now on, make sure you use the latest security features for your cluster (RBAC, network policy, etc.) and think hard before you expose _anything_ outside your cluster.
2) July 2018 – 11 Ways (Not) to Get Hacked
As Kubernetes has emerged as the de facto container orchestrator, Kubernetes security is becoming top of mind for DevOps, DevSecOps, and Security teams. In this blog post, Andrew Martin summarizes the top 11 security considerations when running Kubernetes clusters. Some of these issues can be addressed using native Kubernetes security controls. For others, you will need a third-party security solution.
The 11 Kubernetes security considerations include:
- TLS Everywhere
- Enable RBAC with Least Privilege, Disable ABAC, and Monitor Logs
- Use Third Party Auth for API Server
- Separate and Firewall your etcd Cluster
- Rotate Encryption Keys
- Use Linux Security Features and PodSecurityPolicies
- Statically Analyze YAML
- Run Containers as a Non-Root User
- Use Network Policies
- Scan Images and Run IDS
- Run a Service Mesh
Cloud Native applications have a more fine-grained set of lightweight security primitives to lock down workloads and infrastructure. The power and flexibility of these tools is both a blessing and curse - with insufficient automation it has become easier to expose insecure workloads which permit breakouts from the container or its isolation model.
3) August 2018 – Demystifying Role-Based Access Control (RBAC) in Kubernetes
When RBAC authorizer debuted as a beta feature in Kubernetes 1.6, developers finally had an alternative to the often-frustrating Attribute-Based Access Control authorizer. While RBAC simplified access control in some areas, it left many users confused about some features.
In this Cloud Native Computing Foundation blog post, author Javier Salmeron explores the basics of Kubernetes RBAC and provides a deep dive into some of the most commonly cited topics of confusion.
In order to work with Kubernetes in production, RBAC policies are not optional. These can’t be seen as only a set of Kubernetes API Objects that administrators must know. Indeed, application developers will need them to deploy secure applications and to fully exploit the potential that the Kubernetes API offers to their cloud-native applications.
4) November 2018 – Kubernetes in production vs. Kubernetes in development – 4 myths
A core tenet of securing containers is that you apply security across the full container life cycle: Build, Deploy, and Runtime. But the requirements differ in each phase. In the Build phase, the primary focus is on ensuring images are free of vulnerabilities and understanding the risk profile of the assets you’re building. In the deployment phase, you’re looking to harden the environment and shrink the attack surface. In runtime, your focus is on detecting external threats and responding to incidents.
In this blog post, author Kevin Casey debunks the four common myths behind the idea that the requirements for DevOps and Security in test Kubernetes clusters is the same as production clusters. The key takeaway is that understanding your container security risk requires context that can be acquired only by looking at the full container life cycle.
Container image vulnerabilities can quickly become critical in production, for example, whereas the threat may be limited or non-existent locally.
5) November 2018 – StackRox Publishes Industry’s First Ever State of Container Security Report
We couldn’t compile a Top 5 Blog list without including one of our own, could we?! When we published our State of Container Security Report in November, the more than a dozen news articles featuring the results focused on a handful of key findings:
- 70% of containers are deployed on-premises (either purely on-premises or in a hybrid model).
- DevOps, not security, is more likely to be responsible for container security (31% vs 28%).
- Despite the rapid adoption of containers, 70% of respondents lacked a container strategy completely, or were in planning mode.
A few data points highlight the angst companies are feeling about securing their container environments: 50% are worried their container strategies don’t invest enough in container security, 54% are most concerned about misconfigurations and exposures, with only 17% worried about attacks.
As we head into 2019, we expect blog posts on security tips, best practices, and compromises of Kubernetes and containers to continue to dominate the landscape – we look forward to sharing them in the months to come.