遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/5947)
<a href="https://www.bestpractices.dev/projects/5947"><img src="https://www.bestpractices.dev/projects/5947/badge"></a>
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
https://external-secrets.io/contributing-process/
We have implemented a DCO as part of our CI. You can view ANY PR, it is present as a GitHub Actions status. See PR template checklist [1].
[1] https://github.com/external-secrets/external-secrets/blob/main/.github/pull_request_template.md
https://github.com/external-secrets/external-secrets/blob/main/GOVERNANCE.md
https://external-secrets.io/latest/contributing/coc/
https://github.com/external-secrets/external-secrets/blob/main/MAINTAINERS.md
external-secrets is part of the CNCF and thus the GitHub Organisation is owned by the CNCF, including the DNS records. https://github.com/external-secrets?view_as=public
This is fluctuating. See currently active maintainers http://github.com/external-secrets/external-secrets. At the moment we are about ~4-6 active maintainers
https://external-secrets.io/latest/contributing/roadmap/
https://external-secrets.io/latest/api/components/
https://external-secrets.io/latest/guides/security-best-practices/ https://external-secrets.io/latest/guides/multi-tenancy/ https://external-secrets.io/latest/guides/threat-model/
https://external-secrets.io/latest/introduction/getting-started/
Our docs are versioned (version dropdown at the top of the page) https://external-secrets.io/
http://github.com/external-secrets/external-secrets
We use mkdocs to generate our docs [1] and use GitHub to collaborate [2]. Both have accessibility as a priority in their product philosophy.
[1] https://github.com/squidfunk/mkdocs-material/blob/44982451f7759ed65e31d1151b3c49566b8c6ca0/docs/philosophy.md?plain=1#L29-L31 https://accessibility.github.com/conformance/github-com/
It is only available in english at the moment, we do not have capacity to i18n the documentation at this point, we don't have the capacity to implement it at this point.
https://external-secrets.io/latest/
We as the project don't store passwords, we're relying on GitHub to securely do it.
We support older versions to an extend, see docs:
\https://external-secrets.io/latest/introduction/deprecation-policy/ https://external-secrets.io/latest/introduction/stability-support/
We use GitHub to track issues.
See our security policy:
https://github.com/external-secrets/external-secrets/blob/main/SECURITY.md
https://github.com/external-secrets/external-secrets/blob/d1161379f14b1d701bca4bf3b9e614dd07e3e227/SECURITY_RESPONSE.md
We use the golang ecosystem and have checks for lint/fmt etc.
https://github.com/external-secrets/external-secrets/blob/00249f1d436c97fced336d04e90e6368d0fb5a60/Makefile#L75-L77
https://pkg.go.dev/cmd/go#hdr-Environment_variables https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies
go toolchain is able to preserve debug flags where needed.
the go compiler errors out on circular dependencies
dependencies are pinned and we have a lock file.
helm or kubectl/kustomize can be used to install the software
covered via helm or kubectl/kustomize installation method.
https://external-secrets.io/latest/contributing/devguide/
https://github.com/external-secrets/external-secrets/blob/00249f1d436c97fced336d04e90e6368d0fb5a60/go.mod
met via container image scanning, snyk and dependabot.
our software is packaged in a container and updates are easy to ship
Not sure how this is applicable to us
https://github.com/external-secrets/external-secrets/blob/00249f1d436c97fced336d04e90e6368d0fb5a60/.github/workflows/ci.yml
We add regession tests for every bugfix.
We have a test coverage of ~60% https://app.codecov.io/gh/external-secrets/external-secrets/tree/main
We have a proposal process for new major functionality. It is part of the proposal to review the acceptance criteria.
https://external-secrets.io/latest/contributing/process/#proposal-process
We have a strict linter suite and enforce that tests pass. https://github.com/external-secrets/external-secrets/blob/00249f1d436c97fced336d04e90e6368d0fb5a60/.golangci.yaml
We follow the Kubernetes multi-tenancy design to isolate tenants by using namespaces and the user relies on Kubernetes RBAC to interface with external-secrets.
https://external-secrets.io/latest/guides/multi-tenancy/
This is covered by our security scanning tools.
Users can choose their own algorithms when managing X.509 certificates. Users can specify TLS ciphers which are used on the webhook component.
secrets are read from file, env or accessed through an API.
We support HTTPS for all meaningful connections. The only exception is the /metrics endpoint which is read-only and presents telemetry data of a component.
We allow users to specify the tls version in the webhook which defaults to tls 1.2.
We verify certificates. There are some providers which allow disabling TLS verification, the user must opt-in to use it.
this is covered by the go runtime
https://external-secrets.io/latest/guides/security-best-practices/#verifying-provenance
We validate user input, however this is a shared responsibility with the admin team which installs our software.
We've hardened the Kubernetes pods using the NSA kubernetes hardening guide
https://external-secrets.io/latest/guides/threat-model/ https://external-secrets.io/latest/guides/security-best-practices/
We use SNYK to do analysis
golang is a memory-safe language (as long as CGO isn't used)
后退