InterSystems Cloud Manager Guide
The security measures included in ICM are described in the following sections:
For information about the ICM fields used to specify the files needed for the security described here, see Security-Related Parameters
This is the host machine on which containers are deployed. It may be virtual or physical, running in the cloud or on-premises.
ICM uses SSH to log into compute nodes and remotely execute commands on them, and SCP to copy files between the ICM container and a compute node. To enable this secure communication, you must provide an SSH public/private key pair and specify these keys in the defaults.json file as SSHPublicKey and SSHPrivateKey. During the configuration phase, ICM disables password login on each compute node, copies the private key to the node, and opens port 22, enabling clients with the corresponding public key to use SSH and SCP to connect to the node.
Other ports opened on the host machine are covered in the sections that follow.
During provisioning, ICM downloads and installs a specific version of Docker from the official Docker web site using a GPG fingerprint. ICM then copies the TLS certificates you provide (located in the directory specified by the TLSKeyDir field in the defaults file) to the host machine, starts the Docker daemon with TLS enabled, and opens port 2376. At this point clients with the corresponding certificates can issue Docker commands to the host machine.
During provisioning, ICM launches Weave Net with options to encrypt traffic and require a password (provided by the user) from each machine joining the Weave network.
You can disable encryption of Weave Net traffic by setting the WeavePassword to the literal "null" in the defaults.json file. (By default, this parameter is generated by ICM and is set to the Weave Net password provided by the user.)
ICM does not install these monitoring products by default. They are deployed with authentication enabled; credentials must be provided in the defaults.json
file. For more information, see Monitoring in ICM
ICM expects that the InterSystems IRIS image was installed with Normal security (as opposed to Minimal or Locked Down).
To secure the InterSystems IRIS instance, the default password for predefined accounts must be changed by ICM. The first time ICM runs the InterSystems IRIS container, passwords on all enabled accounts with non-null roles are changed to a password provided by the user. If you don’t want the InterSystems IRIS password to appear in the definitions files, or in your command-line history using the -iscPassword option, you can omit both; ICM interactively prompts for the password, masking your typing. Because passwords are persisted, they are not changed when the InterSystems IRIS container is restarted or upgraded.
ICM opens JDBC connections to InterSystems IRIS in SSL/TLS mode (as required by InterSystems IRIS), using the files located in the directory specified by the TLSKeyDir field in the defaults file.
ICM creates mirrors (both DM pairs and DS failover pairs) with SSL/TLS enabled (see the “Mirroring
" chapter of the High Availability Guide
), using the files located in the directory specified by the TLSKeyDir
field in the defaults file. Failover members can join a mirror only if SSL/TLS enabled.
ICM configures WS nodes to communicate with DM and AM nodes using SSL/TLS, using the files located in the directory specified by the TLSKeyDir field in the defaults file.
InterSystems recommends the use of an LDAP server to implement centralized security across the nodes of a sharded cluster or other ICM deployment. For information about using LDAP with InterSystems IRIS, see the “Using LDAP
” chapter of the Security Administration Guide
Content Date/Time: 2019-09-19 06:44:29