Mover permission model

VolSync’s data movers are responsible for copying the data from one location to the other. These data movers run as Pods in the user’s Namespace, where it can have access to the data PVCs that it needs to replicate.

The data movers need to run with sufficient privileges to be able to read and write the affected data. In most cases, running the mover with the same permissions that are granted to the workload in the Namespace is sufficient.

In some cases, it is necessary to run the data movers with elevated privileges. The main example of this is where the UID/GID of files need to be preserved, particularly for ReadWriteMany PVCs. In this case, the mover Pod needs to be granted sufficient capabilities to read/write files regardless of their ownership and to modify that ownership.

The choice of whether to run the data movers as normal users or with elevated privileges depends on the data to be replicated and the security model for the cluster(s).

Affected movers

The current set of movers that support this dual permission model is:

  • rclone

  • restic

  • rsync-tls

  • syncthing

Note

The legacy rsync mover that uses ssh as the transport only supports the elevated permission model.

Controlling mover permissions

The VolSync operator is responsible for managing the data mover Pods and their associated ServiceAccounts. By default, the supported movers will be run with normal user privileges for movers that support this dual permission model.

To signal that the movers in a particular Namespace should be granted additional permissions, an annotation must be added to the user’s Namespace. VolSync checks for the annotation volsync.backube/privileged-movers to see if it has a value of true before granting elevated privileges to the mover Pods.

For example, the following command will annotate a namespace to allow privileged movers:

$ kubectl annotate ns/elevated-demo volsync.backube/privileged-movers=true
namespace/elevated-demo annotated

$ kubectl get ns/elevated-demo -oyaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/sa.scc.mcs: s0:c26,c20
    openshift.io/sa.scc.supplemental-groups: 1000690000/10000
    openshift.io/sa.scc.uid-range: 1000690000/10000
    volsync.backube/privileged-movers: "true"
  creationTimestamp: "2022-12-06T16:34:54Z"
  labels:
    kubernetes.io/metadata.name: elevated-demo
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.24
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.24
  name: elevated-demo
  resourceVersion: "507456"
  uid: 7f3d2184-876b-4f70-9b1d-12462ebda512
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Since the annotation must be added at the Namespace level, cluster administrators can control which Namespaces will have access to movers with elevated permissions.

Mover’s security context

Kubernetes supports setting a security context for Pods (and individual containers) that controls security aspects such as which UID or GID they are assigned or which supplemental groups they are a member of. The VolSync movers can also have their security context configured by setting a PodSecurityContext in the .spec.<mover>.moverSecurityContext field of ReplicationSource and ReplicationDestination objects. This allows matching the permissions of the mover to that of the primary workload in the Namespace.

As general guidance, if the primary workload specifies a security context, that same security context should be used for VolSync.

Privilege escalation when using privileged movers

By default, movers with elevated privileges are not permitted. This is because users with access to the Namespace can leverage the data mover’s ServiceAccount to run their own Pods with the same permissions granted to the data mover. In the case of privileged movers, this would allow normal users to run Pods with a UID of 0 (root) and to gain access to the DAC_OVERRIDE capability, among others.

Using rsync-tls with UID 0

When running unprivileged, the data movers explicitly drop all capabilities to conform to the restricted PSS. For Kubernetes distributions that do not automatically assign non-root UIDs, this causes the data movers to run as UID 0, but without any of the normal “superuser” abilities of root. While most movers are able to handle this case easily, the rsync-tls mover cannot due to a limitation of rsync.

When using rsync-tls, ensure that the mover is either running with a non-zero UID or is run with elevated privileges via the VolSync Namespace annotation.