Gardener

Gardener versions policy is described here: https://github.com/gardener/gardener/blob/master/docs/deployment/version_skew_policy.md Every Gardener release (project result) contains release notes providing further information on the upgrade path: https://github.com/gardener/gardener/releases

Issues are tracked as GitHub issues for all Gardener repositories in the Gardener GitHub organization, e.g. https://github.com/gardener/gardener/issues, https://github.com/gardener/dashboard/issues , https://github.com/gardener/gardenctl/issues, ...

example: https://groups.google.com/forum/#!topic/gardener/Pom2Y70cDpw

https://github.com/gardener/documentation/blob/master/security-release-process.md#disclosures

Relevant coding style guidelines are mentioned here: https://gardener.cloud/docs/contribute/#contributing Formatting guidelines for Gardener documentation: https://gardener.cloud/docs/contribute/20_documentation/20_formatting_guide/ Style guidelines for Gardener documentation: https://gardener.cloud/docs/contribute/20_documentation/40_style_guide/

Gardener project enforces coding styles if possible, e.g. via linting in GoLang, see https://github.com/gardener/gardener/blob/master/.golangci.yaml

Gardener uses Go build running in multi stage docker build, see: https://github.com/gardener/gardener/blob/master/Dockerfile

Gardener uses Go build running in multi stage docker build, see: https://github.com/gardener/gardener/blob/master/Dockerfile

the Gardener components are built independent from each other into separate container images

The Gardener project is not able to repeat the process of generating information from source files and get exactly the same bit-for-bit result. But we are able to reproduce semantically equivalent results: We have dependencies in source tree, we do not modify our container images after release, we tag the source state with a GitHub release

An easy way to install Gardener for the purpose of "having a look into it" is described at https://github.com/gardener/garden-setup . Further deployment documentation can be found at https://github.com/gardener/gardener/blob/master/docs/README.md#deployment .

Gardener project results are following the OCI image specification.

Guidance for potential developers to get started contributing to the project can be found here - https://github.com/gardener/gardener/blob/master/docs/README.md#development

External dependencies can be found and processed (yaml) for each Gardener release (release asset called component descriptor) e.g. https://github.com/gardener/gardener/releases/latest/download/github.com_gardener_gardener.component_descriptor.cnudie.yaml

The Gardener project leverages Black Duck Binary Analysis fka Protecode to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable

Gardener provides a mechanism to auto update the Kubernetes version and the underlying host OS version

Gardener Project is quite depending on Kubernetes, the support Kubernetes versions are described here: https://github.com/gardener/gardener/blob/master/docs/usage/supported_k8s_versions.md .

Other OSS dependencies are regularly assessed.

Gardener project defines the testing strategy and guideline here - https://gardener.cloud/docs/gardener/development/testing/ . The project relies on GitHub automation for testing and produces test reports accordingly.

regression test are only added to an automated test suite when it is necessary or when the bugs are security related.

https://github.com/gardener/documentation/blob/master/CONTRIBUTING.md#pull-request-checklist

https://github.com/gardener/documentation/blob/master/CONTRIBUTING.md#pull-request-checklist

There is evidence that the Gardener project is striving to enable warning flags where it can, so that errors are detected early. Example: a shoot resource definition cannot be uploaded when it contains an error.

The Gardener architecture itself https://gardener.cloud/docs/gardener/concepts/architecture/ is an implementation of secure design principles like introducing additional trust boundaries

Gardener project ensures wanted and acceptable cipher suites, for example see https://github.com/gardener/gardener/blob/master/pkg/utils/kubernetes/tls_cipher_suites.go

https://github.com/gardener/gardener/pull/428/files

Gardener project relies on standard Kubernetes means (secrets), see https://kubernetes.io/docs/concepts/configuration/secret/

Gardener project relies on standard Kubernetes means, all API communication in the cluster is encrypted by default with TLS, see https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#use-transport-layer-security-tls-for-all-api-traffic

Gardener supports at least TLS version 1.2

In Gardener project, the certificate management and verification is documented and implemented here - https://github.com/gardener/cert-management

In Gardener project, the certificate management and verification is documented and implemented here - https://github.com/gardener/cert-management

each container image contains cryptographically hashes, following the OCI spec https://github.com/opencontainers/image-spec#oci-image-format-specification

Gardener is entirely API-driven and extends the K8s API concepts. All API clients must be authenticated and every API call is expected to pass an authorization check. Consequently, the Gardener API server is secured against untrusted sources.

Gardener has introduced several network policies and did according community communication https://groups.google.com/forum/#!topic/gardener/Pom2Y70cDpw

Gardener complies with DISA STIGs for Kubernetes. For every release we check that Gardener is able of creating a hardened shoot reconfirming that the configurations which are not secure by default (as per https://gardener.cloud/docs/guides/security-and-compliance/kubernetes-hardening/) are still possible and work as expected.

Gardener leverages CheckMarx

the project does not produce software written in a memory-unsafe language (Go)