-
Notifications
You must be signed in to change notification settings - Fork 14
Feature/332 kms key auth #363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
thijshberg
wants to merge
18
commits into
development
Choose a base branch
from
feature/332-kms-key-auth
base: development
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
2e32324 to
ff98f14
Compare
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.
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.