7d0cff9babdf566dc4b24bd7ba9b68514d389a65
wiki/info/landscape/amazon-ec2.md
| ... | ... | @@ -273,6 +273,43 @@ In all of the following sub-sections the text will assume that you have provided |
| 273 | 273 | |
| 274 | 274 | In several of the scenarios, both, AdminConsole and REST API, you will have the option to provide security bearer tokens that are used to authenticate requests to processes running the SAP Sailing Analytics. If you omit those, the credentials of the session used to authenticate your sailing user will be used. (Note, that for local test set-ups disconnected from the standard security realm used by all of the sapsailing.com-deployed processes, these credentials may not be accepted by the processes you're trying to control. In this case, please provide explicit bearer tokens instead.) We distinguish between the credentials required to replicate the information shared across the landscape, usually from ``security-service.sapsailing.com``, and those used by a replica in one of your application replica sets to authenticate for credentials to replicate the application replica set's master. |
| 275 | 275 | |
| 276 | +There is now a single point of truth for the various ssh and AWS keys, and possibly others in the future. This can be found at /root/key_vault on the central reverse proxy. There you will find directories for different environments' key setups, named consistently with the environment types under `${GIT_HOME}/configuration/environments_scripts` (the directory names are the environment type). One can use the `setup_keys` function in `imageupgrade_functions.sh` to setup the keys. There is 1 parameter, the environment type. |
|
| 277 | + |
|
| 278 | +The structure of the vault is important for the efficacy of the script and should appear as below. There is an explanation afterwards. |
|
| 279 | +``` |
|
| 280 | +key_vault |
|
| 281 | +├── aws_credentials |
|
| 282 | +│ └── disposable-reverse-proxy-automation |
|
| 283 | +├── central_reverse_proxy |
|
| 284 | +│ ├── httpdConf |
|
| 285 | +│ │ ├── aws |
|
| 286 | +│ │ │ └── credentials -> ../../../aws_credentials/disposable-reverse-proxy-automation |
|
| 287 | +│ │ └── ssh |
|
| 288 | +│ │ ├── authorized_keys |
|
| 289 | +│ │ │ ├── id_ed25519.pub@root@central_reverse_proxy -> ../../../root/ssh/id_ed25519.pub |
|
| 290 | +│ │ │ └── id_ed25519.pub@root@reverse_proxy -> ../../../../reverse_proxy/root/ssh/id_ed25519.pub |
|
| 291 | +│ │ ├── id_ed25519 |
|
| 292 | +│ │ └── id_ed25519.pub |
|
| 293 | +│ ├── root |
|
| 294 | +│ │ └── ssh |
|
| 295 | +│ │ ├── authorized_keys |
|
| 296 | +│ │ │ └── id_ed25519.pub@httpdConf@central_reverse_proxy -> ../../../httpdConf/ssh/id_ed25519.pub |
|
| 297 | +│ │ ├── id_ed25519 |
|
| 298 | +│ │ └── id_ed25519.pub |
|
| 299 | +``` |
|
| 300 | +1. So we have the aws_credentials directory, storing the credentials for specific AWS users. |
|
| 301 | +2. We also have directories named after the environment types (matching the directory names in GIT_HOME/configuration/environments_scripts). |
|
| 302 | +3. Nested within these, we have directories for each user that will require some keys, for the given environment type. |
|
| 303 | +4. For each user, we have optional directories "ssh" & "aws" (the naming is important). |
|
| 304 | +5. The aws folder should contain only credentials files which are sym links to the aws_credentials folder. |
|
| 305 | +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. |
|
| 306 | +7. The ssh folder will contain the ssh keys of the user; they are named based on the type of the key. |
|
| 307 | +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 |
|
| 308 | +for root, so the id_ed25519 key of the httpdConf user on the central reverse proxy will be able to access the root user. |
|
| 309 | +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. |
|
| 310 | +10. The script will copy across the keys in the ssh folder (ignoring sym links or directories). |
|
| 311 | +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. |
|
| 312 | + |
|
| 276 | 313 | ### Creating a New Application Replica Set |
| 277 | 314 | |
| 278 | 315 | In the Application Replica Sets table click the "Add" button and provide the replica set name. You may already now press the OK button and will receive a new application replica set with a master process running on a new dedicated host, and a single replica process running on a new instance launched by the application replica set's auto-scaling group. |