By Michael
Foster, Principal
Product Manager, Advanced Cluster Security, Red Hat
I first joined StackRox in 2020, coming from a
Kubernetes-centric background and in the middle of the pandemic. At the time,
StackRox was a startup hitting its stride, consisting of people located
worldwide and filling a security gap massive Kubernetes adoption had created.
StackRox was not open source, as there were few security tools, and no complete
security platforms, that were. And while companies in the software industry,
whether startups or big companies, look at open sourcing their products, it is
a massive challenge and undertaking to do it and do it well. In April 2022, we
open sourced the complete Kubernetes-native StackRox platform, and this is the
story of how we did it.
StackRox was founded in 2014 at the beginning of the
container revolution, but hit its stride in 2017 when the company pivoted to be
a Kubernetes-centric security platform. Growing up with the many open source
projects around us, as well as Kubernetes itself, StackRox was no stranger to
open source and the benefits that came with it. The Kubernetes open source
community rapidly expanded, pushing out four releases a year and constantly
providing feature and stability updates. The StackRox team had to grow at the
rapid pace at which that community was growing. We were there through all of
the community's challenges, along with a few internal challenges of our own;
because StackRox itself utilizes other open source projects and integrates
forks of the Falco and Clair projects, our engineering and product teams had to
be in tune with the communities from which we were pulling.
StackRox was the first company to build a security platform
entirely around Kubernetes. We took on bigger and more established security
companies and did it with open source assistance. We started with a
subscription model for the paid platform, while discussing ways that we could
give back to the CNCF community with an open source project of our own.
Our first open source project was KubeLinter, a command-line
interface to identify misconfigurations in Kubernetes objects. It was created
as a completely open source, community project, using security knowledge we'd
acquired from supporting customers on StackRox. KubeLinter enabled developers
to integrate security checks directly from the command line and their CI/CD
workflows. It was easy to use and exemplified the term "shift left",
referring to making security automatically accessible at development time, that
we constantly see in security discussions. It rapidly became popular, with over
a hundred users and developers forking it on GitHub.
We learned a lot from our first open source effort, like
anything else you do for the first time. We faced significant issues from not
preparing enough for a flood of contributors and involved users in the project.
KubeLinter required community management and project infrastructures like
contribution guidelines and issue and pull request triage. Without these
processes, you rely on engineering to discuss changes in Slack threads,
something that is not the best use of their time. The KubeLinter engineers got
invitations to present at virtual conferences and meetups, events that are
typically during workdays or late at night, when they should be getting time to
relax. We were flattered by the project's success, even though we could have
done more to enable its growth and development. Overall, it was a great example
of filling a gap that the community was looking for and validating that we were
on the right track.
Then, at the beginning of 2021,
Red Hat acquired StackRox. The acquisition seemed to happen overnight, and with
it, one thing was guaranteed: StackRox's code would be open sourced.
The first few months were set for
the team to settle and onboard. Ali Golshan, a StackRox co-founder, led the
open sourcing effort. At the time, the open source roadmap was uncertain, so
the first effort we focused on was creating the framework for the project, the
community website at Stackrox.io. We
wanted to promise the community that our security platform would follow the Red
Hat way and be freely available to the community.
As the year moved along, it
became more and more apparent that the community stood to gain a lot from a
Kubernetes-native open source security platform. With log4shell and other exploits in the news, it seemed necessary to
speed up our timeline to release.
To be considered an open source
project, you simply need to have code that is publicly accessible-anyone can
see, modify, and distribute the code as they see fit. But that is not the mark
of a successful project and simply giving the code to the community didn't sit
right with us, anyway. We desired community feedback, opened GitHub issues,
made documentation updates, and released deployment documentation. All of these
additional requirements led to some significant decisions and engineering
effort.
A few of the questions and
decisions included:
- Where will we host the code? Should we use our existing repositories or
create new ones?
- We decided to host the code in our organizational
GitHub repository, letting us flip the switch easier and create a minimal
barrier between our engineers and the community.
- What license(s) will the repositories have?
- With many repositories being set to Public, it meant
reviewing each repository for the correct license. There have been a few cases
of open source abuse from incorrect licensing, something that we never want to
encourage or fall victim to.
- What will the build process look like?
- Red Hat Advanced Cluster Security has its own internal
build process and it was challenging to modify this so that the community could
have the open source builds.
- Where would the community application images going to
be stored?
- Hosting the community images in Quay.io and not Docker
was partially due to the ease of the internal build processes.
- Who will lead community activities?
- Finding volunteers to help with the community efforts
is challenging. It is not usually a part of your job description and the effort
scales depending on how much engagement and users participate.
- Are we going to have online public meetings? When?
There were many human considerations to add to the practical
issues. For example, how would our paying customers react to the open source
StackRox platform? There tends to be a significant amount of hesitation in open
sourcing security applications, and for a good reason. A big concern is that
the code is out in the open and left to scrutiny, where bad actors can exploit
faults in your application. At Red Hat, we see this as a benefit and not a
burden. Open source projects patch security issues significantly faster, and
the openness of the code means that users don't have a "black box"
security application.
Another human aspect is how to manage community contribution
to the project. Since users are donating their time, we want to make it easy
and rewarding for them. Our team can only directly test so many use cases, and
we needed our community for feedback.
And lastly, as a surprise to us, staffing was a significant
factor that delayed the launch. Several people moved on to new jobs, COVID
issues lingered, and the war in Europe affected many of our European-based team
members. We had to push back much of our work because assignees were simply not
available.
In the end, the launch went well, with a few hiccups. Open
sourcing a large, commercially successful software project is a significant
undertaking, where your biggest problems will come from the most unexpected and
unknown.
The end goal for our team was that our code be available for
the community and that users had a safe forum in which to contribute and triage
issues. Thankfully, after a year of hard work, we have achieved that. In large
part, from the guidance of others who have traversed the open source road
before us. Hopefully, this article will help you travel that same path in the
future.
##
***To learn more about containerized infrastructure and cloud native technologies, consider joining us at KubeCon + CloudNativeCon Europe 2022, May 16-20.
ABOUT THE AUTHOR
Michael
Foster Principal Product Manager, Advanced Cluster Security, Red Hat
Michael
Foster is a Principal Product Marketing Manager at Red Hat (formerly StackRox).
Michael is a passionate tech enthusiast and open-source advocate with a
multidisciplinary background. His work allows him to review, discuss, and
contribute to the CNCF ecosystem through various media forms. Michael enjoys
helping people become more security-focused during their cloud-native journey
and invites you to join the open source StackRox community at stackrox.io.