Location Configuration

K10 can usually invoke protection operations such as snapshots within a cluster without requiring additional credentials. While this might be sufficient if K10 is running in some of (but not all) the major public clouds and if actions are limited to a single cluster, it is not sufficient for essential operations such as performing real backups, enabling cross-cluster and cross-cloud application migration, and enabling DR of the K10 system itself.

To enable these actions that span the lifetime of any one cluster, K10 needs to be configured with access to external object storage or external NFS file storage. This is accomplished via the creation of Location Profiles.

Profile creation can be accessed from the Settings icon in the top-right corner of the dashboard or via the CRD-based Profiles API.

Location Profiles

Location profiles are used to create backups from snapshots, move applications and their data across clusters and potentially across different clouds, and to subsequently import these backups or exports into another cluster. To create a location profile, click New Profile on the profiles page.

Object Storage Location

As mentioned above, exporting or importing data requires an object storage location. You are therefore required to pick an object storage provider, a region for the bucket if being used in a public cloud, and the bucket name. If a bucket with the given name does not exist, it will be created.

If an S3-compatible object storage system is used that is not hosted by one of the supported cloud providers, an S3 endpoint URL will need to be specified and optionally, SSL verification might need to be disabled. Disabling SSL verification is only recommended for test setups.

Note

When certain cloud providers (e.g., AWS) are selected, provider-specific options (e.g., IAM Roles) will appear for configuration if needed.

When Validate and Save is selected, the config profile will be created and a profile similar to the following will appear:

NFS File Storage Location

Requirements:

• An NFS server reachable from the nodes where K10 is installed

• An exported NFS share, mounted on all the nodes where K10 is installed

• A Persistent Volume defining the exported NFS share similar to the example below:

  apiVersion: v1
  kind: PersistentVolume
  metadata:
     name: test-pv
  spec:
     capacity:
        storage: 10Gi
     volumeMode: Filesystem
     accessModes:
        - ReadWriteMany
     persistentVolumeReclaimPolicy: Recycle
     storageClassName: nfs
     mountOptions:
        - hard
        - nfsvers=4.1
     nfs:
        path: /
        server: 172.17.0.2
  

• A corresponding Persistent Volume Claim with the same storage class name in the K10 namespace (default kasten-io):

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
     name: test-pvc
     namespace: kasten-io
  spec:
     storageClassName: nfs
     accessModes:
        - ReadWriteMany
     resources:
        requests:
           storage: 10Gi
  

Once the above requirements are met, an NFS FileStore location profile can be created on the profiles page using the PVC created above.

When Validate and Save is selected, the config profile will be created and a profile similar to the following will appear:

Location Settings for Migration

If the location profile is used for exporting an application for cross-cluster migration, it will be used to store application restore point metadata and, when moving across infrastructure providers, bulk data too. Similarly, location profiles are also used for importing applications into a cluster that is different than the source cluster where the application was captured.

Note

In case of NFS File Storage Location, the exported NFS share must be reachable from the destination cluster and mounted on all the nodes where K10 is installed.

Immutable Backups

Warning

This feature is preview-only and should NOT be used in production until the general-availability release. Please contact support with any questions.

The frequency of ransomware attacks on enterprise customers is increasing. Backups are essential for recovering from these attacks, acting as a first line of defense for recovering critical data. Attackers are now targeting backups as well, to make more difficult, if not impossible for their victims to recover.

K10 can leverage object-locking and immutability features available in many object store providers to ensure its exported backups are protected from tampering. When exporting to a locked bucket, the restore point data cannot be deleted or modified within a set period, even with administrator privileges. If an attacker obtains privileged object store credentials and attempts to disrupt the backups stored there, K10 can restore the protected application by reading back the original, immutable and unadulterated restore point.

Enabling the Immutable Backups Feature

Enable the Ransomware Protection setting on the features page. Assuming K10 is deployed with the release name k10 and the URL for accessing K10 is https://example.com/k10, the features page will be available at https://example.com/k10/#/features.

Locked Bucket Setup

To prepare K10 to export immutable backups, a bucket must be prepared in advance.

• The bucket must be created with object locking enabled (a property that can only be applied at creation time).

• The bucket must have a default retention configuration applied. This is the immutable retention period that will be applied to any new objects written to the bucket.

• The default retention period must be at least 5 days long. The longer the default retention period, the longer the data protection period K10 can offer (more info below).

• The default retention mode must be Compliance.

A sample Minio CLI mc script that will set up an immutable-backup-eligible locked bucket in AWS S3:

# Set up the following variables:
BUCKET_NAME=<choose a unique bucket name>
REGION=<pick the region for the bucket>
RETENTION_PERIOD=<desired default retention period, 30 days is formatted as "30d">
AWS_ACCESS_KEY_ID=<access key ID>
AWS_SECRET_ACCESS_KEY=<secret access key>

# Alias the s3 account credentials
mc alias set s3 https://s3.amazonaws.com ${AWS_ACCESS_KEY_ID} ${AWS_SECRET_ACCESS_KEY}

# Make the bucket with locking enabled
mc mb --region=${REGION} s3/${BUCKET_NAME} --with-lock

# Set the bucket default retention configuration in compliance mode with the chosen period
mc retention set --default compliance ${RETENTION_PERIOD} s3/${BUCKET_NAME}

For more information on setting up object-locking: * Using S3 Object Lock

Profile Creation

Once a bucket has been prepared with each of these requirements met, a profile can be created from the K10 dashboard to point to it.

Follow the steps for setting up a profile as normal. Enter a profile name, object store credentials, region, and bucket name.

It is recommended that the credentials provided to access the locked bucket are granted minimal permissions only:

• List objects

• Get object lock configuration

• Get/Put object retention

• Get/Put/Remove object

  

After selecting the checkbox labeled "Enable Immutable Backups" a new button labeled "Validate Bucket <bucket-name>" will appear. Click the Validate Bucket button to initiate a series of checks against the bucket, verifying the bucket can be reached and meets all of the requirements denoted above. All conditions must be met for the check to succeed and for the profile form to be submitted.

If the provided bucket meets all of the conditions, a Protection Period slider will appear. The protection period is a user-selectable time period that K10 will use when maintaining an ongoing immutable retention period for each exported restore point. A longer protection period means a longer window in which to detect, and safely recover from, an attack; backup data remains immutable and unadulterated for longer. The trade-off is increased storage costs, as potentially stale data cannot be removed until the object's immutable retention expires.

K10 limits the maximum protection period that can be selected based on the default retention period in the bucket and an additional safety time period of 20 days. The allowed protection period must be less than or equal to the bucket's default retention period minus the 20 day safety time window. This is to ensure K10 can always find and maintain ongoing protection of any new objects written to the bucket before their retention lapses. Therefore minimum default retention period that a bucket must have is 21 days, which permits a 1 day protection period.

If the protection period slider does not reach the desired protection period, increase the default bucket retention period in the bucket, then re-initiate the validation check by clicking the "Validate Bucket <bucket-name>" button. The slider should now reflect the new maximum protection period allowable from the updated default bucket retention.

Push the "Save Profile" button. The profile will be submitted to K10 and will appear in the list of Location Profiles. The card will reflect the object immutability status of the referenced bucket, as well as the selected protection period. This profile can now be selected as an export destination, and any restore points exported there will be immutable and protected for the selected protection period.

A bit more about the Protection Period

Q: If a backup is exported on January 1st using a profile with a 30 day Protection Period, does that mean on January 31st that backup is no longer protected by data immutability?

A: Not at all. The Protection Period is a moving window representing continuous refreshment of the immutable protection of the underlying data. This means a backup will be protected by immutability from the moment it's exported until the day it's retired. The longer the protection period, the more immutable time is applied to the underlying data each time it's refreshed.

Instead, the time associated with the Protection Period dictates the timeline for detection of, and recovery from, a data loss event, such as a ransomware attack. For example, if an attack occurs on July 1st, a bucket with a 30 day protection period will ensure that any earlier backup, whether it was taken the prior day or the prior year, can be restored with full fidelity any time until July 31st. Beyond that window, the integrity of the data cannot be guaranteed, so it would be advisable to choose a Protection Period that would leave ample time to detect and respond to an attack.

Q: Why is the Protection Period limited by the bucket's Default Retention Period? Why can't an arbitrary Protection Period be chosen?

A: It comes down to being able to guarantee the specified protection period. The promise is that if the data comes under attack at time t, the exported backup will be accessible, unadulterated, until t + protection period.

If a protection period larger than the default retention period was allowed, then the desired protection period cannot be guaranteed. For example, if the default retention period was 1 day, and the protection period was 300 days, any new backup data written to the object store would, for some perceptible period of time, only have 1 day of immutable protection. This would obviously be in violation the 300 day protection claim.

Therefore K10 requires that the bucket default retention period must be longer than the requested protection period (and then some). This is so K10 can maintain that no matter when an attack occurs, the data is immutable and safe for at least that amount of time after the event.