Almost a year passed before I began developing the plugin to improve the security of Infrastructure as Code files. Many rules were implemented, especially for Docker and Dockerfiles, 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 rules to align with the NSA Kubernetes Hardening Guide.
I have always postponed implementing rules to analyze YAML files because it was struggling boring. There wasn’t an API to implement it easily – just brutal PSI analyze. 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 comfortable. This approach helps me rewrite some smell parts in Docker Compose analyze and start working diving deeper in Kubernetes.
Everything started from another event in my life: I needed to learn more about Kubernetes Security, so I started research on this subject and found Kubescape. This tool contains a lot of rules to analyze the security of Kubernetes objects, and it has an implementation for VS Code but not for JetBrains IDE. I thought, “hm, okay, I could implement these rules in my 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 rule.
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 a mascot of the plugin—a dog with the name “Jessica”. She was my dog for many years, but then our ways separated. This logo is a copy of her pictures, combined into a cyber style with help of AI and re-drawn by an artist in vector format. This step symbolizes a memory of her.
My goal is to ship at least one new Kubernetes rule or quick fix every week, so development stays steady and predictable. If you haven’t installed the 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 LinkedIn: https://www.linkedin.com/in/protsenkodev/