The _GET /user/ca_ operation returns the public key of the user CA.
This can be used by hosts to "bootstrap" their trusted signing keys for
user authentication.
After building and publishing a new "latest" container image, we can
automatically deploy it to production by restarting the *sshca*
Deployment. We use `curl` here to patch the Deployment manually, since
`kubectl` is not available in the container image. This is a simple
enough operation that it's not worth the effort of trying to install it.
In some cases, users may need to authenticate as a different user on the
remote machine than their normal username. For example, the default user
*core* on a Fedora CoreOS machine, or the *root* user on machines that
have not been provisioned yet. In such cases, the default set of
principals on issued user certificates is not sufficient.
We don't want to allow users to specify arbitrary principals, so instead
we can use their membership in specific groups to add a preselected set
of principals.
Since the `groups` claim is not part of the core OpenID Connect
specification, we have to define it ourselves as part of the "additional
claims" of the token. This is somewhat cumbersome and involves a lot of
copying from the core type aliases, but otherwise straightforward.
According to the *sshd(8)* manual page:
> Certificates may encode access restrictions similar to these key
> options. If both certificate restrictions and key options are
> present, the most restrictive union of the two is applied.
This would seem to apply that if a certificate has no restrictions, all
features are allowed unless restricted in the `authorized_keys` file.
Unfortunately, this is not actually the case. A certificate with no
extensions apparently trumps all other configuration. As such,
certificates need to explicitly list the features users will need.
The list of extensions to add to user certificates is configurable via
the `ca.user.extensions` array. The default set should provide a good
user experience without being overly permissive.
The SSHCA container image is supposed to be published to the *packages*
organization, since it is an image for custom software, as opposed to a
customized OS.
The OpenID Connect integration introduced a dependency on the system
OpenSSL library. As such, the OpenSSL development package needs ot be
available when building the application.
The *POST /user/sign* operation issues SSH user certificates for the
public keys provided. The request must include a valid OpenID Connect
Identity token in the `Authorization` request header, which will be used
to populate the valid principals in the signed certificate.
User certificates are typically issued for a very short duration (one
hour by default). This precludes the need for revoking certificates
that are no longer trusted; users must reauthenticate frequently and
obtain a new certificate.
The `SignKeyError` enum will also be used by the request handler for
signing SSH user certificates. Thus, I am moving it to its own module
where it can be accessed from both places.
The `sshca::ca::sign_cert` function has been renamed to
`sign_host_cert`, reflecting that it creates SSH host certificates. A
new `sign_user_cert` function is now available to sign SSH user
certificates.
The second major feature for SSHCA will be the ability to sign SSH
certificates for users. Naturally, users will need to prove their
identity to the server in order for it to issue certificates for them.
To implement that, we will use OpenID Connect Identity Tokens. Users
will obtain a token from an Identity Provider and include it in their
request to the SSHCA server. If the token is valid and issued by a
trusted provider, the server will sign the user's keys.
The `openidconnect` crate provides everything we need to validate OIDC
ID tokens. It supports fetching the OpenID Provider Configuration in
order to retrieve the signing keys. These keys are then used to
verify the signature of a token; other token metadata are verified as
well, including issuer, audience, and expiration.
To avoid making an HTTP request to the OIDC IdP for every request, the
provider configuration is cached for an hour after each lookup.
Clients, such as the `sshca` CLI utility, can use the *GET
/user/oidc-config* HTTP path operation to fetch the SSHCA server's
OpenID Connect client configuration. The can use the information
returned to initiate a login process with the IdP and obtain the
identity token to submit to the SSHCA server.
In preparation for adding a separate authorization strategy for client
requests, I have moved the implementation of the authorization strategy
for host requests in to the `server::host` module.
When this repository was split from the original *dustin/sshca*
repository, the CI pipeline was not imported. It wouldn't have mattered
if it had been, since it wouldn't have worked, anyway, given the path
changes.
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.
