Almost a year passed before I began developing the Cloud Security plugin for JetBrains IDEs to improve the security of Infrastructure as Code files. I started by implementing the Docker scanner. Many rules were implemented, especially for Docker security, and many lessons were learned.
This week, I found new energy to begin delivering the next milestone in the plugin’s lifecycle. I started implementing Kubernetes Security best practices to align with the NSA Kubernetes Hardening Guide.
I have always postponed implementing rules to analyze YAML files because it was boring, and I struggled. There wasn’t an API to implement it easily—just brutal PSI analysis. I thought so, but then I found useful classes and methods in the YAML plugin and wrote a simple YAML-path engine to find elements in the text more comfortably. This approach helps me rewrite some smelly parts in the Cloud Security plugin in Docker Compose implementation. It helps me analyze and start working, diving deeper into Kubernetes Security.
Everything started from another event in my life: I needed to learn more about Kubernetes Security, as I did while implementing the Docker scanner, so I started researching this subject and found Kubescape. This tool contains many rules to analyze the security of Kubernetes objects, and it has an implementation plugin for VS Code, but not for JetBrains IDEs. I thought, “Hm, okay, I could implement these rules in my cloud security plugin.”
Kubescape uses a library of rules that are implemented with Open Policy Agent in Rego rules. Rego rules could be compiled to WASM, and here was a field for experiments. I tried to use opa-java-wasm to integrate Kubescape rules as is. While I experimented with this approach, I found a bug that was fixed by the maintainer. I really appreciate how fast it was fixed.
There were core problems with that approach. To analyze YAML files, they should be converted to JSON first, and while the user is typing in the YAML document, it could raise serialization errors due to a non-parsable YAML file. This was a tombstone for that, because all implemented inspections should work on the fly without those problems. The next problem is that it is necessary to highlight specific elements in the YAML. With text-based output, it is hard to find which elements should be highlighted, because there were corner cases for that. Code with experiments stored in the dedicated branch.
After that, I started looking for features that could improve my developer productivity, and I finally successfully implemented the first Kubernetes Security rule. So, the plugin now contains not only the Docker scanner but also Kubernetes.
Alongside the new YAML-based rules, I did a rebranding. At the start, the plugin pointed to Infrastructure Security, and it was one of the first names. Now, it is called Cloud (IaC) Security. This name is more laconic, shorter, and modern. I think this name should work better for users who install the plugin by searching in the marketplace.
The new logo was designed for the plugin. Now, it’s the plugin’s mascot—a dog named Jessica. She was my dog for many years, but then our paths separated. This logo is a copy of her pictures, combined into a cyber style with the help of AI and redrawn by an artist in vector format. This step symbolizes a memory of her.
My goal is to ship at least one new Kubernetes Security rule or quick fix every week so development stays steady and predictable. If I have time, I’ll probably try to improve or extend Docker Security rules. If you haven’t installed the Cloud Security JetBrains plugin yet, give it a try—I’d love your feedback. And if you’d like a heads-up whenever a new blog post drops, follow me on social media.
