Provision Namespaces and Buckets to Vault (Step 4)

Step 4 creates the corresponding namespaces, service accounts, and buckets on the vault-side ObjectScale device. This gives copy jobs a destination to write to. Provisioning is a prerequisite before any copy job can run for a protection group.

info

Single pass, no manual account step. Provisioning creates the per-namespace vault service account for you as part of the run (step 2 below), immediately after it creates the namespace.

You do not need to pre-create the target service account in Target Authentication > Target Authentication Service Accounts for a namespace that is new to the vault. A brand-new namespace goes from source to a provisioned vault bucket in a single run.

Pre-creating the account there is still supported. Step 2 then finds it already present.

What Step 4 Does: Full Sequence

When you provision, the console runs this sequence on the vault target device for each namespace covered by the selected buckets:

1. Create namespace. Creates the namespace on the vault ObjectScale device if it does not already exist. This step is skipped (idempotent) if the namespace is already present.
2. Create service account. Creates a per-namespace ObjectScale object user with a deterministic name derived from the namespace: {sanitized-namespace}-vault-svc. For example, namespace prod-data gets user prod-data-vault-svc. This step is skipped if the user already exists. The account becomes the owner of all buckets in the namespace.
3. Generate S3 keys. Generates a new S3 access key and secret key for the service account. This step runs only if the service account was newly created in step 2. If the account already existed, the existing keys are left unchanged.
4. Create bucket. Creates the bucket on the vault ObjectScale device inside the namespace, with the service account as the bucket owner. This step is skipped if the bucket already exists.
5. Apply bucket policy. Sets a bucket policy that grants the service account full read, write, multipart, and delete access to the bucket.
6. Store credentials. Saves the new service account S3 credentials to the console so that copy jobs can authenticate when they write to the vault.

Adding a new bucket to an existing namespace (re-provisioning)

When you provision a new bucket that belongs to a namespace already present on the vault:

• Steps 1 and 2 are skipped, because the namespace and user already exist.
• Step 3 is skipped. Keys are not rotated, so the existing service account credentials stay intact and running copy jobs are not interrupted.
• Steps 4 and 5 run for the new bucket only.

This makes Step 4 safe to re-run at any time.

Service Account Naming Convention

Each namespace on the vault target gets exactly one service account. The username is derived from the namespace name in these steps:

1. Lowercase the namespace name.
2. Replace any non-alphanumeric characters with hyphens.
3. Strip leading and trailing hyphens, and truncate to 53 characters.
4. Append -vault-svc.

Namespace	Service account username
prod-data	prod-data-vault-svc
finance_q1	finance-q1-vault-svc
my_namespace	my-namespace-vault-svc

Names such as prod_data and prod-data map to the same service account name. Avoid namespaces that differ only in this way.

Because the name is deterministic, you can predict the username without running provisioning first. The console, the vault agent, and the target authentication screens all use the same derivation.

Provisioned Column

The Provisioned column shows each bucket's current state:

State	Meaning
Provisioned (green)	The bucket exists on the vault target. Copy jobs can run.
Not provisioned (gray)	The bucket has not been provisioned. Copy jobs fail.

Before provisioning, a reconcile step queries the live vault. It clears any stale "provisioned" flags for buckets that were deleted directly on the vault since the last run.

Selecting a Protection Group

A group is the unit of provisioning. Everything in Step 4 runs against one group's target device at a time.

The — Select a protection group — dropdown lets you select only groups that have a Target Vault Device configured. That field tells the console which vault ObjectScale device to provision against.

Groups with no Target Vault Device appear in the list disabled, labeled <group name> — no Target Vault Device selected, and are sorted to the bottom. If any groups are in this state, a warning banner below the dropdown shows how many. It includes a link to Protection Groups Configuration.

To set the device, go to Source Data Protection Group Config > Protection Groups Configuration, edit the group, and set Target Vault Device.

This applies to any group, including the built-in Default Group. It is seeded without a Target Vault Device, so it is not selectable in Step 4 until you assign one.

How to Provision

Provision selected buckets

1. Switch to Provision Namespaces and Buckets to Vault mode (Step 4).
2. Filter the bucket list to the group you want to provision.
3. Select individual buckets using the checkboxes.
4. If more buckets exist on the server than the current page shows, a blue banner offers Select all N buckets. Click it to select all pages.
5. Click Provision Selected in the action bar.
6. If your ObjectScale configuration requires it, choose the replication group in the confirmation modal.
7. Confirm. The console starts a provisioning job and shows the job ID.

Provision all unprovisioned in a group

1. Filter by the group you want to provision. You do not need to select buckets.
2. Click Provision All Unprovisioned in the action bar.
3. Confirm in the modal. The vault target device is resolved automatically from the group configuration.

Vault Inventory View

Toggle Vault Inventory to switch the bucket table to the live vault target inventory. Use it to verify which namespaces and buckets are actually present on the vault device after provisioning completes.

Workflows

Initial provisioning for a new protection group

1. Assign all buckets to the group (Bucket Browser > Assign mode).
2. Switch to Step 4 (Provision mode).
3. Filter by the new group.
4. Click Provision All Unprovisioned.
5. If you have not done so yet, switch to ACL mode (Step 3) and grant read access on the source ObjectScale device to the source-side service accounts ({ns}-src-svc, created in Source Authentication).
6. Switch to Vault Inventory and confirm that the expected namespaces appear.

Adding new buckets to an existing group

1. Filter by the group the new bucket was added to.
2. Identify the unprovisioned row using the Provisioned column.
3. Select it and click Provision Selected.

The namespace and service account already exist. Only the new bucket is created and its ACL is applied. Existing credentials are not changed.

Preparation Mode vs Vault Mode: Step 4 Banners

When you select a protection group in Step 4, a colored banner shows the group's current operational mode and what happens when you provision.

How the mode is set

The mode of a protection group is set system-wide from Vault Operations > Vault Data Sync Dashboard > Switch to Vault Mode. This action converts all prep-mode protection groups to Vault Mode in one operation and assigns them to the selected vault agent.

You cannot change the mode for a single group from Step 4. It is a group-level setting controlled in Vault Operations.

Amber banner: Preparation Mode (direct ObjectScale)

An amber Preparation Mode — Direct ECS Provisioning banner appears when the selected group is in Preparation Mode. In this mode the console calls the vault ObjectScale device management API directly. This works only when the vault network is reachable from the console.

To switch a group to Vault Mode, go to Vault Operations > Vault Data Sync Dashboard and use Switch to Vault Mode. The banner turns blue on the next page load.

Blue banner: Vault Mode Active (QTP proxy)

A blue Vault Mode Active — Proxy Provisioning via QTP banner appears as soon as you select a vault-mode group, regardless of bucket state.

In this mode the vault network is physically air-gapped, and the console cannot reach the ObjectScale management port directly. All provisioning is routed through the vault agent over the Quantum Trust Protocol (QTP) encrypted heartbeat channel.

Vault Mode Groups: Air-Gapped Provisioning via QTP

When a protection group has Vault Mode active, the vault network is physically air-gapped and the console cannot reach the ObjectScale management port directly. A blue banner appears in Step 4 as soon as you select a vault-mode group.

All policies created for this group in Step 5 are automatically set to Vault Mode. You do not need to select a mode, and you cannot.

What changes in vault mode

The console does not run the provisioning sequence locally. It sends a PROVISION_NAMESPACE QTP message to the assigned vault agent over the ML-KEM-1024 encrypted heartbeat channel.

The vault agent runs the full sequence inside the vault network, using its locally cached ObjectScale credentials. The sequence is namespace, service account, S3 keys, bucket, then ACL.

The sequence is identical to normal provisioning, including the idempotency rules:

• Existing namespaces and service accounts are skipped.
• S3 keys are generated only for newly created service accounts.
• New buckets are created and ACL-applied regardless.

Tracking vault mode provisioning status

No job record is created in the Jobs route. Track status in Vault Operations > Quantum Trust Protocol Audit Log:

• Filter by Provision NS to see when the request was queued (REQUESTED) and delivered to the agent (DELIVERED).
• Filter by Provision ACK to see the outcome once the agent responds.

ACK Status	Meaning
ACKED	All namespaces and buckets were provisioned. New service account keys are stored in the console.
PARTIAL	Some items succeeded. Check the QTP detail errors list to see which stage failed and why.
FAILED	No items were provisioned. The agent could not reach the ObjectScale management port, authentication failed, or device credentials were not yet delivered.

The errors list in a PARTIAL or FAILED record includes:

• The namespace and bucket.
• The stage, for example create_namespace, create_user, create_bucket, or set_acl.
• The HTTP status code.
• The raw ObjectScale error message.

Prerequisites

• The group must have a vault agent assigned.
• The vault agent must have ObjectScale management credentials for the vault device. They are delivered through Credential Delivery in Vault Device Management.
• The agent does not need to be online when you submit. Requests are held in REQUESTED state until the agent's next heartbeat.

Tips

• Provisioning is idempotent and safe to re-run at any time.
• The {ns}-vault-svc accounts created here own the vault buckets. The source read-access policies applied in Step 3 reference the source-side {ns}-src-svc accounts instead, which are created in Source Authentication (Step 2).
• Use Vault Inventory after provisioning for a quick sanity check.
• For vault-mode groups, check Vault Operations > Quantum Trust Protocol Audit Log after you submit to confirm that the request was delivered and acknowledged.