wiki/info/landscape/amazon-ec2.md
... ...
@@ -282,13 +282,15 @@ There is now a single point of truth for the various ssh and AWS keys, and possi
282 282
283 283
The structure of the vault is important for the efficacy of the script and should appear as below. There is an explanation afterwards.
284 284
```
285
-key_vault
285
+.
286 286
├── aws_credentials
287
+│   ├── axel-central-reverse-proxy-credentials
287 288
│   └── disposable-reverse-proxy-automation
288 289
├── central_reverse_proxy
289 290
│   ├── httpdConf
290 291
│   │   ├── aws
291
-│   │   │   └── credentials -> ../../../aws_credentials/disposable-reverse-proxy-automation
292
+│   │   │   └── credentials
293
+│   │   │   └── disposable-reverse-proxy-automation -> ../../../../aws_credentials/disposable-reverse-proxy-automation
292 294
│   │   └── ssh
293 295
│   │   ├── authorized_keys
294 296
│   │   │   ├── id_ed25519.pub@root@central_reverse_proxy -> ../../../root/ssh/id_ed25519.pub
... ...
@@ -296,23 +298,46 @@ key_vault
296 298
│   │   ├── id_ed25519
297 299
│   │   └── id_ed25519.pub
298 300
│   ├── root
301
+│   │   ├── aws
302
+│   │   │   ├── config
303
+│   │   │   │   └── axel
304
+│   │   │   └── credentials
305
+│   │   │   ├── axel-central-reverse-proxy-credentials -> ../../../../aws_credentials/axel-central-reverse-proxy-credentials
306
+│   │   │   └── disposable-reverse-proxy-automation -> ../../../../aws_credentials/disposable-reverse-proxy-automation
299 307
│   │   └── ssh
300 308
│   │   ├── authorized_keys
301 309
│   │   │   └── id_ed25519.pub@httpdConf@central_reverse_proxy -> ../../../httpdConf/ssh/id_ed25519.pub
302 310
│   │   ├── id_ed25519
303 311
│   │   └── id_ed25519.pub
312
+│   └── wiki
313
+│   └── ssh
314
+│   └── authorized_keys
315
+│   └── id_ed25519.pub@root@reverse_proxy -> ../../../../reverse_proxy/root/ssh/id_ed25519.pub
316
+├── README
317
+...
304 318
```
319
+
305 320
1. So we have the aws_credentials directory, storing the credentials for specific AWS users.
321
+
306 322
2. We also have directories named after the environment types (matching the directory names in GIT_HOME/configuration/environments_scripts).
323
+
307 324
3. Nested within these, we have directories for each user that will require some keys, for the given environment type.
325
+
308 326
4. For each user, we have optional directories "ssh" & "aws" (the naming is important).
309
-5. The aws folder should contain only credentials files which are sym links to the aws_credentials folder.
310
-6. If the setup_keys script is run, the contents of the aws folder will be copied, across to the respective .aws folder on the instance the script runs on, within the correct user's home directory. The config file will be created with the correct region. Although, it will *only* be the default profile.
327
+
328
+5. The aws folder can contain a config and credentials folder. The credentials folder contains sym links to aws_credentials, whilst the config folder contains config header and format.
329
+
330
+6. If the setup_keys script is run, the contents of the credentials and config folders are concatenated into the credentials and config file respectively, which are found in .aws home dir of the user that the folders are nested within. The region is automatically added and so shouldn't be defined in the config. Note, that the general idea is to use the "default" header and define access control for that instance type through AWS credentials, reducing the number of different profiles, as well as complexity of scripts.
331
+
311 332
7. The ssh folder will contain the ssh keys of the user; they are named based on the type of the key.
333
+
312 334
8. Furthermore, the folder will contain an authorized_keys directory, which holds references to the keys (elsewhere in the vault), which should be authorized to access the user. In the above example, the symbolic link named `id_ed25519.pub@httpdConf@central_reverse_proxy` means that the key referenced will be in the authorized keys
313 335
for root, so the id_ed25519 key of the httpdConf user on the central reverse proxy will be able to access the root user.
336
+
314 337
9. The name of these links doesn't matter, but by convention we will use the format used in the image above (`key_type@user@env_type`), using @ as a separator.
338
+
315 339
10. The script will copy across the keys in the ssh folder (ignoring sym links or directories).
340
+
316 341
11. The script will append every public key that is linked in the authorized_keys folder, to the authorized_keys file of the respective user.
317 342
318 343
### Creating a New Application Replica Set