Applying Data Transformation Key Rotation to CTE for Kubernetes

Data encryption keys are the keys used to encrypt data in a GuardPoint. Key rotation is the process of changing the encryption key used to encrypt your GuardPoint data. Key Rotation is also called Rekeying. Changing GuardPoint encryption keys increases security. Rekeying with Data Transformation requires that you change the current key of the production policy on your GuardPoint to a new key.

Performing a Key Rotation

Delete Pods and PVC

1. Delete all of the application pods which are using cte-claim:

   kubectl delete -f <applicationPodName>.yaml
   

   Note

   Users can also use the CTE PVC (# kubectl describe pvc <CTE-PVC>) to find the list of all of the pods that are using a specific CTE PVC.

2. Delete the CTE PVC:

   kubectl delete -f cte-csi-claim.yaml
   

Create New Polices and Keys

Create a new Data Transformation and a new production Policy, with required Key rules on CipherTrust Manager.

Alternatively, (recommended), clone the original policies, (Data Transformation and Production policy) that you used to encrypt the data.

• If creating new policies, make sure to set Policy Type: CTE for Kubernetes.

• Toggle the Data Transformation button to on while creating the Data Transformation policy.

• Toggle the Data Transformation button to off while creating the production policy.

Updating Key Rules

Update the key rules, for both policies, by editing the Key Rule, and the Data Transformation Rule, and changing the Current Key Name and Transformation Key Name to reflect the new key to use.

For Example:

If the GuardPoint data is encrypted with Key1, and you want to rotate the key from Key1 to Key2:

Data Transformation clone/new policy key rule update:

    Key Rules (Current Key Name): key1
    Data Transformation Rules(Transformation Key Name): key2

Production clone/new policy key rule update:

    Key Rules(Key Name): key2

Applying the New/Cloned Policies

1. Add the newly created/cloned policies to CipherTrust Manager K8s Storage Groups. See Configuration Concepts for more information about creating CTE for Kubernetes storage groups in CipherTrust Manager.

2. Update the data transformation and production policy names in the CTE claim yaml file (cte-csi-claim.yaml) with the following annotations.

   csi.cte.cpl.thalesgroup.com/dataxform_policy:   <NewDataxformPolicy>    // newly created dataxform policy
   csi.cte.cpl.thalesgroup.com/policy:             <NewProductionPolicy>  // newly created production policy
   

   Example

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
       name: cte-claim
       annotations:
           csi.cte.cpl.thalesgroup.com/dataxform_policy: dataxform-key1-to-key2-rotation-policy  // newly created dataxform standard policy
           csi.cte.cpl.thalesgroup.com/policy: csi-prod-with-key2-policy    // newly created production policy
           csi.cte.cpl.thalesgroup.com/source_pvc: nfs-test-claim   // nfs source persistent volume claim spec:
       storageClassName: <CHANGEME to the storageclass name deployed e.g. csi-test-sc>
       accessModes:
           - ReadWriteMany
       resources:
           requests:
               storage: 1Ki
   

3. Deploy the CTE claim file cte-csi-claim.yaml:

   kubectl apply -f cte-csi-claim.yaml
   

4. Add the dataxform_cleanup annotation to the NFS source PV from nfs-pv.yaml. See Create a Persistent Storage (PV) YAML file description for more information.

   # kubectl annotate pv <SOURCE_PV_NAME> csi.cte.cpl.thalesgroup.com/dataxform_cleanup='require'
   

   **<SOURCE_PV_NAME>**: PersistentVolume name from nfs-pv.yaml file

5. Deploy the Application Pod which uses the cte-claim.

   # kubectl apply -f <applicationPodName>.yaml