Grant Cyber Vault Service Accounts Data Access (ACL Mode)

The Grant Cyber Vault Service Accounts Data Access ACL Policy to source buckets mode applies or revokes read-access bucket policies on source buckets.

This grants the source-side service account the permissions it needs to read object data from the source ObjectScale system. The account is created per namespace during Source Authentication provisioning.

Why This Is Required

Copy jobs authenticate to the source device using per-namespace service accounts. These accounts are created on the source ObjectScale device during Source Authentication provisioning.

Account names follow these patterns:

• New deployments use the deterministic name {sanitized-namespace}-src-svc. For example, namespace prod-data gives the user prod-data-src-svc.
• Legacy deployments use sequential names such as cybersourcesvc1 and cybersourcesvc2. These continue to work unchanged.

These accounts are distinct from the target-side {ns}-vault-svc accounts (legacy cybervaultsvcN), which own the vault buckets.

Before a copy job can read from a source bucket, the source ObjectScale device must have an bucket policy attached to that bucket. The policy must grant the source-side service account read access.

Without this step, copy jobs fail with permission errors when they try to list or read objects from the source.

How to Apply Bucket Policies

1. Select a source device from the device dropdown at the top of the filter bar. This is mandatory because the console connects directly to the source device to apply the policy.
2. Optionally, filter by namespace or protection group to narrow the bucket list.
3. Select the buckets you want to grant access to using the checkboxes.
4. Click Grant Read Access Policy in the action bar.
5. Confirm in the modal. It shows the exact buckets and service account that will be granted access.

The console submits an ACL job. A result banner shows the job ID and a link to track progress.

ACL Status Column

The Source ACL column in the bucket table shows the current grant state for each bucket.

Status	Meaning
Access Granted (green shield)	The service account has read access to this bucket. The account name is shown below the status.
Pending (lock)	No bucket policy has been applied yet.

Click Revoke to remove the bucket policy from a single bucket.

Pre-existing Policy Detection

The console can show which source buckets already carry a customer-defined S3 bucket policy before you grant access. You then know that a grant will merge into an existing policy rather than create a new one.

info

Detection reads the bucket policy only. It does not read the bucket ACL.

ObjectScale has two independent access mechanisms on a bucket. The bucket policy is what the console reads, writes, merges, and restores. The older per-user bucket ACL grid is at ObjectScale > Bucket Management > Bucket ACLs Management, with its User, Group, and Custom Group tabs. The console never reads or modifies the bucket ACL.

A bucket whose users are granted access only through the ACL grid, and which has no policy, correctly shows nothing in the Pre-existing Policy column.

How the column is populated

• Detect pre-existing policies button. Select buckets and click Detect pre-existing policies in the action bar. This starts a read-only scan that checks each selected bucket for an existing policy and fills in the column. It does not apply, merge, or change anything on ObjectScale. Run it before granting to see the pre-existing state.
• As part of a grant. The apply job runs the same scan as its first step, so the column is also refreshed whenever you grant.

Only buckets that are not yet granted are scanned. Running Detect again on such a bucket always reflects the current policy. If the customer changed the policy since the last scan, the snapshot is refreshed. If the customer removed the policy, the Detected badge clears. This keeps what a later grant merges, and a later revoke restores, up to date.

Reading the column

• Buckets that already have a policy show an amber Detected badge.
• Click the Detected badge to view the customer's original policy JSON. It was captured from the bucket before provisioning began. This is the exact snapshot that is restored if you later revoke access.
• Buckets with no pre-existing policy show nothing.

A filter toggle in the filter bar limits the table to buckets with a detected pre-existing policy.

Merge Behavior

When a bucket already has a policy, the apply step merges the read-access statement into the existing policy. It does not replace the policy. The customer's original policy statements are preserved exactly as they were.

The merged policy contains:

• The original customer statements.
• The new AllowVaultAgentReadAccess statement, which grants the source service account ({ns}-src-svc) read access. Older deployments use cybersourcesvcN. The copy agents use this account to read the bucket.

The merge is idempotent. When you re-run apply on an already provisioned bucket that has a pre-existing policy, the existing vault agent statement is removed before the current one is appended. This prevents duplicates.

To verify the merge, click the View merge link in the Source ACL column on provisioned rows where a pre-existing policy was detected. It fetches the current live policy from ObjectScale and shows it side by side with the original pre-existing snapshot. You can confirm that both sets of statements are present.

Revoking Access

Click Revoke on any row with the Access Granted status to remove the service account's read access from that bucket. A confirmation prompt appears before the revoke is submitted.

What happens depends on whether the bucket had a policy:

• The bucket had a pre-existing policy. Revoking fully restores the original policy. The customer's original statements are put back exactly as captured during the scan step, and the read-access statement is removed.
• The bucket had no prior policy. The policy is deleted entirely. A 404 response from ObjectScale is treated as success.

Workflows

Grant access to all buckets in a group

1. Switch to ACL mode.
2. Select the source device.
3. Filter by the protection group you just provisioned.
4. Use the Select All checkbox to select all visible buckets on the current page.
5. If more buckets exist on the server, click the blue Select all N buckets banner to select all pages.
6. Click Grant Read Access Policy and confirm.
7. Repeat for each source device and group combination.

Virtual select-all behavior

When you select every row on the current page and more rows exist on the server, a blue banner appears below the filter bar. Click the banner link to select all server-side rows. The action bar then shows the full count and a Clear link.

When you submit Grant Read Access Policy in this mode, the console fetches all matching pages from the server in parallel, 1000 rows per page. It resolves the complete list of bucket IDs before it opens the confirmation modal. You do not need to click Load More.

Virtual select-all resets when you change a filter, change the page, or toggle an individual row.

Add new buckets later

1. Filter by group and the specific namespace or bucket name.
2. Select the new buckets.
3. Click Grant Read Access Policy.

Tips

tip

Apply bucket policies after the source-side service accounts exist (Service Account Configuration > Source Authentication Service Accounts). The policy references the source account of each bucket's namespace.

tip

The ACL apply step needs to run only once per bucket, unless the bucket's namespace service account changes.

tip

If copy jobs report permission errors on buckets that worked before, check two things. The ACL may have been revoked by accident, or the service account may have been recreated with a different ID.

tip

After you apply to buckets with the Detected badge, use View merge to confirm that both the customer's original statements and the read-access statement are in the live policy on ObjectScale.

tip

To restore a customer's original policy without vault agent access, click Revoke. The original policy is fully restored from the snapshot taken at scan time.