Final Blog!


The motivation for the kubernetes network policy project completed this summer was to limit communications between the kubernetes “pods” that live in a kubernetes cluster and run the PingThings PredictiveGrid™ platform. A kubernetes pod behaves somewhat like a server within kubernetes. Although multiple pods might be running on one AWS server, within the cluster, each is assigned its own IP address, and by default kubernetes does not restrict communication between pods in a cluster. Thus, in order to secure the information contained in different pods in the cluster — especially as the number of users grows via the NI4AI project — network policies must be implemented. A pod’s communication is restricted by the union of the policies that apply to it, so the safest way to secure a cluster is to put a default-deny policy in each namespace within the cluster, and then go with a least privilege approach: grant exactly the access privileges required and nothing more. First, a default-deny policy for both ingress and egress requests was implemented in the main namespace of the cluster. Then, each pod labelled “app-x” was made to be the target of a policy that allowed ingress from pods labelled “needs-app-x.” Pods labelled “needs-app-x” were made to be the target of policies that allowed egress to pods labelled “app-x”. This design choice was made because there were multiple categories of pods, all with their own “app-y” labels or labels of another format, that needed access to “app-x.” Now, instead of listing all those labels in the network policy and having to modify potentially many network policies each time a new pod is developed, all that must be done when writing the template for a new pod is to label that pod “needs-app-x” for everything it needs access to. At first, each “x” corresponded to one YAML file containing two network policies, but when debugging, it proved to be difficult to distinguish whether a bug originated from an erroneous egress rule or ingress rule. The policies were then split into a separate set of files for egress and ingress. Default-deny-ingress and the ingress policies were applied and debugged first, before adding default-deny-egress and the egress policies. This was a great example of how useful it can be to break down a task into subtasks. After learning many lessons while implementing ingress and egress policies in the main namespace, adding policies to the other namespaces went much smoother, although new sets of pods and labels meant there was more debugging to do. To test the effectiveness of the policies, netcat was used to initiate simple communication between pods, and the logs and status of the pods were monitored. The initial netcat experiments revealed that the default kubernetes network plugin silently ignores network policies, so it had to be replaced with kube-router. Ultimately, network policies were successfully implemented in all namespaces of the cluster, along with two fail-safe mechanisms: ability to toggle all network policies on or off, and ability to label a pod to be unaffected by network policies.



Overall my experience at PingThings was a dream come true and I learned more than I could have ever imagined. I became well-versed in a new platform (kubernetes). I learned about a new-to-me field of computer science (DevOps) and fell in love with how powerful it can be. I wrote and tested code in file formats that I had never worked with before, and was able to develop and test my git branch sufficiently for it to be merged into the master branch of the whole app. I learned how to create aesthetically pleasing documentation in notion. I learned what AGILE development was and how it can look in practice. Above all, I learned that I had the ability to learn and feel fulfilled by learning.

I have always much preferred working to school. In my four years at UC Berkeley, I have spent each semester in a growing wave of anxiety. Twice a year for 15 weeks, I either am studying and feeling stupid for not understanding things faster, or not studying and wracked with guilt that I should be studying. I felt like a human being only during breaks from school, and saw graduation as the light at the end of the tunnel. This past spring, as I neared completion of my Computer Science degree and began to realize how much knowledge I would have to learn outside of the classroom, I felt overwhelmed. It seemed like even if I went straight into the workforce instead of to graduate school, I would still be stuck in an endless cycle of having to “study” and that I would never arrive at a place where I could just become an expert at what I already knew. “Maybe I should have chosen a subject that doesn’t change as fast as tech,” I worried, questioning my choice of major.

My experience at this internship has been invaluable to my perspective on my future career. After learning outside of school and enjoying it, I am so much more optimistic about my ability to continue in this field and feel fulfilled. Certainly there were challenges, and days where I clocked out without understanding what was causing an error, but the experience was overall so positive. I learned new things with the motivation of contributing to a project that inspired me. It was exciting to apply those new skills and create a new feature that real people would actually use, instead of just an assignment or an exam. I grew by leaps and bounds as a programmer, including learning how to effectively document my code and communicate to my team how it would affect future development. I am currently continuing on at PingThings, learning a new language as I prepare to pivot to infrastructure tasks that center around things other than kubernetes network policies. To be honest, sometimes (often) I am still struck with imposter syndrome. But having my successful project from this summer under my belt gives me hope that with another year or two of experience, I will have more and more faith in both my ability to do tasks that I have already done, as well as my ability to adapt when I am presented with things I don’t yet understand.