Running the Tufin Orchestration Suite (TOS) not only means to have a system running Linux, but also a Kubernetes Cluster is running on the system. If a system restart is necessary, it's not sufficient to simply enter the "reboot" command at the command line. Even if a snapshot needs to be created from a virtual machine, measures must be taken beforehand—otherwise, a snapshot might be available, but it will not be suitable for restoring the system. 

To shut down the system running TOS these steps should be taken: 

  • Stop TOS and wait for the message that TOS has been stopped
    # tos stop -d 

  • The Pods are still terminating, wait until all Pods have been stopped successfully, then resume the command using Ctrl-C
    # watch kubectl get pods

  • The Kubernetes Cluster should also be stopped and disabled
    # systemctl stop k3s.service
    # systemctl disable k3s.service

  • The result should be checked using the commands
    # systemctl is-active k3s
    # systemcll is-enabled k3s

Now it's safe to shutdown or restart the system. Creating a snapshot is now also possible safely.
After a restart or restore of the system, neither k3s nor tos will start automatically.
This might be uncomfortable, but it should be done this way. If not, problems migth arise due to open data bases, open files, etc. 

To start the system, these steps should be carried out: 

  • Start, enable and check k3s Service. This needs to be done first since TOS requires a running Kubernetes Cluster
    # systemctl start k3s.serice
    # systemctl enable k3s service
    # systemctl is-enabled k3s.service
    # systemctl status k3s.service

  •  Start TOS and wait for the message that TOS has been started successfully
    # tos start -d 

  • The Pods are still starting even if the command states that the start has been successully done.
    Check that all Pods have been started, leave the command afterwards using CTRL-C
    # watch kubectl get pods

This method appears to be complex, but it's recommended regarding data security and keep the system running without issues. 

 

 

Since some versions of the Tufin Orchestration Suite (TOS) licensing and its enforcement is a bit more flexible as in earlier times. 

If e.g. 20 devices had been licensed some time ago, adding another device resulted in problems. Now, it's more flexible and you have the possibility to add some devices more than you have licensed. This results in the need of "license usage reports" for Tufin to find out the number of licenses used. 

Working with versions up to 24-2, these reports are required, but not really enforced. The license is shown in SecureTrack via Menu > Admin > Administrator > Licenses. At the bottom of the screen License Management the section License Usage is shown.

If the option "Send automatic usage reports" is turned on and the system has Internet access, everything is fine. If it's not turned on or connected to the Internet, a manual download of the usage report is recommended. The resulting JSON file is uploaded to the Tufin Portal then. 

Starting with 25-1, the license usage reports are enforced. The screen shown above has changed to this: 

It's now necessary to upload the license usage report to the Tufin Portal - and to get the confirmation code that will be sent by E-Mail after the upload. After having uploaded the code shown in the E-Mail to TOS, a message is displayed that the licenses used has been verified. 

Not following Tufin's guidelines of today, some restrictions regarding the TOS will occur because no Information about Site Usage Monitoring has been supplied: 

  • Not providing Reports for 6 Months:
    There is no possibility to upgrade TOS

  • Not providing Reports for 12 Months: 
    No further use of TOS is possible, even if a valid subscription has been purchased

So the flexibility regarding licenses requires a mandatory upload of License Usage Reports to the Tufin Portal now. It's done here via My Account > Available Licenses > Manual Usage Upload - or if TOS is connected to the Internet, via the automatic upload process. 

 

 

 

 

There are various status messages when backing up the Tufin Orchestration Suite. One of them is 
     IMPAIRED
If any backup is in this status, it's no longer possible to continue working with the data backup.

The reason for this status is a component in the Kubernetes cluster that is not working correctly when the backup has been created. 

To solve the problem, all backups with this status should first be deleted. Then ensure that the TOS cluster is in a good state. No problems should be reported when calling the “tos status” command. Then the backup will work as desired again.

 

 

 

The message "checker failure" might occur when checking the status of the Tufin Orchestration Suite. 

When looking at Tufin's knowledge base, this message is mentioned as "known bug" that is fixed in R24-1 PHF4.1.0 and R24-2 PHF1.0.0, respectively. If you cannot upgrade or get still the message, this procedure might help: 

  • Find as root the pod that is responsible for this message by using the command
    # kubectl get pods -owide | grep node-exporter
    tos-prometheus-node-exporter-zddqg                    2/2     Running     0 …

  • Check this pod, e.g. if it's running (can be skipped)
    # kubectl describe pod tos-prometheus-node-exporter-zddqg
    ...
  • Restarting the pod helps to return to a normal status
    # kubectl delete pod tos-prometheus-node-exporter-zddqg

You can check the status of this pod by using the first command shown above. Please give the pod to start (and to show a status "ok") about two minutes. Checking "tos status" before will still deliver "checker failure" because the pod is still not running well. 

 

 

 

Since TOS Aurora 22-1, there is an option to use a Single Sign On (SSO) for SecureTrack and SecureChange / SecureApp. In new installations, this feature is enabled by default, but in upgraded installations, this feature needs to be enabled manually. This is quite easy, following Tufin Knowledge Base. If SSO is turned on, there is no additional authentication required if a user changes from e.g. SecureTrack to SecureChange.

Enable SSO

To activate SSO access to the command line is necessary. Additionally, administrative permissions are needed (e.g. root or the use of sudo). This command enables SSO:

[Tufin]$ sudo tos config set -p tos.sso.enabled=true

After this action, SSO is active and the login screen shows "Tufin Orchestration Suite".

Sometimes it's useful, to disable SSO (see below).

Disable SSO

Disabling the optional SSO is done using this command with administrative permissions at the CLI (e.g. root or the use of sudo):

[Tufin]$ sudo tos config set -p tos.sso.enabled=false

After this command, a separate login screen is shown for SecureTrack and/or SecureChange - as it has been before for many years.

 

Items to consider when using SSO for SecureTrack and SecureChange

  • The login using the portal shown above requires the user to be configured in SecureTrack.
    If a user is configured in SecureChange only (e.g. Approver, Auditor), a successful login is not possible.
    So these users need to be configured in SecureTrack also (but don't need any permission to view any device).

  • If a disclaimer is required, there is only one possibility to configure it (see also here).

  • If external Servers for authentication are used, please be aware of which server is needed and where users need to be configured. (Special AD branches for user/admin used in SecureTrack vs. separate LDAP authentication in SecureChange).

  • The "old" SSO option for SecureChange is no more supported if SSO for SecureTrack/SecureChange is configured.
    So if a portal is used for SecureChange authentication, this needs to be migrated to use SAML-based authentication.

    > added May, 30th, 2023:
    If you want to use SAML, please consider that there is no support for integration with SAML IDP IBM.

 

 

 

 

 

More Articles …

  1. Logging authentication at Tufin
  2. AERAsec is Tufin SDP+
  3. AERAsec is Tufin Service Delivery Partner
  4. data privacy statement
Page 1 of 2