With ever more computing resources moving off-premise and into the cloud, controlling access to these resources becomes increasingly important. Traditionally, remote access to these hosts is performed using the SSH protocol, and, while the protocol itself provides adequate security mechanisms, organizations continue to struggle to deploy these mechanisms at scale.
To boost SSH security, moving from username/password authentication to public key authentication is an important first step, but provisioning authorized keys to a large number of instances proves to be unwieldy and hard to manage. This often results in a wild growth of long-lived keys, shared by multiple users and instances, which puts the entire infrastructure at risk.
CloudGate Key Manager addresses these problems by issuing short-lived keys to individual users, and provides flexible attribute-based policies to restrict the resources that can be accessed by a specific user, group, or organizational unit. Furthermore, all this can be done with only minimal changes to existing or newly created SSH hosts.
How it works
The following diagram presents a general overview of how CloudGate Key Manager works.
- The user authenticates with their identity provider, and uses single sign-on to access CloudGate Key Manager.
- The user issues a new key in CloudGate Key Manager and downloads it to his system.
- The user uses the newly issued key to perform an SSH login to a server instance that is hosted by a cloud service provider or elsewhere.
- The server instance will inform CloudGate Key Manager of the login attempt, and request the user's matching public key. After checking whether the user should be allowed access to the server instance, CloudGate Key Manager returns the public key.
- The server instance matches the private key provided by the user with the public key provided by CloudGate Key Manager, and authenticates the user.
Please sign in to leave a comment.