The `ARCH` environment varible set by the Jenkins pipeline uses the
Kubernetes names for CPU architectures. RPMs use the Linux kernel
names, which are not the same. Using the former, therefore, in the
`include` filter for `rsync` results in no packages being uploaded to
the repository.
dustin/sshca/pipeline/pr-master This commit looks goodDetails
dustin/sshca/pipeline/head This commit looks goodDetails
In order to automate certificate issuance and renewal for Raspberry Pi
devices, we need aarch64 builds of the `sshca` tool. Using the `matrix`
feature of Jenkins pipelines lets us reuse the same stage definition for
building the client on both platforms. Unfortunately, the `matrix`
block has to encompass the server stage as well, as `matrix` cannot be
nested below `parallel`, and we don't want to build the server and
clients sequentially. This makes the code a bit less clear, as the
server and client stages are now conditional based on the matrix
intersection, but it is cleaner than duplicating the entire client
stage.
dustin/sshca/pipeline/head This commit looks goodDetails
Apparently, the although the tooltip says " Volumes get mounted in all
containers with the specified mount path," volumes defined in the
default Pod Template in the Jenkins Kubernetes Cloud configuration
actually only get mounted in the JNLP agent container. Containers
defined in the pod template YAML document are not included in this
interpretation of "all."
dustin/sshca/pipeline/head There was a failure building this commitDetails
The CI pipeline builds both the SSHCA server and client CLI. The server
is published as an OCI image, while the latter uses RPMs. Since
multiple RPMs with the same version cannot exist in the same repository,
and since RPM versions cannot be arbitrarily set after they have been
built, the RPMs are only published when building the *master* branch.
Server container images are published from every branch, as each image
is tagged with the branch name and build number.
The *ssh-host-cert-sign@.service* unit does what it says on the tin:
requests a signed host certificate from an SSHCA server. It is a
template unit, whose instances correspond to SSH key types (RSA, ECDSA,
and Ed25519). The *ssh-host-certs.target* unit depends on the three
instances of the template unit, so they can all be activated together.
This target is only activated on the first boot of the system, to
initially request the certificates.
The *ssh-host-certs-renew.timer* unit periodically renews the SSH hosts
certificates. Its corresponding target unit depends on the three
instances of *ssh-host-cert-sign@.service*, so each certificate will be
renewed independently.
The *sshca-cli* RPM package can be used to install the SSHCA CLI client
on Fedora (and other RPM-based distributions). The `.spec` file was
originally generated using [rust2rpm], but several manual modifications
were required. Notably, the script does not generate `BuildRequres`
tags when run in "vendored" mode (i.e. third-party crate sources are
included in the source RPM package instead of packaged as separate
RPMS).
The CLI tool will be the primary method for interacting with the SSH CA
service. For now, it supports a single operation: `sshca-cli host
sign`, which requests a certificate to be signed by the CA service.`
I realized that allowing hosts to request certificates for arbitrary
aliases sort of defeats the purpose of the authentication process. If a
host successfully authenticates, there would be nothing stopping it from
requesting a certificate for another host. I will have to come up with
a different way of specifying aliases. Probably something like a JSON
map containing pre-assigned aliases for hosts that will need them.
Since hosts have multiple keys that they will want to have signed, they
will need to make multiple requests, either sequentially or in parallel.
Since each request must be authenticated individually, this would result
in a libvirt connection and lookup for each one. To avoid this
overhead, the server will now cache machine IDs in memory for 60
seconds.
Dustin