logging-operator

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 7941 ist gold So können Sie ihn einbetten:

Dies sind die Kriterien das Level Gold. Sie können auch die Kriterien für die Level Passing oder Silber sehen.

        

 Grundlagen 5/5

  • Identifizierung

    Logging operator for Kubernetes

  • Voraussetzungen


    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]

    Everyone from the maintainers are entirely familiar with the project: https://github.com/kube-logging/.github/blob/main/MAINTAINERS.md, among other contributors who are frequently contributing. Also there is a company (Axoflow) who provides commerical support for this project.



    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [contributors_unassociated]

    We have more than two unassociated contrbutors: https://github.com/kube-logging/logging-operator/graphs/contributors


  • Andere


    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

    This is implemented and checked in CI runs, with the help of Licensei.


  • Öffentliches Versionskontroll-Source-Repository


    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.



    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [small_tasks]

    We use Github labels: "Good first issue" to signify that an issue is suitable for new or casual contributors.

    see also:



    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [require_2FA]

    We do require 2FA enabled for developers.



    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]

    The project enforces using a TOTP app.


  • Programmierstil


    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]

    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [two_person_review]

    All maintainers are asked for reviews all the time, if a proposed modification is a major one, then 2-3 person must review it!


  • Produktivsystem


    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [build_reproducible]

    Our operator implements a reproducible build process using Go modules with go.mod and go.sum files that lock all dependency versions. Our CI pipeline verifies reproducibility by comparing hashes of builds from different environments. All build configuration is committed to the repository.

    See: https://github.com/kube-logging/logging-operator/blob/master/.github/workflows/artifacts.yaml


  • Automatisierte Test-Suite


    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]

    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [test_continuous_integration]

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [test_statement_coverage90]

    Our total e2e test coverage is above: 75% with additional unit and shell-based tests. In total the project is most probably well above 90% coverage.



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [test_branch_coverage80]

    Our total e2e test coverage is above: 75% with additional unit and shell-based tests. In total the project is most probably well above 80% coverage.


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Die vom Projekt produzierte Software MUSS sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 MÜSSEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    All network communications in our operator use secure protocols. We utilize the Kubernetes API which requires TLS, and any external communications implement TLS 1.2+. No insecure protocols are enabled by default. (Only for development purposes!)



    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    Our operator exclusively uses TLS 1.2+ for all secure communications. We enforce this minimum version through our client configurations when making external API calls.


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [hardened_site]

    The GitHub repository implement security headers including strict Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Strict-Transport-Security with long max-age, and Referrer-Policy: strict-origin. URL: https://github.com/kube-logging/logging-operator


  • Andere Sicherheitsissues


    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [security_review]

    Security is #1 priority for us, meaning that we regularly do security review on our project.



    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [hardening]

    There are several hardening mechanisms implemented, on various layers of the project:

    Input validation: All inputs are validated, especially those from external sources Least privilege: The operator runs with minimal required permissions and by default it uses the least required Kubernetes RBAC. Secure defaults: We provide sensible and secure default settings, especially in cases when the user would use a potentially risky feature. Resource constraints: Resource limits are set for all types of deployments.

    There is not a single URL we can paste here, since this is implemented in various layers of the project: https://github.com/kube-logging/logging-operator


  • Dynamische Codeanalyse


    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]

    End-to-end tests are running against each PR that tests the software using various inputs dynamically.



    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [dynamic_analysis_enable_assertions]

    Our operator includes extensive runtime assertions through Go's built-in mechanisms. We use require and assert functions in tests, implement error checking in all critical code paths, and leverage Go's panic/recover for unexpected conditions.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Márk Sági-Kazár and the OpenSSF Best Practices badge contributors.

Projekt-Badge-Eintrag im Besitz von: Márk Sági-Kazár.
Eintrag erstellt: 2023-10-10 11:47:44 UTC, zuletzt aktualisiert: 2025-03-18 09:39:31 UTC. Letztes erreichtes Badge: 2023-12-06 15:10:07 UTC.

Zurück