search

kubernetes-sigs / kubebuilder

Kubebuilder - SDK for building Kubernetes APIs using CRDs
http://book.kubebuilder.io
Apache License 2.0
7.77k stars 1.43k forks source link

Analysis and Compliance Strategy for New Cyber Resilience Act #3712

Open camilamacedo86 opened 9 months ago

camilamacedo86 commented 9 months ago

Issue Description:

We need to conduct a thorough analysis of the new Cyber Resilience Act to understand its implications for the Kubebuilder project, particularly in terms of our release process, tooling, and dependencies. We probably need to start to generate the SBOOMs. Also, note that today we use GCP to perform the builds and we have a desire to use only GitHub Actions to do so and no longer need to use GCP.

Areas of Focus:

  1. Current Release Process:

    • Currently, our releases are managed via GCP and build triggers.
    • We utilize goreleaser for automating releases, triggered by pushing a new tag.
    • Relevant documentation: Release Process and Goreleaser Configuration.

  2. Kubebuilder Tools:

  3. Kube-RBAC-Proxy:

    • Currently, we are handling the retagging of kube-rbac-proxy.
    • This project has been in a process of being donated to kubernetes-sig for a long time
    • Also, it has breaking changes, which might make it very hard for us keep its usage in the default scaffold and that is something that we must reconsider see; https://github.com/kubernetes-sigs/kubebuilder/issues/3524#issuecomment-1809793221
    • Considering delegating this responsibility to the project itself and re-evaluating its use in default scaffolding due to recent breaking changes.

Objectives:

  1. Create a Proposal Design Document:

    • Utilizing the Design Doc Template, we need to document how the new legislation affects our project and outline necessary compliance measures.
    • This document should serve as the foundation for understanding our obligations and planning our response.

  2. Develop Compliance Strategies:

    • Based on the analysis, we need to propose solutions and modifications to our processes and tools to ensure compliance with the new legislation.

Objectives:

  1. Create a Proposal Design Document:

    • Utilizing the Design Doc Template, we need to document how the new legislation affects our project and outline necessary compliance measures.
    • This document should serve as the foundation for understanding our obligations and planning our response.

  2. Develop Compliance Strategies:

    • Based on the analysis, we need to propose solutions and modifications to our processes and tools to ensure compliance with the new legislation.

Call to Action:

We invite contributors to participate in this analysis and help develop a comprehensive strategy for compliance. Your insights and expertise in our current processes, tooling, and dependencies will be invaluable in navigating these new requirements.

Reproducing this issue

No response

KubeBuilder (CLI) Version

master

PROJECT version

No response

Plugin versions

No response

Other versions

No response

Extra Labels

No response

camilamacedo86 commented 9 months ago

@varshaprasad96 @Kavinjsir @everettraven @rashmigottipati

varshaprasad96 commented 9 months ago

Hi @camilamacedo86, thanks for brining this to attention. I took a dig at the Cyber Resilience Act and some of the implications it may have. A few thoughts on this:

  1. Looks like the CRA is in the draft stage, and the current specifications are based on the initial draft published in September. The Act, if passed by EU would take effect in 2024 (end) - 2025: https://www.fmapprovals.com/product-alerts-and-news-events/Insights/eu-cyber-resilience-act
  2. Kubebuilder - should be coming under non-critical project based on the criteria they have mentioned - but it would be nice if we can wait for the steps k8s takes as a whole. I hope there would be some guidance from their end.
  3. Based on the article - looks like we fall in the second category (as specified under "Are you covered by the CRA?" section) - where we follow a de-centralized community driven model, where not just one company develops the software. Some of the requirements may probably change for us, given we can't explicitly evaluate how/where our consumers use the product. We may probably have to wait out to see how things turn out before taking an action.
everettraven commented 9 months ago

I also took a look at the shared article and I 100% agree with the breakdown @varshaprasad96 shared. My inclination is that we would be classified as a non-critical project based (since we are a dev tool for streamlining the building of software) on the information provided. I agree with waiting for more guidance from the Kubernetes orgs or CNCF as a whole before making any commitments.