-
Notifications
You must be signed in to change notification settings - Fork 5
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
Vault Scanning #339
Comments
I will need to review the code to spec this out further. |
I'm going to change up the logic here a little bit. We have this chain that handle this information. I'm going to make |
Because we originally designed the domains (classes) to be standalone objects that can provide all the methods necessary to do work, the domain classes themselves therefore expose methods that ultimately call other nodes, and that's why we inject NodeConnectionManager into various classes. So the architecture of vault scanning is like this:
There are 2 The client service The agent service This is similar to A consequence of this design is that ACL checks have to be done on the agent service handler, but not inside the |
As an example when However on the agent service handler for |
Thinking about this a bit more, I think there is room for
We wouldn't create handler methods for any method that is only targeting itself. So for example in |
If we proceed with that design, we should write that into our wiki for our domain class design. |
We have another case of needing to get the NodeId from the connection info. To finish this we are blocked by #342 . |
I'm going to need to review the agent and client service tests to make sure all of the GRPC for the vaults and secrets domains are tested properly. I think I'll make a new issue for this. @tegefaulkes For the case of
It seems like a bit of duplication of testing here since the only things we really need to test are the Bin command, |
So would the scanVaults // request to scan another node's vault
handleScanVaults // respond to the request (i.e. handle it) by returning the requested info In this case I'm not sure if notifications' |
I think it's more about handling an action than handling a response, it doesn't matter how it responds. The thinking here is that when we have the agent-agent communication. The action is started by the |
Specification
Scanning vaults is both a client service handler and agent service handler, but they do different things.
Scanning should be implemented in the
VaultManager
and not theNodeManager
.The only thing is that the agent service handler must have a scan method.
client/service/vaultsScan.ts
- performs a scan on another node, triggered bypk vaults scan
which isbin/vaults/CommandScan.ts
agent/service/vaultsScan.ts
- allows another node to scan what vaults they are allowed to clone or pull, should provide a structured data structure that indicates each vault id, vault name and the vault permissions setWe need to know how to separate the logic between:
For example, what does
VaultManager.scanVaults
do? Is a "client-side" logic or "server-side" logic? The answer to this question is neither. If we pursue the pattern of composition, then we instead lower level plumbing methods should be exposed byVaultManager
that allows it to answer the calls ofagent/service/vaultsScan.ts
. The calls ofclient/service/vaultsScan.ts
would be different instead calling the other node's agent service.At the very least
NodeManager.scanNodeVaults
should not exist, because it's not the job ofNodeManager
.VaultManager
must provide two functions.scanVaults
andhandleScanVaults
.scanVaults
makes the GRPC call to a remote agent to get the list of vaults. This is called by the clientServicescanVaults
handler to provide this data to the client.handleScanVaults
is called by the agentService handler to obtain the data in the first place.The structure follows this diagram:
The nodeId we are checking should be gotten from the connection info and not the message.
changes made
vaultsScan
logic was moved into thevaultManager
.vaultsScan
was updated to be a generator to properly stream the information andhandleVaultScan
was created to hold the logic that collects the expected information.vaultScan
request message since this is retrived via the connection info now. Agent service utility to acquire trustedConnectionInfo
from connecting client node #342.Additional context
Tasks
VaultManager.handleScanVaults
to collect the expected data to be used by the agent service handler.vaultManager.scanVaults
to be a generator to allow for streaming.The text was updated successfully, but these errors were encountered: