Aleksei Sviridkin
3fe3028fa6
## What this PR does
#3797 added `talos.imageFactoryCA`, so a pool's CDI import can verify a
self-hosted Image Factory served by an internal CA.
`hack/proxmox-talos-template.sh` (#4742) downloads the same image with
curl on the Proxmox node. curl there trusts only the system store, so
with that kind of factory it fails with `curl: (60) SSL certificate
problem: unable to get local issuer certificate`, which is exactly the
setup #3797 was written for.
`COZY_TALOS_FACTORY_CA` names a PEM file that holds those certificates,
the same blocks a pool puts in `talos.imageFactoryCA`. The program
writes the node's system bundle into its scratch directory, appends the
certificates after it, and passes the result to `curl --cacert`. They
are therefore trusted on top of the system store, the same way CDI
appends them to its pool, and a redirect to a publicly trusted host
still verifies. Nothing is installed into the node's own trust store.
The certificates are pasted into the program that runs as root on the
hypervisor, so the file is held to the rule
`cozy-lib.tls.validateCACert` applies to the chart value: it must
contain complete certificate blocks and nothing else. The script refuses
a file with a private key alongside the certificates, with trailing
text, or with an unclosed block, and it does so before printing
anything. It also refuses a CA given for a plain-http factory. On the
same principle, curl gets `--proto-redir =https` whenever a CA is set,
so a redirect cannot take the download off verified TLS halfway. Without
the variable, the program is byte-for-byte what it was.
Follows #3797 and #4742.
### Testing
- `bats hack/proxmox-talos-template_test.bats` (Bats 1.14.0) passes
15/15. Three tests are new: the program without a CA is unchanged; with
a CA, curl receives `--proto-redir =https` and the system bundle
followed by the certificates, and CRLF line endings are stripped;
malformed files and a CA for an http factory are refused. The new tests
go red against the script from #4742, against a validator that accepts
any line, and against a bundle that leaves out the system store.
- The same file passes 15/15 under mawk and under busybox awk.
- `bats-strict-setup`, `bats-no-negated-assert` and `bats-no-exit-trap`
are clean, and so is `shellcheck -s sh`.
- The bundle the program writes was checked against a local `openssl
s_server` with a certificate from a throwaway CA: curl verifies with the
bundle and fails with `(60)` without it.
- Against a local HTTPS server that redirects to http, curl follows the
redirect without the flag and stops with `(1) Protocol "http" not
supported or disabled` with it.
- Re-run after the rebase onto main 11b19635e, with #4742 merged: the
bats file is 15/15 under Bats 1.14.0, mawk and busybox awk, the three
Bats audits pass, `shellcheck -s sh` is clean and
`hack/check-commit-trailers.sh` passes.
- Run live on a Proxmox VE 9.2 node (curl 8.14.1) against a stand-in
factory: an HTTPS server with a certificate from a throwaway CA, reached
from the node through an ssh tunnel, given as `COZY_TALOS_FACTORY_URL`
with `COZY_TALOS_FACTORY_CA` naming that CA. Each run used a test VMID
and tags no pool selects, and the template was destroyed afterwards.
- Without the CA, the program stops at curl with `(60)` before `qm
create`.
- With the CA and a factory that redirects to http, curl stops with `(1)
Protocol "http" disabled (in redirect)`, again before `qm create`.
- With the CA and a factory that serves the image itself, the template
is built (76 s): `agent: enabled=1`, `template: 1`, the given tags.
- With the CA and a factory that redirects to
`https://factory.talos.dev`, the template is built (53 s), so the system
store is still trusted after the redirect.
- Neither a CA file with a private key appended nor a CA for an http
factory gets past the local checks.
- After every run the node's `/etc/ssl/certs/ca-certificates.crt` has
the same sha256, and no scratch directory is left in `/var/tmp`.
### Screenshots
Not applicable, no UI change.
### Downstream repositories
- [x] No downstream repository is affected by this change
The change is a `hack/` script and its test. No chart value, schema or
generated file changes.
### Release note
```release-note
feat(kubernetes-nodes): `hack/proxmox-talos-template.sh` accepts `COZY_TALOS_FACTORY_CA`, a PEM file with the CA of a self-hosted Image Factory, and trusts it on top of the Proxmox node's system store for the image download. A factory that needs `talos.imageFactoryCA` for CDI now works for Proxmox templates too.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* HTTPS downloads of Talos images can now use certificates from a
specified private CA file, alongside the Proxmox node’s trusted
certificates.
* Private CA files are validated, and downloads are restricted to HTTPS.
Without a specified CA file, downloads continue using the existing
system trust behavior.
* **Tests**
* Added coverage for private CA handling, certificate-file validation,
and HTTPS requirements.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Cozystack
Cozystack is a free and open-source platform and framework for building clouds.
Cozystack is a CNCF Sandbox project that was originally built and sponsored by Ænix.
With Cozystack, you can transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
Use Cozystack to build your own cloud or provide a cost-effective development environment.
Use-Cases
-
Using Cozystack to build a public cloud
You can use Cozystack as a backend for a public cloud -
Using Cozystack to build a private cloud
You can use Cozystack as a platform to build a private cloud powered by Infrastructure-as-Code approach -
Using Cozystack to build your own platform
You can install only the Cozystack components you need on an existing Kubernetes cluster
Documentation
The documentation is located on the cozystack.io website.
Read the Getting Started section for a quick start.
If you encounter any difficulties, start with the troubleshooting guide and work your way through the process that we've outlined.
Versioning
Versioning adheres to the Semantic Versioning principles.
A full list of the available releases is available in the GitHub repository's Release section.
Contributions
Contributions are highly appreciated and very welcomed!
In case of bugs, please check if the issue has already been opened by checking the GitHub Issues section. If it isn't, you can open a new one. A detailed report will help us replicate it, assess it, and work on a fix.
You are welcome to take on the fix yourself. Commits are used to generate the changelog, and their author will be referenced in it.
If you have a concrete feature request, open an issue. For a cross-cutting or architectural change, open a design proposal in the community repo. For questions or early ideas, use GitHub Discussions. See CONTRIBUTING.md for the full routing.
Community
You are welcome to join us in #cozystack, on either CNCF Slack (get an invite) or Kubernetes Slack (get an invite), in our Telegram group, and at our community meetings. Add them to your Google Calendar or iCal for convenience.
Project documents
| Document | What it covers |
|---|---|
| Governance | How decisions are made and who makes them |
| Contributor Ladder | How to grow from contributor to maintainer |
| Maintainers | Who maintains the project |
| Code of Conduct | What we expect of each other |
| Security Policy | Reporting a vulnerability, and which releases get fixes |
| Adopters | Who runs Cozystack in production |
| Roadmap | Where the project is going |
License
Cozystack is licensed under Apache 2.0.
The code is provided as-is with no warranties.
Commercial Support
A list of companies providing commercial support for this project can be found on official site.