logging-operator

Since the beginning of the project, it uses the same version maintain rules, that are followed by Kubernetes: https://kubernetes.io/releases/ The most recent three minor releases are maintained.

https://github.com/kube-logging/logging-operator/issues

We have never received a security vulnerability report before.

We take security vulnerabilities very seriously, more about it can be read in here: https://github.com/kube-logging/logging-operator/blob/master/CONTRIBUTING.md

See:

• https://github.com/kube-logging/logging-operator/blob/master/CONTRIBUTING.md
• https://github.com/kube-logging/.github/blob/main/SECURITY.md

See: https://github.com/kube-logging/.github/blob/main/CONTRIBUTING.md

The project uses golangci-lint, that is ran in CI on pull-requests.

The GO_BUILD_FLAGS environment variable is available to set, and it is honored.

Debugging can be enable by setting the right flag(s): https://kube-logging.dev/docs/install/#arguments

The project is written in Go. Go's build system is non-recursive by default and automatically resolves dependencies correctly regardless of directory layout. It builds packages based on their import dependencies, ensuring that cross-dependent code is built in the proper order. This approach prevents the issues that can arise from recursive building of subdirectories with cross-dependencies.

We ensure reproducibility by specifying our Go version in go.mod and using checksummed dependencies through go.mod/go.sum. All build processes use the -trimpath flag to remove local file paths from the binary, and we avoid embedding timestamps or system-specific information that could change between builds.

See: https://kube-logging.dev/docs/install/

The project is distributed as a Docker image, which is also embedded into a Helm-chart, which can be used to deploy it to a Kubernetes cluster, in a namespace, defined by the user.

The project is distributed as a Docker image, which is also embedded into a Helm-chart, which can be used to deploy it to a Kubernetes cluster conveniently. Also for development and testing purposes, we use conventional tools used in the Kubernetes ecosystem. This is collected in the Makefile of the project.

Since this is a Go project, external dependencies can be found in the projects go.mod file: https://github.com/kube-logging/logging-operator/blob/master/go.mod

We use Github Actions to periodically check on pull-requests, merges, releases. The container image we publish is scanned by trivy, go.mod dependencies are checked with snyk. (Both offers a way to check and resolve or mark vulnerabilities.)

This project uses the standard Go dependency management system via go.mod and go.sum files to track all external dependencies.

We avoid depending on deprecated/obsolete functions.

We use Github Actions to run unit and e2e tests, both creating a test report.

When regressions occur, we add tests for them.

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.

We require new tests for new functionalities according to our contributing guide:

https://github.com/kube-logging/.github/blob/main/CONTRIBUTING.md

See: https://github.com/kube-logging/logging-operator/blob/master/CONTRIBUTING.md

The settings for the warning tools are generally fairly strict.

See: https://github.com/kube-logging/.github/blob/main/SECURITY.md

Our operator doesn't implement custom cryptography and relies on Go's standard crypto libraries which avoid algorithms with known weaknesses like SHA-1 and CBC mode. We use SHA-256 for hashing and AES-GCM for any encryption needs.

Our K8s operator doesn't implement cryptographic operations directly but relies on Kubernetes' built-in mechanisms. We don't need to support multiple algorithms as we don't perform crypto operations ourselves.

All authentication credentials used by our operator are stored in Kubernetes secrets, which are separate from operator code and configuration. Users can update these without requiring operator recompilation.

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.

TLS certificate verification is enabled by default for all API communications. We use the standard Go TLS configuration which performs proper certificate validation.

Our operator verifies TLS certificates before sending any private information.

We use cosign to sign our images and helm-charts during it's release process. The signing and verification is documented in: https://kube-logging.dev/docs/install/#verify

We use cosign to sign our images and helm-charts during it's release process. The signing and verification is documented in: https://kube-logging.dev/docs/install/#verify

All inputs from potentially untrusted sources are checked & rejected if they are invalid.

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

See: https://github.com/kube-logging/.github/blob/main/SECURITY.md

The project uses golangci-lint for static analysis.

The project was written in Go.