rhtyd commented on issue #2239: CLOUDSTACK-9993: Securing Agents Communications URL: https://github.com/apache/cloudstack/pull/2239#issuecomment-324971414 @mlsorensen yes if @wido wants to use the new secure system he can (1) create a keystore at /etc/cloudstack/agent/cloud.jks with a 'cloud' alias and password at agent.properties file, and (2) create a CSR using the keystore, (3) use the CSR to issue a certificate from management server and save the certificate and ca-certs and import them into the keystore, (4) add/start the agent to a zone/cluster. The utility scripts will be installed as part of `cloudstack-common` package and will be put in systemvm.iso for systemvms, and available at: `/usr/share/cloudstack-common/scripts/util/{keystore-cert-import, keystore-setup}` I'll document the usage of these scripts, in admin docs or somewhere, briefly here's how these scripts work: (the command name and options in <> brackets) `keystore-setup` <the agent/db properties filepath> <the target keystore filepath> <the keystore password> <ks/cert validity in number of days> <csr filepath> This script will save and output the csr, save the keystore passphrase in the properties file and also create a `cloud.jks.new` keystore file. After the certificate (ca+client) are created, they are stored in the keystore file using `keystore-import-cert` script: `keystore-cert-import` <properties filepath> <final keystore filename, give cloud.jks not cloud.jks.new> <application mode: ssh|agent, only in ssh mode the agent/cloud service is restarted, ex. for systemvms> <the certificate filepath> <the certificate content/base-64 with newlines replaced by `^` and spaces replaced by `~`> <the ca-cert filepath> <the ca-cert content, with char-replacements same as the cert content> <the private key file path, this is useful only when csr was not used/created> <the private key content, with same char-replacement scheme> Running the import-script would save the certs in the keystore file `cloud.jks.new` and rename it to `cloud.jks`. The `.new` is used to act as a two-phase commit approach, so in case during provisioning (for example, a live system using provisionCertificate API) if anything goes bad, it won't affect an existing keystore. Lastly, in addition to the keystore file, the certificates and keys are also stored in usual x509/pem formats with `chmod 600` applied to them, at the agent conf directory for usage with other services. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
With regards, Apache Git Services
