Securing the server to agent communication
Overview
The BMC AMI Cloud management server is connected to the agent on many occasions, such as policy runs, and security checks. The connectivity between the BMC AMI Cloud server and the BMC AMI Cloud agents is protected by certificate client authentication. By default, BMC AMI Cloud protects the connection using self-signed certificates. we recommend that you replace these certificates with signed organizational ones.
Flow description
The BMC AMI Cloud agent is acting as the server side. The BMC AMI Cloud server docker container is the client-side as it connects to the agent.
At least four certificates are needed, two on the UI side and two on the agent side.
BMC AMI Cloud server requirements
The BMC AMI Cloud server side needs a private certificate that has a private key and can be used for client-side authentication (certificate request parameter: extendedKeyUsage = clientAuth).
The DNS and IP addresses in the SAN extension (certificate request parameter subjectAltName) must match the ones of the BMC AMI Cloud server.
It also needs the CA certificate chain that was used to sign the agent's private certificate.
BMC AMI Cloud agent requirements
The BMC AMI Cloud agent side requires a private certificate that has a private key and can be used for server-side authorization.
The DNS and IP addresses in the SAN extension (certificate request parameter subjectAltName) must match the ones of all of the mainframe systems that will be using this certificate.
# SAN and IP goes here
subjectAltName = DNS: system1, IP: xxx.xxx.xxx.xxx, DNS: system2, IP: xxx.xxx.xxx.xxx
# server auth and/or client auth
extendedKeyUsage = serverAuth
It also needs the CA certificate that was used to sign the UI private cert.
Normally, both private certificates are signed by the same organizational CA, so the BMC AMI Cloud server and the BMC AMI Cloud agent side CA certificates are the same certificates.
To secure the server to agent communication
- Import the required keystores and truststores certificates into four files, two on the BMC AMI Cloud server side and two on the BMC AMI Cloud agent side. These files are protected with a password.
On the BMC AMI Cloud server side, it's required to have a PKCS12 keystore file that holds the client's private certificate and key, and a JKS truststore file that holds the CA.
On the BMC AMI Cloud agent side, it's required to have a JKS keystore file that holds the Server's private certificate and key, and a JKS truststore file that holds the CA. The BMC AMI Cloud agent and the BMC AMI Cloud server need to point to these new keystore and truststore files. Update the following parameters in the BMC AMI Cloud server's configuration file (model9-local.yml) to point to the new files:
model9.security.dataInFlight.truststore.fileName: {MODEL9_HOME}/keys/truststore.jks'
model9.security.dataInFlight.truststore.type: "JKS"
model9.security.dataInFlight.truststore.password: "traststore password"
model9.security.dataInFlight.keystore.fileName: {MODEL9_HOME}/keys/keystore.p12'
model9.security.dataInFlight.keystore.type: "PKCS12"
model9.security.dataInFlight.keystore.password: "keyststore password"Update the following parameters in the agent's agent.yml to point to the new files:
keystore: /usr/lpp/model9/conf/keyststore.jks
keystore_password: personal_cert_keystore_password
truststore: usr/lpp/model9/conf/truststore.jks
truststore_password: truststore_password- Restart both the BMC AMI Cloud server docker container and the BMC AMI Cloud agents to pick up the new definitions.
- To verify the new definitions, perform a login to the BMC AMI Cloud management server using the web UI.