(It is important to note that access is only available to Timebeat Cloud if this is the subscription model you have ordered.)
Timebeat Cloud removes the operational overhead of managing and supporting Timebeat's dependencies. Simply put Timebeat Cloud offers complete peace of mind, and ensures your clock sync is available to view 24/7.
Connecting to Timebeat Cloud is achieved in 2 ways:
- IPSec VPN
- PKI certificates and TLS
It is by far simpler and faster to connect to Timebeat Cloud using our PKI method and can allow you to be up and running in seconds rather than potentially hours.
This guide will not go into details on how to connect using IPSec VPN as this will always require working with the Timebeat technical team to set up and as such they will provide full instruction details at the time, instead we will look at how simple it is to get up and running with PKI's still ensuring absolute protection and security.
PKI certification and TLS
The simplest and by far the favoured approach to connecting to Timebeat Cloud is by using TLS and PKI certification.
Timebeat creates various levels of security within the application and certificates.
This ultimately results in each process or element to the Timebeat solution only having the absolute minimum level of privileges it requires in order to carry out its function for example:
- The Front end only has read privileges
- The Timebeat process/agent only has write privileges
- The Database has read and write privilege but no delete (unless accessed via admin role)
When getting started on Timebeat Cloud one of our team members will issue you with a PKI file, this will contain 3 files typically labeled:
ca.crt
timebeat.crt
timebeat.key
Although these files can be placed anywhere provided the timebeat.yml file has the correct path location we recommend using the below locations to maintain traditional best practices (if you do not want to use the default location of "/etc/timebeat/pki/*").
It is worth noting at this point that different Linux distributions use slightly different locations so do check what your distribution recommends, the timebeat.yml file uses the CentOS/RHEL distributions location as its default parameters.
SSL directory on Ubuntu
The right place to store your certificate is /etc/ssl/certs/ directory.
Save your private keys to /etc/ssl/private/ directory.
SSL directory on CentOS/RHEL
The right place to store your certificate is /etc/pki/tls/certs/ directory.
Save your private keys to /etc/pki/tls/private/ directory.
Move or copy the files named ca.crt & timebeat.crt into the */*/*/certs/directory and the timebeat.key file into */*/*/private/directory.
This can be achieved by using the mv command:
mv <path/to/timebeat-ca.crt> /etc/pki/tls/certs/timebeat-ca.crt
mv <path/to/timebeat-ca.crt> /etc/pki/tls/certs/timebeat.crt
mv <path/to/timebeat.key> /etc/pki/tls/private/timebeat.key
Always secure the private key file
The private key file for your SSL certificate should always be only accessible to the root user only. Run the appropriate commands on the file to secure it:
chown root:root /etc/pki/tls/private/timebeat.key
chmod 0600 /etc/pki/tls/private/timebeat.key
Now all that is left is to double-check the timebeat.yml configuration file to ensure that the correct directory locations have been inputted. This section is found in the elastic output section of the config.
For details on the elastic output, configuration check out our guide
Assuming the configuration is correct you can go ahead and start the Timebeat service.