遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/7941)
<a href="https://www.bestpractices.dev/projects/7941"><img src="https://www.bestpractices.dev/projects/7941/badge"></a>
Logging operator for Kubernetes
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.
We have more than two unassociated contrbutors: https://github.com/kube-logging/logging-operator/graphs/contributors
This is implemented and checked in CI runs, with the help of Licensei.
Repository on GitHub, which uses git. git is distributed.
We use Github labels: "Good first issue" to signify that an issue is suitable for new or casual contributors.
see also:
We do require 2FA enabled for developers.
The project enforces using a TOTP app.
See:
All maintainers are asked for reviews all the time, if a proposed modification is a major one, then 2-3 person must review it!
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
See: https://github.com/kube-logging/logging-operator/blob/master/CONTRIBUTING.md
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.
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.
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!)
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.
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
Security is #1 priority for us, meaning that we regularly do security review on our project.
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
End-to-end tests are running against each PR that tests the software using various inputs dynamically.
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.
后退