Compliant Kubernetes (CK8S) includes backup functionality through Velero, a backup tool for Kubernetes Resources and Persistent Volumes. For backup of container images, Harbor is used instead.
The requirements to comply with ISO 27001 are stated in ISO 27001:2013. The annexes that are relevant to backups are:
- Annex 12, article A.12.3.1 "Information Backup".
What is Velero?¶
Velero is an open source, cloud native tool for backing up and migrating Kubernetes Resources and Persistent Volumes. It has been developed by VMware since 2017. It allows for both manual and scheduled backups, and also allows for subsets of Resources in a cluster to be backed up rather than necessarily backing up everything.
The following are instructions for backing up and restoring resources.
Compliant Kubernetes takes a daily backup of all Kubernetes Resources in all user namespaces. Persistent Volumes will be backed up if they are tied to a Pod. If backups are not wanted the label
compliantkubernetes.io/nobackup can be added to opt-out of the daily backups.
Application metrics (Grafana) and application log (Kibana) dashboards are also backup up by default.
By default, backups are stored for 720 hours (30 days).
Restoring from a backup with Velero is meant to be a type of disaster recovery. Velero will not overwrite existing Resources when restoring. As such, if you want to restore the state of a Resource that is still running, the Resource must be deleted first.
To restore a backup on demand, contact your Compliant Kubernetes administrator.
Protection of Backups¶
The Compliant Kubernetes administrator will take the following measure to ensure backups are protected:
Backups are encrypted at rest, if the underlying infrastructure provider supports it.
Why? This ensures backups remain confidential, even if, e.g., hard drives are not safely disposed.
Backups are replicated to an off-site location, if requested. This process is performed from outside the cluster, hence the users -- or attackers gaining access to their application -- cannot access the off-site replicas.
Why? This ensures backups are available even if the primary location is subject to a disaster, such as extreme weather. The backups also remain available -- though unlikely confidential -- in case an attacker manages to gain access to the cluster.