Closed krisnova closed 4 years ago
Keep the Cloud Native Security hub as is and continue with our existing plans, we can always revisit this later.
Migrate to the Artifact Hub now, and shutdown the cloud native security hub.
I think the CNCF Hub is probably a good idea in the long run, to make tools discoverable and provide some assurances to end users on quality and interoperability. That said, I think it should be opt-in and I don't see any reason for Falco to migrate immediately. I'd say use the current one now, and the CNCF Hub at some point in the future.
Thanks @shane-lawrence I agree that we should re-visit this as needed in the future. So I added some language that this vote is more of a "right now" style vote and encouraged us to re-open it as needed.
Kris Nova personal opinion:
I personally am still not sold on a global hub especially in the state its in, and with the history of building it behind the scenes without getting the Falco community involved.
The CNCF has tried to globalize other resources like the Cloud Native Landscape and I don't think the landscape is useful at its current size.
I worry that we would lose security curation - which was the original goal of the Falco community supporting rules.
But again - we can always revisit once the Artifact hub is further along. I just tried to create a helm chart and created an account there and it's still very new. Also it looks like charts need approval and I am unsure who has the power to do that - and that is also a concern for me as well.
Also it looks like there is a Falco logo on the artifact hub site? Granted it's apache2 licensed in our branding guidelines anyone could use - still seems worrisome.
Hi. First, I want to suggest that the Cloud Native Security Hub should not consider going away until the ArtifactHub is ready. That is if you decide to go that route. I would not ask for anything to happen prematurely. You can define what ready is and work with the Artifact Hub folks on it. Though, you may desire to take a wait and see approach with the Artifact Hub.
With that preamble. Here's what I wrote to the mailing list to add some context...
We want to see Falco configurations being easily discoverable in the Artifact Hub right alongside other things. Imagine someone searches for PostgreSQL and they find a Helm chart, an operator, and Falco configuration all right in one place. That's the idea.
For those not familiar, the Artifact Hub is trying to make discovery of cloud native artifacts (e.g., operators, helm charts, falco configuration, opa policies) easier. It's a centralized metadata search of information from multiple projects. Unlike the Docker Hub, the Artifact Hub does not host the artifacts themselves. Open source projects and vendors still host the artifacts in a distributed manner. The Artifact Hub provides a means to capture metadata from these distributed locations so they can be searched. Both a web UI and search APIs are provided.
Personally, I would be interested hearing feedback on how the Artifact Hub can help to serve the Falco community. That is in the form of features and UX.
Yesterday I voted for option
Keep the Cloud Native Security hub as is and continue with our existing plans, we can always revisit this later.
I'd like to motivate my vote and encourage others to do the same so that we can all understand what are our needs.
Here are my reasons to keep the Cloud Native Security Hub:
I think that the Security Hub and Artifact Hub must live together and be interconnected. What did I mean? Let me make some examples:
Scenario 1
Scenario 2
Suggestions I would like to give, regardless of the hub we go with:
I might have more stuff, this is what came on top of my mind right now.
Regardless of my opinions, I think that both, the Security Hub developers and Artifact Hub developers did an extremely good job at putting the respective Hubs together.
At the current moment, from a UX point of view, I find the Artifact Hub a better experience. I know that @nestorsalceda showed me a new version of the Security Hub but I can't find the link rn.
At the current moment, from a UX point of view, I find the Artifact Hub a better experience. I know that @nestorsalceda showed me a new version of the Security Hub but I can't find the link rn.
Here is the link, @fntlnz
@fntlnz I applaud the efforts of the cloud native security hub and everyone working on security. But, getting people to secure their things is a constant battle. Not enough people are security the things. Can we agree on that?
What I would really like to see, in some way, is that people look for an application to install in their cluster. This can be via an operator, Helm chart, or something else. Alongside that they discover, without extra work, a way they can do something to secure that more than the default. And, it can be done easily.
This is a different case from those who are already running Falco with security in mind. While I don't have stats on it, my circumstantial evidence says that Falco use is in the minority. I could argue that security clusters is in the minority. I wonder, how can we easily change that and expose people to ways to more easily secure the things.
My hope with the Artifact Hub and Falco configuration being listed there is that it opens Falco up to a larger audience with information in the context of the actions they are already doing.
Artifact Hub is pre-alpha. It's early and will change. Right now it doesn't do a great job exposing Falco or related projects. Ideally that would change over time.
Notice, I'm not campaigning for anyone to drop the cloud native security hub. I don't know if that will happen. I'm more campaigning for a better UX from the cloud native community to help people where they are at.
I have been thinking a lot until I decided my vote, but today I voted for keeping the Cloud Native Security Hub as is and continue with our existing plans.
These are my reasons:
I think that the most of the value about the SecurityHub is about its content. The final value comes from the security resources curation. Having a place where having some security recipes curated by security / Falco / OPA experts is the key here. Being able to enable people who doesn't have a lot of security expertise to secure by default their deployments is really awesome. I know that a 100% secure stuff is not possible, but if you are running a nginx server (by example) and just use Helm or falcoctl to give a try to a rule and deploy it is much better that having nothing.
When we created the SecurityHub we tried to think in a broader scope, not only Kubernetes related environments. Although Kubernetes is perhaps the main scenario we also have some rules for FIM or SSH connections which are more related to host level. Or even when we find a nice CVE which can be detected with Falco, we publish a rule in the SecurityHub. I'm not sure if this may fit in the ArtifactHub scope.
The next point is about more security resources. In our initial thoughts the SecurityHub would contain more resources, not only Falco rules or OPA policies. We created some drafts for considering benchmarks, like CIS Benchmark, Docker Benchmark and so on and is something that we would like to include in a future in the SecurityHub. Again, I'm not sure if this may fit in the ArtifactHub scope; some of things are Kubernetes related but others not.
And even we are still discovering other security needs. Imagine if you want to use Falco to help your organization to get a PCI or a SOC2 or other security certification. I'm not sure how this fits in ArtifactHub scope.
On the other hand, I read some suggestions in the thread that I want to consider:
Additional fetching mechanisms for recipes, not everyone uses Helm and many users (like me) will happily use something else that has the only purpose to download Falco rules.
Yes, this is something I want to improve. I want to work on them:
Freeze the API and offer a swagger documentation. All people deserves to get some benefit from this project and from the knowledge we have: https://github.com/falcosecurity/cloud-native-security-hub-backend/issues/7
I want to offer faster ways to people to try a new rule and I think we can do it with falcoctl support: https://github.com/falcosecurity/cloud-native-security-hub/issues/22
Finally @mattfarina I know you from the Helm Charts community, and you always helped me when I needed. So if I can help you to use the information we currently have in the SecurityHub I will be glad to do it. I will be happy to help you with the API or if you want to use the YAML resources or just zooming or talking about the best way to share information.
Honestly, I don't see any benefit, at the moment, in focusing and supporting any hub at all (not only the Artifact Hub).
We are still in the middle of the process of completely reshaping and reviewing the packaging of artifacts and installation methods for Falco, which our community showed to be the top priority. Falco rules are just one little piece of this process.
During past community call, we - as a community - already started discussing to deprecate various kinds of packaging/installation methods making them no more "officially" supported. In case we'll decide to go with this choice they will not disappear. Their maintenance and evolution will just be left to the community, in a broader sense. While we'll focus on the officially supported ones.
We started talking about this and agreeing about it during those calls. We'll talk again about it during tomorrow's call probably, in order to understand the benefits (if any) for Falco and its community case by case. Anyone is invited to join those calls! :)
My personal reasoning is that trying to increase discoverability and providing just another packaging method (both for Falco and/or Falco rules) will actually increase the entropy and the fragmentation of the community. It will increase the maintainability cost and complexity, not reduce it. With no visible or quantifiable benefits for the community.
Furthermore, when it comes to Artifact Hub, it is very early stage and not a sandboxed CNCF project. It mentions Falco rules without any past discussion at all about such integration with the Falco community. The correct process would be to join our community call and explain the ArtifactHub approach, pros, and cons.
Clearly, as things evolve, we discuss them as needed during our calls and, maybe, come up with different decisions.
Just read through this thread and voted for continuing with the Cloud Native Security Hub for now. I agree with a number of the reasons listed above
I like the two scenarios that @fntlnz outlined as examples of how we might move forward.
In terms of OPA, there are many more types of OPA policies besides security-centric ones (think "you must have a valid billing code label"), I think it would be sub-optimal for OPA users if they had to go to multiple places to get policies.
Unless the proposal here includes potentially providing metadata + links to other artefact repositories as well as being the source of truth for some artefacts?
I agree with several comments from Kris, Shane, Matt, Nestor, Lorenzo and others.
Some additional opinions for your consideration.
About Leo's point of view of being to soon to commit for a hub, I follow your logic, but maybe also think of people like me, that is more focused on rules that in the engine. I speak with several people very interested in writing rules for their specific needs. Having now a place to focus on this kind of work, in an orderly manner is useful and creates community. Maybe in the near future we have to rethink how this works, but let's not stop posibility of development of rules for specific purposes and a community around them.
About Craig's comment, I've been tinkering a little bit with OPA, and I understand that it has many more applications than security. Having to search at different places for different kinds of OPA rules can be a burden, sure. But security is a very important topic that can be the only focus of many people's professional work. For them, having to search at different places for different kinds of security-related rules can also be a burden.
The little I can understand about the CNCF Artifact Hub is that it will not host resources, they will be hosted in each of their own project's website. So I see it more like a search engine for other people's artifacts, where having also a Security Hub where the community and curation are done is very useful.
@nestorsalceda Thanks for the offer. We will keep that in mind.
@leodido I understand where you're coming from. I do want to respond to a few things...
It mentions Falco rules without any past discussion at all about such integration with the Falco community. The correct process would be to join our community call and explain the ArtifactHub approach, pros, and cons.
I'm sorry we didn't do a great job of that before. A couple weeks ago there was a meeting the day prior to the TOC call on the hub where I had thought the agenda was to present all of this to the Falco community. And, I had emailed Kris about this back at the start of January before any code development had started.
Once the meeting the day before the TOC call had not gone in a direction of presenting to the Falco community I planned on going to an upcoming Falco meeting and presented yesterday.
Again, my apologies this didn't start off on the best note.
My personal reasoning is that trying to increase discoverability and providing just another packaging method (both for Falco and/or Falco rules) will actually increase the entropy and the fragmentation of the community. It will increase the maintainability cost and complexity, not reduce it. With no visible or quantifiable benefits for the community.
If someone wants to have "fun in 5 minutes" with Falco how will they go about it? By that I mean, if an end user wants to accomplish a task relevant to them in 5 minutes what will that look like? For example, to install Falco and security PostgreSQL using rules.
I'm curious to understand the story of how this works or what you want to the experience to be to better imagine how to get there and where a hub might fit.
Closing the issue as it looks like the community clearly has a trend towards keeping the security hub as is.
If an end-user wants to have "fun with falco" in 5 minutes they can start by installing Falco and getting involved with the community, which takes significantly less time than nitpicking the maintainers on Github.
If the artifact hub want's to continue to scrape Falco rules, please at least respect the wishes of our community and label them as unofficial.
Hey all,
(trying to keep this as neutral and informative as possible, I will share my opinions in comments below)
On last week's call we brought up the various Hub work happening both in the Falco community and in the CNCF and we have talked about it in slack as well in a few different slack organizations.
Last week I mentioned that we were in a place where we need to start making decisions as a community on what we wanted to SUPPORT as a project. The concept of support means that we (The Falco Community) will take ownership of supporting these artifacts over time.
So I wanted to get a quick show of hands - as well as any thoughts on why you show support the way you did.
Note: this isn't an official vote/poll - this is just a way to see if there is a trend in the community.
Ultimately this decision on what we do is up to the Falco community and our end-users. If there isn't a clear winner we might end up putting together a formal vote where active contributors and known end-users can vote.
So it looks like there are a few possibilities for the end game here stay the same or migrate now.
This is a "right now" style answer (30 days or so), and we can re-open this at some point in the future as many times as needed. There is a difference between no and not today.
Please answer the question: Which hubs should the Falco community support for the time being?
Keep the cloud native hub as is
We already have done a lot of work with the cloud-native hub, and we could "double-down" on the work to make the hub even better.
Migrate to the new Artifact hub project
Showing support
Please only respond once. Please :+1: on the issue you agree with by using the comments below :point_down:
If you would like to add another option please add it as a comment, and we can follow the same parlance of :+1: showing support
Please add any supporting statements below as well.