My LFX Mentorship Experience
The LFX Mentorship program is designed to provide developers (mostly new to open-source development) with necessary skills and guidance from mentors needed to successfully kickstart their open-source journey and contribute to projects that matter. Click here to learn more.
MY JOURNEY TO BECOMING A CONTRIBUTOR TO KUBEARMOR
While I was thinking of something interesting to do with my summer break, a friend shared a link to Linux foundation open-source projects that would be available to the next cohort.
Skimming through the projects, I immediately picked interest in the ones related to Kubernetes in some way because in my previous work experience, I had worked with Kubernetes (as an orchestration tool), so seeing an opportunity to contribute to a tool which I have used extensively was exciting for me.
At the time, I was just learning Golang, so seeing that these projects were in Golang made it more interesting for me. I saw it as a perfect opportunity to sharpen my Golang skills, a break away from normal API development, and an opportunity to contribute to something that matters.
THE APPLICATION PROCESS
After going through all the available projects, I narrowed down my choices to three. I prepared my CV and motivation letter, tailored to each of the applications.
And so, I applied — fortunately, I got selected!
Now, if I were to apply again, something I would do differently is to reach out to the mentors first, discuss with them to have more insight into the projects, join the community slack channel and then apply. The community is very open and welcoming, and trust me, you can be sure to get prompt responses.
GETTING STARTED
To be honest, at the beginning, I didn’t understand much of what I was doing or what I was to do. I reached out to the mentors, trying to get them to explain the tasks to me. I started off with the KubeArmor documentation, going over it again and again (before we had our first official meeting).
For the first 2 weeks, I was playing around the installation of KubeArmor and KArmor client, to understand the status quo, and how it works in practice.
I faced a couple of challenges at this point, I was using a mac big sur os and it doesn’t support KubeArmor, then I had a hard time understanding the different modes on which KubeArmor work e.g. systemd mode, k8s. (more on this later)
After a few weeks, with kind support from my mentors, I was able to grasp the flow and how things work.
INTRODUCTION
I’ve been mentioning KubeArmor and kArmor a lot, a brief introduction to what they are:
KubeArmor is a cloud-native runtime security enforcer that restricts the behaviour (such as process execution, file access, and networking operation) of containers and nodes (VMs) at the system level. KubeArmor allows operators to define security policies and apply them to Kubernetes. So, if there’s any violations against security policies, KubeArmor immediately generates alerts with container identities. Read more here.
kArmor client is the helper utility that helps to manage KubeArmor.
THE TASK: kArmor Probe Utility
The purpose for this probe utility is to provide various information on KubeArmor depending on the current environment. Information such as whether KubeArmor is supported in the current environment, KubeArmor current running mode, the enforcer used by KubeArmor, the pods in the environment being handled by KubeArmor, the policies being applied to the pods etc.
THE MENTORSHIP PROGRAM
Week 1–2
Like I mentioned earlier, for the first few weeks, I spent time trying to understand the basics, knowing how KubeArmor and kArmor client tools work.
Also in this phase, I took time to understand the task at hand, I indicated that I will be handling the issue at https://github.com/kubearmor/kubearmor-client/issues/19 and the issue was assigned to me, so I went over the issues and the work items, I tried to get more insight from the mentors on what is the expected outcome.
The following resources helped me in getting started:
https://github.com/kubearmor/KubeArmor
https://github.com/kubearmor/KubeArmor/blob/main/getting-started/deployment_guide.md
https://github.com/kubearmor/KubeArmor/blob/main/contribution/contribution_guide.md
https://github.com/kubearmor/KubeArmor/blob/main/contribution/development_guide.md
I didn’t get the full picture at the end of this phase though, but I had a better understanding than when I started.
One thing I always said in the meetings for each task is — I’m not sure how exactly that is going to work out, but I will sure figure it out. So, it was a continuous learning process for me.
Week 3–12
After getting a good understanding of the task at hand and some background, at least good enough to get started, as well as the issues and the expected outcomes, I sectioned the tasks into different phases and had an expected output for each phase.
The probe utility works in 2 parts — if KubeArmor is absent, it probes the system to check if KubeArmor is supported in the current environment.
If KubeArmor is present, it checks which environment KubeArmor is currently running and analyses configuration and supported KubeArmor features in the current environment.
So the first part was in two phases and the second part was divided into 2 phases as follows:
First phase is to probe in an environment where KubeArmor isn’t running. It was quite easy to achieve this, I made my first PR and had some reviews and comments from the mentors
The probe utility does a pre-check in this case to see if KubeArmor would be supported in the current environment.
A quick comment: the mentors are so thorough in giving review and they do this kindly. So, I don’t feel like my code is thrash, at the same time, they gave very detailed and honest feedback.
Second Phase is to do a full probing when KubeArmor is not running in the environment, this requires deploying a privileged daemonset which has access to the nodes for required information.
After this phase was completed, reviewed and tested, my PR got merged. Yaay!!
kArmor has no access to the node info, So a full probing is required to get access to node information. When the –full tag is used, a privileged daemonset is deployed which has access to node information and the probe output is as shown below:
The next three phases involve probing when KubeArmor is running, and this requires me to get some information from KubeArmor. So, I cloned the KubeArmor repo and did some work there.
The Third Phase was to probe when KubeArmor is running in system mode
The fourth phase was to probe when KubeArmor is running in Kubernetes environment. If kubearmor is found running in Kubernetes, the probe utility fetches all pods, deployments, containers, and daemonset. It also gets all pods in the cluster being handled by KubeArmor and the corresponding policies running on them.
Kubearmor daemon has access to node information, so these data are written to a file and accessed by kArmor.
The final phase was to get all pods being handled by KubeArmor and their corresponding security policies.
At the end of each of the phases, I tested the code in different environments to cater for environment differences. Also, there was a thorough review on the output formatting and presentation.
My mentors wouldn’t have me present an output that wasn’t well aligned or formatted. It was a great experience for me, different from what I was used to.
MOST VALUABLE LESSONS LEARNED
The first and topmost lesson I learnt is paying attention to details, Special thanks to my mentor Barun Acharya for always pointing out even the slightest mistake. This makes me more conscious whenever I’m working on the task.
Another lesson is knowing when to ask for help. I learnt to understand that the mentors are also as busy and so, it made sense to have done some good level of research before bugging them with questions that I could easily get answers to in provided documentation.
More importantly, I understood that I don’t have to have it all figured out at once. One step at a time, when we get to the bridge, we will cross it.
CHALLENGES FACED
I remember sending a message to my mentor saying one day to say, I don’t even understand what I’m doing any more, nothing seems to be working, it’s like one bug leads to another and another, and he replied, “That’s what we do every day”, lol.
The first challenge I encountered was trying to install KubeArmor on my mac big sur os, lol, apparently, that wouldn’t work, because at the time, mac big sur os doesn’t support KubeArmor, I stubbornly wanted to see it work, lol, it’s not magic or rocket science, some conditions need to be met, in terms of environment specification.
Another challenge related to this was getting my environment right. I remembered uninstalling something (while experimenting, I’m not sure exactly what it was) and then I kept getting very weird errors, after several days of being frustrated, I had to back up my code, delete my VM, and set up the environment all over again and that solved the problem I’ve been having for several days.
So, it’s important to understand the dynamics of the environment, understand how things work and in case there are weird bugs, don’t hesitate to replicate the issue in a new environment, that might help isolate the issue.
Another funny challenge I had was with git (merge conflicts, rebasing and squashing). So before now, I worked very well with git, but it seems in open-source contributions, you get to explore git more extensively. I had issues resolving my merge conflicts especially whenever I was being asked to rebase and squash my commits, I ended up messing everything up. Lol
After reading the documentation to understand how rebase and squashing work, it became much easier for me and I could just do it in a few seconds.
A special thanks to my mentors Barun Acharya, Ankur Kothiwal and Rahul Jadhav for being patient, kind and thorough through this process. It was really a privilege and a pleasure working with you.
For reviews, comments and questions, kindly reach me on LinkedIn @ Esther Adenekan
