Rotating Encryption Keys While a Rekey is in Progress (Relaunch)

On Linux, if a key is rotated (either manually or automatically when a key version expires) while CTE-LDT is in progress on a GuardPoint, the key rotation is processed and queued, and the GuardPoint is marked for relaunch. Relaunch indicates the need to restart CTE-LDT after the current transformation completes. If the GuardPoint has been rekeyed and is flagged for relaunch, CTE-LDT launches as soon as the GuardPoint is enabled.

When this event occurs, the following message appears in the log file: "LDT: Deferred key rotation on GuardPoint [GuardPoint] until after completion of current transformation."

When the new key rotation request is queued, files can be in one of three states:

• Undergoing rekey to a previous key: Files already undergoing transformation to a previous key when the new rekey request is queued, are rekeyed to the key version already in progress.

• Scheduled for rekey to a previous key: Files that start transformation after the new key rotation request is queued are rekeyed to the newest key version.

• Rekeyed to a previous key: Files that have already been rekeyed to a previous key remain in that state until all files undergoing rekey, or scheduled for rekey, have been processed. Once the current CTE-LDT process for the GuardPoint is complete, CTE-LDT automatically relaunches to transform any files that are not rekeyed to the latest key version. This includes any files that were rekeyed before the new key rotation request was queued, or that were undergoing transformation when the new key request was queued.

For example:

voradmin ldt attr get /oxf-fs1/gp1
LDT stats: version=2, rekey_status=rekeying,relaunch
    Number of times rekeyed:                1 time
    Rekey start time:                       2024/03/18 16:54:00
    Last rekey completion time:             2024/03/18 16:53:38
    Estimated rekey completion time:        0 days 0 hours 6 minutes
    Policy key version:                     344
    Data stats:
       total=9.8GB, rekeyed=0.0MB
       truncated=0.0MB, sparse=0.0MB
    File stats:
        total=1000, rekeyed=0, failed=0
        passed=0, skipped=0, created=0, removed=0, excluded=0

Relaunch when Directories are renamed

Prior to v7.6.0, when a user renamed a directory, LDT would set a relaunch flag on the GuardPoint during the scan phase of LDT. This relaunch flag would trigger an additional LDT process on the GuardPoint when the current transformation job completed.

As the transformation process can impose significant overhead on production workloads, subsequent relaunch of LDT, as the result of renaming directories, is not efficient.

CTE v7.6.0 records renamed directories during the scan phase, so it can locate the files relocated to other paths during the rekeying phase of LDT. This prevents the GuardPoint from going through another transformation due to the directory being renamed during the scan.

Limitation

You can only rename a maximum of 16 concurrent directories without triggering a relaunch. If more than 16 concurrent directories are renamed during the scan phase, LDT sets the relaunch flag on the GuardPoint.