Metal3 (Metal Kubed)

We have 16 active repositories under https://github.com/metal3-io

We enforce use of Github Pull Requests for all changes.

All changes are available in Github.

Github is used.

We use semantic versioning, see supported versions: https://book.metal3.io/version_support

Releases are created from Git tags.

Curated changelogs are generated from included PRs. Example: CAPM3 https://github.com/metal3-io/cluster-api-provider-metal3/releases/tag/v1.7.0

We request CVEs for vulnerabilities and publish them in release notes. Example: Ironic-image https://github.com/metal3-io/ironic-image/releases/tag/v24.1.1

We use GH issues for bug reports and feature requests, with appropriate templates for each. Example: CAPM3 issues https://github.com/metal3-io/cluster-api-provider-metal3/issues

We use GH issues for bug reports and feature requests.

All incoming issues are triaged every two weeks in community meeting at latest, often discussed before that as well.

All incoming issues are triaged every two weeks in community meeting at latest, often discussed before that as well.

We use Github issues. https://github.com/issues?q=archived%3Afalse+user%3Ametal3-io+is%3Aissue+sort%3Acreated-asc

We have security policy in every repo and in website: https://book.metal3.io/security_policy

The disclosures are sent to private security team mailing list for review. https://book.metal3.io/security_policy

All vulnerability disclosures have been answered within 14 days, usually the next working day at the latest.

We have makefiles for building the software, which usually is Go binaries inserted into Docker images. This makefile is then utilized by CI and release processes alike, across Jenkins and GH workflows. Example: CAPM3 https://github.com/metal3-io/cluster-api-provider-metal3/blob/main/Makefile

Make and Docker/Podman are the key tools.

All tools used are FLOSS. Our development environment is building host and node on top of vanilla Ubuntu and Centos images, and our Dockerimages are mainly based on official Golang Docker images.

https://github.com/metal3-io/metal3-dev-env

Our test suite contains repository level tests and Metal3 level e2e tests via development environment: https://github.com/metal3-io/metal3-dev-env

Tests are run in standard way per language. Example: CAPM3 https://github.com/metal3-io/cluster-api-provider-metal3/blob/db5d18f1b6e99e52189b2c0d136f8894acc9d67a/Makefile#L243

Our test suite contains repository level tests from spellchecks to shellchecks to unit tests to Metal3 e2e tests.

We use k8s Prow for managing CI, which consists of all levels of tests as requirement to merging changes. Prow, GH workflows and e2e in Jenkins, with various level of testing (integration, real hardware, features, etc)

https://prow.apps.test.metal3.io/

This is agreed and enforced by reviewers, but it is not written down. It will be fixed in future.

Major functionality has its own suites even, and all PRs are required to be passing e2e suite.

We use golangci-lint, yamllint, markdownlint, shellcheck, dead link checkers etc linters as needed per repository and per language.

PR cannot be merged if linter complaints, so all warnings are either fixed or marked as false positives.

We have most of the linters set to maximum strictness, and only line by line disable as necessary. The disabled checks are not common and were working on getting rid of each of them.

We have dedicated Security Lead (tuminoid).

We have dedicated Security Lead (tuminoid).

We are using standard cryptographic libraries and algorithms from the Go and Python ecosystems and as supported by the included FLOSS dependencies, and harden them by configuration to the best practices as applicable. Example: CAPM3 detects if user tries to use insecure TLS ciphers: https://github.com/metal3-io/cluster-api-provider-metal3/blob/ab5731dafddd999f7f3ac42051573228d6c8a4ec/main.go#L509

We do not roll our own crypto.

We are using only FLOSS.

We are using at minimum SHA256 with exception of MD5 as deprecated, to-be-removed hash, and RSA 2048 bits.

We have deprecated support for MD5 for image checksums, that is to be removed soon after deprecation period passes.

No such algorithm is used.

We are using TLS 1.3 by default (TLS 1.2 can be allowed only via configuration flag) and utilizing the hardened PFS protocols where possible.

Passwords in Metal3 Ironic are Bcrypted for internal component communication. Users do not have usernames or passwords.

We only generate passwords and keys in CI, in production users supply the keys.

HTTPS is enabled by default everywhere.

We download all dependencies via https, and pin them with actual binary hashes or sha1sums downloaded via https.

There are no publicly or privately known vulnerablities open.

No critical vulnerabilities have been reported to the project, and if vulnerability is external via dependencies, they are fixed immediately by bots or by security team, and patch release is coordinated shortly after.

We do not have private keys or non-generated passwords in the repositories. We will implement code secrets scanning in future, in addition to Github doing code secrets scanning automatically for us.

golangci-lint is used for all go, shellcheck for all Bash, etc.

golangci-lint is configured with gosec and other security linter modules.

All vulnerabilities are fixed in timely way after being found, regardless of the source of the finding. No PR that has vulnerability will be merged.

All applicable linters and static code analysis tools run on each PR and must pass before merging is allowed.

Only Go and Python are used, which both are memory safe.