Commit Graph

18 Commits (master)

Author SHA1 Message Date
Dustin fe19559964 server: Add /user/ca route
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-11-09 13:40:03 -06:00
Dustin f8f8218537 ci: Auto deploy latest build of master
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-02-03 10:07:29 -06:00
Dustin 748f4dba9a user: Allow adding principals by group membership
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-02-02 20:00:32 -06:00
Dustin f9ebbbcce9 ca/user: Add certificate extensions
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-02-01 09:05:04 -06:00
Dustin f38f9d9f6e ci: Fix container image repo name
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-01-31 20:56:15 -06:00
Dustin 4b7c8c3d5a container: Install openssl-devel in build stage
dustin/sshca/pipeline/head This commit looks good Details
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.
2024-01-31 20:35:40 -06:00
Dustin be40c05b56 server/user: Add sign cert operation
dustin/sshca/pipeline/head There was a failure building this commit Details
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.
2023-11-21 22:03:02 -06:00
Dustin b945d0f142 server: Move SignKeyError to error module
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.
2023-11-21 22:03:02 -06:00
Dustin cd7a7272ef ca: Add sign_user_cert function
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.
2023-11-21 22:03:02 -06:00
Dustin 94ae6f727e server: user: Implement OIDC auth for users
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.
2023-11-21 22:03:02 -06:00
Dustin 839d756a28 server: Move auth logic to host module
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.
2023-11-16 19:58:26 -06:00
Dustin 818cfc94c2 ci: Import ci pipeline from original repo
dustin/sshca/pipeline/head This commit looks good Details
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.
2023-11-13 20:11:49 -06:00
Dustin be4f5eb6d7 server: Add Containerfile
The SSHCA server is intended to be run in a Kubernetes container.
2023-11-08 21:29:00 -06:00
Dustin a0f6119d60 server: host: Remove alias request parameter
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.
2023-11-04 16:37:19 -05:00
Dustin 87d37aebaf server: Cache machine IDs for 60 seconds
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.
2023-11-04 16:37:19 -05:00
Dustin 02d41e922d examples: Add took to generate a JWT for testing 2023-11-04 16:37:19 -05:00
Dustin 3b42be1797 ca: Add support for encrypted private keys 2023-11-04 16:37:18 -05:00
Dustin ac9681e0c3 Initial commit 2023-11-04 16:36:20 -05:00