|
1 | | -# Sharing Vaults |
| 1 | +# Sharing Vaults With Secrets |
2 | 2 |
|
3 | | -This tutorial assumes that you are working in the `Polykey` project's directory, and you have successfully built it using `npm run build`. |
| 3 | +In Polykey, sharing vaults containing secrets is essential for collaborative environments. This guide will walk you through the process of securely sharing your vaults and enabling other users to access and synchronize secrets between trusted nodes. |
4 | 4 |
|
5 | | -### Setting Up Nodes |
6 | | -For two agents to communicate with each other we need two agents to be running. For this example we're going to run two `Polykey` nodes on the same machine and have them communicate over the loop-back device. |
| 5 | +## Prerequisites for Sharing Vaults |
7 | 6 |
|
8 | | -First we want to start the first node. Since we are going to run two nodes on the same machine, we need to keep them separate. For this we need to override the `node-path` to a directory we want the `Polykey` node to be created in. for this example we're going to use a temp directory `tmp`. We're also going to set a static port value for the proxy. |
| 7 | +Before sharing a vault, ensure that both nodes have established trust and appropriate permissions are set. For details on setting trust and access permissions, refer to the "Discovering Users' Nodes and Managing Access Permissions" section. |
9 | 8 |
|
10 | | -Run the following command |
| 9 | +### Common Debugging Techniques for Sharing Secrets |
11 | 10 |
|
12 | | -``` |
13 | | -node dist/bin/polykey agent start --node-path tmp/nodeA --proxy-port 55551 |
14 | | -``` |
15 | | - |
16 | | -If this is the first time creating the node you should be prompted for the password twice. After that some information about the node should be printed. |
| 11 | +To share secrets between two nodes on different machines, both must be actively connected to the Polykey network. Here are some techniques to ensure connectivity and troubleshoot common issues: |
17 | 12 |
|
18 | | -``` |
19 | | -✔ Enter new password … ******** |
20 | | -✔ Confirm new password … ******** |
21 | | -pid 476567 |
22 | | -nodeId "vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390" |
23 | | -clientHost "127.0.0.1" |
24 | | -clientPort 50617 |
25 | | -agentHost "127.0.0.1" |
26 | | -agentPort 35629 |
27 | | -proxyHost "0.0.0.0" |
28 | | -proxyPort 55551 |
29 | | -forwardHost "127.0.0.1" |
30 | | -forwardPort 38331 |
31 | | -recoveryCode "drill video walnut message stone exhibit render snack comic maze deposit decline bless unit crater correct stool remain legend problem egg lecture approve normal" |
32 | | -``` |
| 13 | +- **Node Ping:** Use `polykey nodes ping <nodeID>` to check if the intended recipient's node is active and reachable. |
33 | 14 |
|
34 | | -Note the `NodeId` here as `vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g`. This will differ for your node. |
| 15 | +- **Restarting Polykey Agent:** If connectivity issues persist, try restarting the Polykey agent. Persistent errors might indicate restrictive network settings blocking communication. |
35 | 16 |
|
36 | | -Now create a 2nd node using the same method, this time with the `node-path` of `tmp/nodeB` and port `55552`. You should see the same password prompt and status read-out. For our example the 2nd node has a `NodeId` of `vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg`. |
| 17 | +- **Network Alternatives:** Connectivity issues may also be due to restrictive networks, try connecting from a different network environment. |
37 | 18 |
|
38 | | -### Connecting and Trusting Nodes |
| 19 | +- **Multiple Nodes:** To test sharing functionality without another user, set up multiple nodes on your system. Refer to the managing multiple nodes section for guidance. |
39 | 20 |
|
40 | | -Normally when a `Polykey` node is started, the first thing it does is automatically contact a seed node to join the network. In the absence of seed nodes to act as an entry point for a network. We can tell a node how to find other nodes directly. |
| 21 | +## Sharing the Vault |
41 | 22 |
|
42 | | -First we need to tell `NodeA` how to contact `NodeB`. For this we need to know the `NodeId`, `host` and `port` of `NodeB`. If we read the status output of `NodeB` when we started it up, we can see the following information. |
| 23 | +Share a vault with another node using the `polykey vaults share` command: |
43 | 24 |
|
44 | | -``` |
45 | | -nodeId "vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g" |
46 | | -... |
47 | | -proxyHost "0.0.0.0" |
48 | | -proxyPort 55551 |
| 25 | +```bash |
| 26 | +polykey vaults share <vaultName> <nodeId> |
49 | 27 | ``` |
50 | 28 |
|
51 | | -Using this we give `NodeA` `NodeB`'s information using the following command. |
| 29 | +- `<vaultName>`: The name of the vault you wish to share. |
| 30 | +- `<nodeId>`: The Node ID of the node you are sharing the vault with. |
52 | 31 |
|
53 | | -``` |
54 | | -node dist/bin/polykey nodes add --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg 127.0.0.1 55552 |
55 | | -``` |
56 | | - |
57 | | -This will add the `NodeB`'s connection information into `NodeA`'s node graph. Now whenever we refer to `NodeB` via it's `NodeId` of `vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg`, `NodeA` will know where to connect to. Note that this step is only needed because both nodes do not share a network. If they did share a network then they could query nodes within the network to find each other. |
| 32 | +:::tip |
58 | 33 |
|
59 | | -To verify if this information is correct and a connection can be made, we can ping `NodeB` using the following command. |
| 34 | +Remember, you can run the following commands to reference the argument names to pass into your command: |
60 | 35 |
|
61 | | -``` |
62 | | -node dist/bin/polykey nodes ping --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg |
63 | | -``` |
| 36 | +- `polykey vaults list` |
| 37 | +- `polykey identities list` |
64 | 38 |
|
65 | | -If a connection can be made then you should get `Node is Active.` as the response. Otherwise, you will get `No response received`. |
| 39 | +::: |
66 | 40 |
|
67 | | -When a connection is made between two nodes then they learn about each other. So when `NodeA` pinged `NodeB`, `NodeB` learned how to connect to `NodeA`. You can verify this by pinging `NodeA` from `NodeB`. |
| 41 | +### Example |
68 | 42 |
|
| 43 | +```bash |
| 44 | +polykey vaults share my-software-project v4c11qv5fpq2fm3ropmma2sglfc9349jspqb1iutl3f7en1ckv500 |
69 | 45 | ``` |
70 | | -node dist/bin/polykey nodes ping --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390 |
71 | 46 |
|
72 | | -Node is Active. |
73 | | -``` |
| 47 | +This command shares the "my-software-project" vault with the specified node. |
74 | 48 |
|
75 | | -Now if `NodeA` wants to do anything more complex than pinging `NodeB`, we need to make `NodeB` trust `NodeA`. We can do this with the trust command. This will allow `NodeB` to receive notifications from `NodeA`, otherwise `NodeB` will just ignore them. |
| 49 | +## Receiving a Shared Vault |
76 | 50 |
|
77 | | -``` |
78 | | -node dist/bin/polykey identities trust --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390 |
79 | | -``` |
| 51 | +### Scanning for Available Vaults |
80 | 52 |
|
81 | | -We should also have `NodeA` trust `NodeB`. |
| 53 | +Once a vault is shared, the recipient should scan for available vaults: |
82 | 54 |
|
83 | | -``` |
84 | | -node dist/bin/polykey identities trust --node-path tmp/nodeB vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg |
| 55 | +```bash |
| 56 | +polykey vaults scan <nodeId> |
85 | 57 | ``` |
86 | 58 |
|
87 | | -### Sharing Vaults |
| 59 | +- `<nodeId>`: The Node ID of the node that shared the vault with you. |
88 | 60 |
|
89 | | -#### Creating a Vault |
90 | | -A core feature of `Polykey` is sharing secrets between nodes. This is done by sharing the vaults that contain the secrets. In order to do this we need a vault to share. Start by creating a vault on `NodeB`. We can do this with the `vaults create` command, doing so will return a unique `VaultId` to identify that vault. |
| 61 | +#### Example |
91 | 62 |
|
| 63 | +```bash |
| 64 | +polykey vaults scan v4c11qv5fpq2fm3ropmma2sglfc9349jspqb1iutl3f7en1ckv500 |
92 | 65 | ``` |
93 | | -node dist/bin/polykey vaults create --node-path tmp/nodeB someVault |
94 | 66 |
|
95 | | -Vault zRMeFutQmJErPNR5rAE1LmN created successfully |
96 | | -``` |
| 67 | +This command lists the vaults shared by the specified node. |
97 | 68 |
|
98 | | -Vaults and generally be referenced by its name, here it's `someVault`. Or it's `VaultId`, here as `zRMeFutQmJErPNR5rAE1LmN`. An empty vault Is not very useful so let's add some data to it. |
| 69 | +## Cloning the Shared Vault |
99 | 70 |
|
| 71 | +After identifying the shared vaults, the recipient can clone the desired vault to their own local node: |
100 | 72 |
|
| 73 | +```bash |
| 74 | +polykey vaults clone <vaultName> <nodeId> |
101 | 75 | ``` |
102 | | -echo "this is a secret" > tmp/someSecret |
103 | 76 |
|
104 | | -node dist/bin/polykey secrets create --node-path tmp/nodeB tmp/someSecret someVault:someSecret |
105 | | -``` |
| 77 | +- `<vaultName>`: The name of the vault to be cloned. |
| 78 | +- `<nodeId>`: The Node ID from which to clone the vault. |
106 | 79 |
|
107 | | -We should be able to see the secret in the vault now. |
| 80 | +### Example |
108 | 81 |
|
| 82 | +```bash |
| 83 | +polykey vaults clone myvault v4c11qv5fpq2fm3ropmma2sglfc9349jspqb1iutl3f7en1ckv500 |
109 | 84 | ``` |
110 | | -node dist/bin/polykey secrets list --node-path tmp/nodeB someVault |
111 | 85 |
|
112 | | -someSecret |
113 | | -``` |
| 86 | +This command clones "myvault" from the specified node to the local system. |
114 | 87 |
|
115 | | -#### Sharing a Vault |
| 88 | +## Synchronizing Changes |
116 | 89 |
|
117 | | -The next step is allowing `NodeA` to clone a vault from `NodeB`. This is done with the `vaults share` command. This will give `NodeA` permission to clone and pull this vault and send a notification to `NodeA`. |
| 90 | +If updates are made to the original vault, such as key rotations or new secrets added, the receiving node can synchronize these changes by pulling the latest version of the vault: |
118 | 91 |
|
| 92 | +```bash |
| 93 | +polykey vaults pull <vaultName> <targetNodeId> |
119 | 94 | ``` |
120 | | -node dist/bin/polykey vaults share --node-path tmp/nodeB someVault vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390 |
121 | | -``` |
122 | | - |
123 | | -`NodeA` should be able to clone the vault now. This is done with the `vaults clone` command. |
124 | 95 |
|
125 | | -``` |
126 | | -node dist/bin/polykey vaults clone --node-path tmp/nodeA someVault vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg |
127 | | -``` |
| 96 | +- `<vaultNameOrId>`: The name or ID of the vault to update. |
| 97 | +- `<targetNodeId>`: (Optional) The node ID from which to pull updates. |
128 | 98 |
|
129 | | -If this completed with no errors, we should be able to see the vault in `NodeA` now. |
| 99 | +### Example |
130 | 100 |
|
| 101 | +```bash |
| 102 | +polykey vaults pull myvault v4c11qv5fpq2fm3ropmma2sglfc9349jspqb1iutl3f7en1ckv500 |
131 | 103 | ``` |
132 | | -node dist/bin/polykey vaults list --node-path tmp/nodeA |
133 | 104 |
|
134 | | -someVault: zEsnWCGvgBqSuuu8r2SscSQ |
135 | | -``` |
| 105 | +This command updates "myvault" with the latest changes from the specified node. |
136 | 106 |
|
137 | | -We can access the secret as well. |
| 107 | +## Conclussion |
138 | 108 |
|
139 | | -``` |
140 | | -node dist/bin/polykey secrets list --node-path tmp/nodeA someVault |
141 | | -
|
142 | | -someSecret |
143 | | -
|
144 | | -node dist/bin/polykey secrets get --node-path tmp/nodeA someVault:someSecret |
145 | | -
|
146 | | -this is a secret |
147 | | -``` |
148 | | - |
149 | | -#### Pulling Vault Changes |
150 | | - |
151 | | -Vaults can be updated. If we wanted these changes then we can pull the vault. If a vault was cloned from another node then it keeps track of where it came from. So pulling a vault is pretty simple. |
152 | | - |
153 | | -First we need to add a new secret to `NodeB`'s vault. |
154 | | - |
155 | | -``` |
156 | | -node dist/bin/polykey secrets create --node-path tmp/nodeB tmp/newSecret someVault:newSecret |
157 | | -
|
158 | | -node dist/bin/polykey secrets list --node-path tmp/nodeB someVault |
159 | | -
|
160 | | -newSecret |
161 | | -someSecret |
162 | | -``` |
163 | | - |
164 | | -Now we can tell `NodeA` to pull the changes from `NodeB` with `Vaults pull`. |
165 | | - |
166 | | -``` |
167 | | -node dist/bin/polykey vaults pull --node-path tmp/nodeA someVault |
168 | | -``` |
169 | | - |
170 | | -And see the changes |
171 | | - |
172 | | -``` |
173 | | -node dist/bin/polykey secrets list --node-path tmp/nodeA someVault |
174 | | -
|
175 | | -newSecret |
176 | | -someSecret |
177 | | -
|
178 | | -node dist/bin/polykey secrets get --node-path tmp/nodeA someVault:newSecret |
179 | | -
|
180 | | -This is a new secret |
181 | | -``` |
| 109 | +Sharing and synchronizing vaults in Polykey enhances collaboration and security across the network. By following these guidelines, users can effectively manage sensitive data, ensuring all parties involved have secure and up-to-date access to shared resources. |
0 commit comments