Preparing for SaaS application data protection
Before you start protecting your Google Artifact Registry data, complete the following steps:
Getting familiar with your SaaS application specifics
Before you start protecting your Google Artifact Registry data, you must get familiar with all prerequisites, limitations, considerations, and/or recommendations in this topic to make sure that your environment is prepared and configured correctly.
Prerequisites
Authentication service account permissions
The authentication service account that you create while adding the SaaS module as a source in R-Cloud must be granted the minimum permissions set in the Google Cloud projects that contain the repositories that you plan to protect, or on the locations where the new repositories are going to be created.
The following permissions must be included:
-
artifactregistry.dockerimages.get
-
artifactregistry.dockerimages.list
-
artifactregistry.projectsettings.get
-
artifactregistry.repositories.create
-
artifactregistry.repositories.delete
-
artifactregistry.repositories.downloadArtifacts
-
artifactregistry.repositories.get
-
artifactregistry.repositories.list
-
artifactregistry.repositories.uploadArtifacts
-
artifactregistry.tags.delete
-
compute.zones.list
-
iam.serviceAccounts.actAs
-
iam.serviceAccounts.get
-
resourcemanager.projects.list
-
storage.buckets.get
-
storage.objects.create
-
storage.objects.get
-
storage.objects.list
Instead of granting the individual permissions, you can also assign the following roles to the authentication service account:
-
Artifact Registry Admin
-
Compute Admin
-
Service Account User
-
Storage Admin
Note Assigning roles might grant permissions that exceed the required minimum permissions for the service accounts.
The following APIs are required:
-
Artifact Registry API
-
Compute Engine API
-
Cloud Storage API
Limitations
-
Only the Artifact Registry repositories in Docker or NPM formats can be protected.
-
The following configurable metadata is not protected:
-
Immutable image tags
-
Docker images inside the remote repository
-
Docker images inside the virtual repository
-
-
When creating a new Google Cloud Function, the Cloud Function automatically creates a Docker repository within the Artifact Registry. These automatically created repositories are not protected by the module.
Note If you plan to back up Google Cloud Functions, see Protecting Google Cloud Functions data.
-
You cannot assign a policy that has Snapshot specified as the backup target type to this type of SaaS application.
-
The repository resources cannot be restored to a remote or to a virtual repository types. For these two repository types, the module can only back up and restore the repository configuration. If the Override Repository option is enabled during the restore, none of the potential resources will be restored.
-
The virtual repositories with virtual upstream policies can only be restored in the same region as specified for the upstream policies. In this case, the region selection is disabled.
-
Restoring the remote repositories from a multi-region environment to a single region is not supported.
-
You can only publish a specific version of the NPM package to a repository once. As a result, you cannot:
-
Overwrite a package version by publishing it again to the repository.
-
Remove a package or its version from the repository, and then publish a package with the same name and version number.
For details, see Node.js documentation.
-
Backing up SaaS application data
Limitation
Only backup data can be stored to the automatically created targets (and not copies of backup data or archive data).

To access the SaaS panel, in the navigation pane, click SaaS.
-
Select the SaaS applications and/or resources that you want to back up.
Note If you want to narrow down the list of displayed SaaS applications, use the filtering options as described in Filtering and sorting data.
- Click
Set Policy. The Set Policy dialog box opens.
-
From the list of available policies, select the preferred policy.
-
Click Assign to assign the policy to the selected SaaS applications and/or resources.
After you assign a policy to a SaaS application, a backup task starts immediately. Subsequent backups are scheduled according to the values defined in the policy.
If required, you can also perform a manual backup of individual SaaS applications and/or resources at any time. For details, see Performing manual backups.