Feature/332 kms key auth - #363
Conversation
2e32324 to
ff98f14
Compare
|
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. |
589c193 to
3e83ce8
Compare
3e8a34f to
0bf598a
Compare
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
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
The Severity.fromString method did not do anything with the base it was called from. This meant that all logs took the global level instead of the per-package option.
This reverts commit 23315e1.
98f884a to
d7aeaa5
Compare
GitHub Actions
Inactive
|
Quick question @thijshberg, does this create (or use) an internally managed KMS? I think integration with existing KMS (gcloud, hashicorp, etc) is much more useful and keeps the hard part (securely managing credentials) away from soarca. |
Essentially yes. The current version would serve as a starting point for that, as it leaves the actual implementation to be generic. |
|
I can see an in-memory KMS make sense from a local development and testing POV 👍 However, I think soarca should probably not be used to actually manage key material. Ideally it shouldn't need to have permissions to create, update or revoke credentials in an (external) KMS, just request (temporary) credentials it needs to perform steps. What would make sense in my mind is a read-only in-memory and simple file based KMS for development and testing. This wouldn't need API endpoints at all. |
3 participants
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.