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

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.

Immutable backups are supported for AWS S3 and other S3 compatible object stores.

More information on the full Immutable Backups Workflow.

Locked Bucket Setup

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

• The bucket must be created on AWS S3 or an S3 compatible object store.

• 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 21 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.

Protecting applications with Immutable Backups

Selecting the locked bucket profile as the Export Location Profile in the Backups procedure will render all application data immutable for the duration of the protection period. Additionally, to ensure K10 can restore that application data, K10 should also be protected with an immutable locked-bucket Disaster Recovery (DR) profile.

In a situation where the cluster and/or object store has been corrupted, attacked, or otherwise tampered with, K10 might be just as susceptible to being compromised as any other application. Protecting both (apps and K10) with immutable locked-bucket profiles will ensure the data is intact, and that K10 knows how to restore it. Therefore, if one or more locked bucket location profiles are being used to back up and protect vital applications, it is highly recommended that a locked bucket profile should also be used with K10 DR.

When setting up a location profile for K10 DR, one should choose a protection period that is AT LEAST as long as the longest protection period in use for application backups. For example if one application is being backed up using a profile with a 1 week protection period, and another using a 1 year protection period, the protection period for the K10 DR backup profile should be at least 1 year to ensure the latter application can always be recovered by K10 in the required 1-year time window.

See Restore K10 Backup for instructions on how to restore K10 to a point-in-time.