It is possible to set an Expiration Date within e.g. an Access Request Ticket in Tufin SecureChange. This Expiration Date has a default value of 180 days, i.e. half a year. To increase this time limit, access to the pod and database is necessary. The Expiration Date can be set up to a limit of 10 years. This is useful for rules that shall be valid "forever".
Please be aware that users might not be able to work with SecureChange due to a (necessary) restart of the pod
To change the maximum Expiration Date, these steps are recommended:
- Check the currently configured time for the Expiration Date:
# sudo kubectl exec -it stolon-keeper-0 -- psql -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration"
A list of value is shown. Look for an entry like this:
-[ RECORD 1 ]-+------------------------------------
id | 10
key | expirationField.maxExpirationPeriod
value | 180
default_value | 180
If this key doesn't show up, it's useful to filter for the key using the command
# sudo kubectl exec -it stolon-keeper-0 -- psql -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where key='expirationField.maxExpirationPeriod'"
At least then the record shown above will be displayed, the relevant ID can be found out this way. - If the record has been found, the value for the maximal Expiration Date can be set with the command
# sudo kubectl exec -it stolon-keeper-0 -- psql -h stolon-sc-svc securechangeworkflow -xc "update general_configuration set value='36000' where id='10'"
The ID needs to be adapted to the result of the step before. In this example, the time is set to approximately 10 years which is the maximum time supported by Tufin - After having set the time it's useful to check the entry in the database again
# sudo kubectl exec -it stolon-keeper-0 -- psql -h stolon-sc-svc securechangeworkflow -xc "select * from general_configuration where id='10'"
Again, the ID is 10, as shown in the example above.
-[ RECORD 1 ]-+------------------------------------
id | 10
key | expirationField.maxExpirationPeriod
value | 3600
default_value | 180
- In TOS Classic it was necessary to restart the Tomcat Server. In TOS Aurora, the pod needs to be deleted. Once done this, the pod will start again - using the newly set value.
First, the exact name of the pod needs to be found using the command
# sudo kubectl get pods | grep sc-server
sc-server-a76994ab9-98236 3/3 Running 0 19m
(the number shown with the pod varies, so here it's an example only). Once found, this pod should be deleted using
# sudo kubectl delete pod sc-server-a76994ab9-98236 - It's useful to check the restart and watch the pod coming up again
# sudo kubectl get pods | grep sc-server
After the successful restart of the pod, It's possible to take the new (maximum) value within tickets.