The HandshakeΒΆ

This document describes how agent connections to DCM are authenticated and authorized. This process is known as the handshake. In the handshake process the agent must convince DCM that it is running on a known server and that it is the trusted agent for that server. The agent handles this by providing DCM with as much information as it can from the following:

  • Injected ID: This is a key that DCM pushes into a cloud’s metadata server where available
  • Instance ID: The ID the cloud uses to describe the server.
  • IP addresses: All IP addresses available to the server.
  • token: A random string generated by the agent for its first connection. This is discussed in detail here label-name.

All of the above information is used by DCM to attempt to authenticate the agent’s connection and authorize it for use by DCM. Exactly how the information is used varies based on cloud and DCM configuration.

DCM supports many different clouds and each cloud provides different pieces of information to the servers they run, thus an agent may not be able to get every piece of information listed about. Further an operator of DCM may be willing to trust servers on some clouds more than servers on other clouds. For example on an on-premise deployment of DCM servers running on an internal private cloud are potentially more trustworthy than those running in a public cloud.

The agent itself makes no decisions in the handshake process, it simply provides all of the information that it can and then awaits a decisions by DCM. If an agent fails to authenticate at one point in time it is appropriate for the agent to try again because DCM may not been able to yet gather the needed information from a given cloud.