Security. Automation. DevOps.
The Classic Infrastructure Management System™
What is CLD?
- A lot of features and automation tools?
- Of course - but security first
- Centralized access system from one point, CLD users able to reach servers via interactive SSH/SFTP gateway or web-based console
- Centralized SSH authorized keys management
- Protection sensitive ports of all your servers on any hosting from external connections and open only to trusted IP addresses
- Update users IP addresses via personal VPN keys or with chat bot validation
- All SSH and SFTP sessions are recording, you can replay everything that users have seen and typed on the remote server, as well as all file operations done through SFTP.
Modular concept and some of built-in toolbox
- Scripts home - make, securely share and use your automation tools or built-in toolbox with any CLD interfaces (CLI, Web, API, Telegram, Discord, Mattermost, Slack)
- Backup files, databases and configurations of all your servers with multiple backup server support and daily report at CLD backup module
- Ansible - store all playbooks in one place, run playbooks in CLD instances
- Kubernetes - manage multiple kubernetes clusters, deploy access list to ingress and centralized store all helm charts
- Cloud management - organize own cloud, create, migrate and manage KVM virtual machines
- DNS control - add sites, set, edit, remove and backup DNS records or site settings with CLD CloudFlare integration
How it works?
Here are a few of the many possible use cases:
- Centralized access system
The basis of the project is a centralized system of SSH access based on PAM:
- all CLD users work according to the internal access matrix and have customizable permissions, they can be assigned personal Messenger account id, as well as API token
- each user is authorized on the server to his PAM account
- access to allowed servers is carried out using a single private SSH key or instance password
- the list of servers allowed for connection for the user is determined both by specifying specific instances and according to the groups which shared for a user
- SSH-key and passwords, with the help of which authorization takes place on remote nodes are not available to the user, respectively, this data is reliably protected and cannot be compromised
This example shows how a user tries to access instances, demonstrates how admin using a dashboard shares one instance for the user, and then a group of instances, also demonstrates the operation of an interactive SSH gate
- Protection of all servers on any hosting
Access to all servers is protected by trusted IP address lists
- access to the CLD management server (as well as to all instances connected to the system) can be limited by the list of allowed ip addresses (access lists)
- the access module provides the ability to update user addresses using a bot in messengers (telegram, discord, mattermost, slack)
- users can generate their personal VPN key to access the CLD server and instances
- trusted lists are deployed by cron, as well as by watcher after changes in the lists on the CLD server
- the list of protected ports is configurable, and separate port lists can be configured for any group or instances
This demonstration shows a user trying to connect to the server, the connection is refused until the user adds his ip address through the bot in the messenger using the link in the api containing the generated one-time token