Skip to content

Conversation

@thijshberg
Copy link
Collaborator

Adds the KMS feature for the SSH capability

Includes some tests and a deployment example

It currently works as an interface to an underlying directory with keys. There is are API endpoints for listing all keys, adding a key, and revoking a key (which moves and renames the underlying files). It is activated and configured by environment variables.

If the feature is not configured at startup there is no method to enable it later. The routes are also not instantiated if the feature is disabled.

This is done via a .env flag and directory indication.
We use the kms property of the user_auth field in CACAO for the
reference to the key.

The key identifier is just the name of the file in the directory as given in
.env. This is convenient for persistence and interaction with other
tasks. The keys are cached. There is room for an api interacting with
the system.

There is also some extra information in the ssh logging, which helps
with identifying errors in the ssh layer.
There is now an example playbook using the KMS system.

There is also a testing docker config. This does not use the same setup
as the existing ssh example unfortunately.

The example requires some work to set up the KMS folder. You should
first set up an example keypair in the deployment example, and then set
up a folder for the KMS system containing those keys (either copying or
using the deployment location).
This makes it possible to get the list of keys, add keys manually, and
revoke keys. Revoking does not delete keys but just moves and renames
the underlying files to prevent irrevertible mishaps.

This should serve as a starting point for consumers such as
soarca-gui.
This also removes some bugs from the existing code
@thijshberg thijshberg force-pushed the feature/332-kms-key-auth branch from 2e32324 to ff98f14 Compare August 13, 2025 12:20
@thijshberg
Copy link
Collaborator Author

The folder-based structure has been removed, the backing is now the same as the playbook api. That is, a mongo option and a simple in-memory option.

This removes the need for a cache in the keymanagement component. The keymanagement component is now more of a front-end for dealing with key parsing and hiding the indirection of the database.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants