This is a cache of https://docs.okd.io/4.19/backup_and_restore/application_backup_and_restore/oadp-self-service/oadp-self-service.html. It is a snapshot of the page at 2025-06-21T21:14:32.840+0000.
OADP Self-Service - OADP Application backup and restore | Backup and restore | OKD 4.19
  1. Documentation
×

OADP Self-Service

About OADP Self-Service

From OADP 1.5.0 onward, you do not need the cluster-admin role to perform the backup and restore operations. You can use OADP with the namespace admin role. The namespace admin role has administrator access only to the namespace the user is assigned to.

You can use the Self-Service feature only after the cluster administrator installs the OADP Operator and provides the necessary permissions.

The OADP Self-Service feature provides secure self-service data protection capabilities for users without cluster-admin privileges while maintaining proper access controls.

The OADP cluster administrator creates a user with the namespace admin role and provides the necessary Role Based Access Controls (rbac) to the user to perform OADP Self-Service actions. As this user has limited access compared to the cluster-admin role, this user is referred to as a namespace admin user.

As a namespace admin user, you can back up and restore applications deployed in your authorized namespace on the cluster.

OADP Self-Service offers the following benefits:

  • As a cluster administrator:

    • You allow namespace-scoped backup and restore operations to a namespace admin user. This means, a namespace admin user cannot access a namespace that they are not authorized to.

    • You keep administrator control over non-administrator operations through DataProtectionApplication configuration and policies.

  • As a namespace admin user:

    • You can create backup and restore custom resources for your authorized namespace.

    • You can create dedicated backup storage locations in your authorized namespace.

    • You have secure access to backup logs and status information.

What namespace-scoped backup and restore means

OADP Self-Service ensures that namespace admin users can only operate within their authorized namespace. For example, if you do not have access to a namespace, as a namespace admin user, you cannot back up that namespace.

A namespace admin user cannot access backup and restore data of other users.

The cluster administrator enforces the access control through custom resources (CRs) that securely manage the backup and restore operations.

Additionally, the cluster administrator can control the allowed options within the CRs, restricting certain operations for added security by using spec enforcements in the DataProtectionApplication (DPA) CR.

Namespace admin users can perform the following Self-Service operations:

  • Create and manage backups of their authorized namespaces.

  • Restore data to their authorized namespaces.

  • Configure their own backup storage locations.

  • Check backup and restore status.

  • Request retrieval of relevant logs.

Additional resources

OADP Self-Service custom resources

The OADP Self-Service feature has the following new custom resources (CRs) to perform the backup and restore operations for a namespace admin user:

Table 1. Custom resources

CR

Description

NonAdminController (NAC)

Controls and orchestrates the Self-Service operations.

NonAdminBackup (NAB)

Manages namespace-scoped backup operations.

NonAdminRestore (NAR)

Manages namespace-scoped restore operations.

NonAdminBackupStorageLocation (NABSL)

Defines user-specific backup storage location.

NonAdminDownloadRequest (NADR)

Manages namespace-scoped download request operations.

How OADP Self-Service works

The following diagram describes how OADP Self-Service works at a high level. The diagram describes the following workflow:

  1. A namespace admin user creates a NonAdminBackup (NAB) custom resource (CR) request.

  2. The NonAdminController (NAC) CR receives the NAB CR request.

  3. The NAC validates the request and updates the NAB CR about the request.

  4. The NAC creates the Velero backup object.

  5. The NAC monitors the Velero backup object and cascades the status back to the NAB CR.

OADP Self-Service
Figure 1. How OADP Self-Service works

OADP Self-Service prerequisites

Before you start using OADP Self-Service as a namespace admin user, ensure you meet the following prerequisites:

  • The cluster administrator has configured the OADP DataProtectionApplication (DPA) CR to enable Self-Service.

  • The cluster administrator has completed the following tasks:

    • Created a namespace admin user account.

    • Created a namespace for the namespace admin user.

    • Assigned appropriate privileges for the namespace admin user’s namespace. This ensures that the namespace admin user is authorized to access and perform backup and restore operations in their assigned namespace.

  • Optionally, the cluster administrator can create a NonAdminBackupStorageLocation (NABSL) CR for the namespace admin user.

OADP Self-Service namespace permissions

As a cluster administrator, ensure that a namespace admin user has editor roles assigned for the following list of objects in their namespace. These objects ensure that a namespace admin user can perform the backup and restore operations in their namespace.

  • nonadminbackups.oadp.openshift.io

  • nonadminbackupstoragelocations.oadp.openshift.io

  • nonadminrestores.oadp.openshift.io

  • nonadmindownloadrequests.oadp.openshift.io

For more details on the namespace admin role, see Default cluster roles.

A cluster administrator can also define their own specifications so that users can have rights similar to project or namespace admin roles.

Example rbac YAML for backup operation

See the following role-based access control (rbac) YAML file example with namespace permissions for a namespace admin user to perform a backup operation.

Example rbac manifest
...
- apiGroups:
      - oadp.openshift.io
    resources:
      - nonadminbackups
      - nonadminrestores
      - nonadminbackupstoragelocations
      - nonadmindownloadrequests
    verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
  - apiGroups:
      - oadp.openshift.io
    resources:
      - nonadminbackups/status
      - nonadminrestores/status
    verbs:
      - get

OADP Self-Service limitations

The following features are not supported by OADP Self-Service:

  • Cross cluster backup and restore, or migrations are not supported. These OADP operations are supported for the cluster administrator.

  • A namespace admin user cannot create a VolumeSnapshotLocation (VSL) CR. The cluster administrator creates and configures the VSL in the DataProtectionApplication (DPA) CR for a namespace admin user.

  • The ResourceModifiers CR and volume policies are not supported for a namespace admin user.

  • A namespace admin user can request backup or restore logs by using the NonAdminDownloadRequest CR, only if the backup or restore is created by a user by using the NonAdminBackupStorageLocation CR.

    If the backup or restore CRs are created by using the cluster-wide default backup storage location, a namespace admin user cannot request the backup or restore logs.

  • To ensure secure backup and restore, OADP Self-Service automatically excludes the following CRs from being backed up or restored:

    • NonAdminBackup

    • NonAdminRestore

    • NonAdminBackupStorageLocation

    • SecurityContextConstraints

    • ClusterRole

    • ClusterRoleBinding

    • CustomResourceDefinition

    • PriorityClasses

    • VirtualMachineClusterInstanceTypes

    • VirtualMachineClusterPreferences

OADP Self-Service backup and restore phases

The status.phase field of a NonAdminBackup (NAB) custom resource (CR) and a NonAdminRestore (NAR) CR provide an overview of the current state of the CRs. Review the values for the NAB and NAR phases in the following table.

The phase of the CRs only progress forward. Once a phase transitions to the next phase, it cannot revert to a previous phase.

Table 2. Phases

Value

Description

New

A creation request of the NAB or NAR CR is accepted by the NAC, but it has not yet been validated by the NAC.

BackingOff

NAB or NAR CR is invalidated by the NAC CR because of an invalid spec of the NAB or NAR CR.

The namespace admin user can update the NAB or NAR spec to comply with the policies set by the administrator. After the namespace admin user edits the CRs, the NAC reconciles the CR again.

Created

NAB or NAR CR is validated by the NAC, and the Velero backup or restore object is created.

Deletion

NAB or NAR CR is marked for deletion. The NAC deletes the corresponding Velero backup or restore object. When the Velero object is deleted, the NAB or NAR CR is also deleted.

About NonAdminBackupStorageLocation CR

A namespace administrator can create a NonAdminBackupStorageLocation (NABSL) custom resource (CR) to store the backup data.

To ensure that the NABSL CR is created and used securely, use cluster administrator controls. The cluster administrator manages the NABSL CR to comply with company policies, and compliance requirements.

You can create a NABSL CR by using one of the following workflows:

  • Administrator creation workflow: In this workflow, the cluster administrator creates the NABSL CR for the namespace admin user. The namespace admin user then references the NABSL in the NonAdminBackup CR.

  • Administrator approval workflow: The cluster administrator must explicitly enable this opt-in feature in the DPA by setting the nonAdmin.requireApprovalForBSL field to true. The cluster administrator approval process works as follows:

    1. A namespace admin user creates a NABSL CR. Because the administrator has enforced an approval process in the DPA, it triggers the creation of a NonAdminBackupStorageLocationRequest CR in the openshift-adp namespace.

    2. The cluster administrator reviews the request and either approves or rejects the request.

      • If approved, a Velero BackupStorageLocation (BSL) is created in the openshift-adp namespace, and the NABSL CR status is updated to reflect the approval.

      • If rejected, the status of the NABSL CR is updated to reflect the rejection.

    3. The cluster administrator can also revoke a previously approved NABSL CR. The approve field is set back to pending or reject. This results in the deletion of the Velero BSL, and the namespace admin user is notified of the rejection.

  • Automatic approval workflow: In this workflow, the cluster administrator does not enforce an approval process for the NABSL CR by setting the nonAdmin.requireApprovalForBSL field in the DPA to false. The default value of this field is false. Not setting the field results in an automatic approval of the NABSL. Therefore, the namespace admin user can create the NABSL CR from their authorized namespace.

For security purposes, use either the administrator creation or the administrator approval workflow. The automatic approval workflow is less secure as it does not require administrator review.