☁️ CryptOS and the CNCF
CryptOS is preparing an application to the Cloud Native Computing Foundation (CNCF) Sandbox. It is not a CNCF project. This page says how CryptOS fits cloud native infrastructure today, which CNCF conventions the project already follows, and how to take part.
How CryptOS fits cloud native
A Kubernetes cluster uses a lot of certificates: ingress certificates for every hostname, certificates for webhooks and controllers, and mTLS between services. In Kubernetes that job usually goes to cert-manager, which asks a CA for certificates and renews them before they expire. A CryptOS node is that CA, with its signing key sealed in the node's TPM.
What works in this release:
- Workload certificates by CSR. Make the key and CSR, issue with
cryptosctl ca issue-leafor the FleetOS Manager, and load the result into a Kubernetes TLS Secret yourself. Renewal is manual. See Internal TLS and mTLS. - cert-manager over ACME. An intermediate or issuing node serves ACME (RFC 8555) with the
http-01challenge once you add thepki.acmeblock to its machine config and reboot it. There is nodns-01and no wildcard names, and cert-manager's default RSA 2048 key is refused. See Kubernetes workloads for what to set. - A CA for the cluster.
cryptosctl ca sign-subordinatecan sign a CA certificate for cert-manager's own CA issuer, so its certificates chain to your CryptOS root. The signing step is the one proven with vCenter's VMCA; it has not been tested with cert-manager. - The FleetOS Manager in a cluster. The FleetOS Manager runs in Kubernetes from the chart in the
cryptos-managerrepo. Each release publishes the image,ghcr.io/cryptos-pki/cryptos-manager(forlinux/amd64andlinux/arm64fromv0.1.0-rc.2), and the chart,oci://ghcr.io/cryptos-pki/charts/fleet-manager. You can also build the image yourself. See Deploy with Helm.
CryptOS does not act as the external CA for the cluster's own PKI: the API server, etcd, kubelet and front-proxy certificates that Kubernetes creates for itself.
CNCF conventions the project follows
These apply across the CryptOS-PKI organization.
| Convention | What CryptOS does | Where it lives |
|---|---|---|
| Apache License 2.0 | Every repo is licensed under the Apache License 2.0, and its LICENSE file is the text exactly as the Apache Software Foundation publishes it. | License |
| Developer Certificate of Origin | Contributions are taken under the DCO, version 1.1, instead of a contributor license agreement. Contributors sign off every commit with git commit -s. | CONTRIBUTING.md |
| CNCF Code of Conduct | The organization-wide code of conduct is the CNCF Community Code of Conduct, version 1.3. Because CryptOS is not a CNCF project, reports go to the project's maintainers. | CODE_OF_CONDUCT.md |
| Security policy | Vulnerabilities are reported privately to the maintainers, never in a public issue, pull request or discussion. Before 1.0.0, only the latest 0.x release of each repo gets security fixes. | SECURITY.md |
Licenses inside the OS image
The CryptOS code is Apache 2.0, but a CryptOS image contains more than CryptOS code.
A CryptOS image built from cryptos includes third-party components built from their own sources, and they keep their own licenses. The Linux kernel and the disk tools (cryptsetup, e2fsprogs, gptfdisk and dosfstools) are under the GNU GPL. Some libraries linked into those tools, such as glibc, and the systemd EFI stub that boots the image are under the GNU LGPL. See License for what the license checks cover.
Get involved
The code and the source of this site are public on GitHub in the CryptOS-PKI organization. Every repo is open to the public today: anyone can open an issue or a pull request, or leave a comment. See The repos for what each repo holds.
A change starts as an issue from one of the repo's templates, and every commit in a pull request is signed off. CONTRIBUTING.md has the whole workflow. Security problems are never reported in public; follow SECURITY.md instead.
The CNCF Sandbox application is still waiting; the project is not a CNCF project yet.