Security Requirements

K10 requires additional privileges to efficiently backup and restore applications due to the nature of backup, recovery, and migration operations. This article contains descriptions and motivation for all the privileges required by K10.

Permissions Requirements

K10 requires the following capabilities for both the K10 installation namespace (default: kasten-io) and the target application's namespace:

  • DAC_OVERRIDE: Allows to read the data on the volume regardless of the permissions set. K10 needs this capability to read all the data from the volume.

  • FOWNER: Allows to change owner (chown) of the files and directories. This capability allows K10 to correctly restore the owner of the entity following the restore process.

  • CHOWN: Allows to change permissions (chmod) of files and directories. This capability allows K10 to correctly restore access permissions for the entity following the restore process.

See Linux Capabilities for a detailed description of the above capability requirements.

runAsUser, runAsGroup

K10 runs pods with UID = 1000 and GID = 1000, which need to be permitted by the security policies.

Additionally, it might be required to allow the default Grafana and Prometheus UID\GID.

See Monitoring for information about Grafana and Prometheus usage.


If the StorageSecurityContext is used, userId and groupId fields should be permitted to be used as values for runAsUser(userId) and runAsGroup(groupId) fields by the security policies. In addition, groupId and supplementalGroup should be permitted as fsGroup values.


Value 1000 for fsGroup parameter should be allowed by security policies. During the restore phase, K10 creates a volume for restoring data and sets fsGroup = 1000 to the internal restore-data-* pod's securityContext so that data can be written to that volume.

NFS Location Profile

If the NFS location profile is used in rootless mode, the security policies must allow the supplementalGroup used by the profile.

See NFS Location Profile for details.