Introduction

IBM Storage Deep Archive is an on‑premises, object‑to‑tape archival solution designed for long‑term data retention at scale. It provides an S3‑compatible object storage interface as the front‑end, while leveraging enterprise‑class tape technology as the back‑end storage tier.

From an application perspective, Deep Archive behaves like an S3 object store. Applications authenticate using S3 credentials, create buckets, upload objects, and restore/download data through standard S3 APIs with Glacier Flexible Retrieval storage class. The complexity of tape media management and data placement is abstracted away and handled internally by the system.

As a result, S3 client applications require no tape‑specific knowledge, and the system is designed so that storage administrators can manage it as simply as possible.

In many environments, a single Deep Archive system is shared by multiple S3 users. In such cases, controlling access at the S3 API level becomes a key requirement. This article focuses on how S3 user access control is implemented in IBM Storage Deep Archive using S3 bucket policies.

S3 User Access Control with an S3‑Compatible Interface

IBM Storage Deep Archive implements access control at the S3 interface layer. The model is aligned with AWS S3, where:

• Users authenticate using S3 access keys

• Buckets act as logical containers for data

• Access permissions are defined using bucket policies

This approach allows customers to reuse existing S3 knowledge, tools, and application logic. However, there is one difference in the way user identities are managed, which is described in the next section.

User Management Without AWS IAM

Unlike AWS S3, IBM Storage Deep Archive V1.3.0 (released in Jan 2026) does not provide the AWS Identity and Access Management (IAM) service. Instead, user identities are managed by the Deep Archive management CLI. When a user is created using the CLI with programmatic access enabled, Deep Archive generates an S3 access key and an S3 secret key. These credentials are used for authentication when issuing S3 API requests.

Bucket Ownership and Default Access Behavior

In V1.3.0, a Deep Archive user can create a bucket and becomes the bucket owner. By default, only the bucket owner can:

• list the bucket and objects within the bucket

• put objects to that bucket

• restore and get objects from the bucket

• delete objects in the bucket

From a system administration perspective, storage administrators can view all buckets using the Deep Archive management CLI. However, from S3 user perspective, each user can see and access only the buckets they own. Thus, S3 users are isolated by bucket-level. This behavior provides a baseline for user separation without requiring additional configuration.

Granting Access Using S3 Bucket Policies

To enable controlled access beyond the default ownership behavior, Deep Archive supports the standard S3 PutBucketPolicy operation. A bucket owner can explicitly grant permissions to other users by setting a bucket policy.

A bucket policy can further define which S3 operations are allowed for which users. In addition, as with AWS S3, policies can control access and allowed S3 operations at the object key prefix level. For example, access can be granted to objects whose key names start with a specific prefix within a bucket (for example, bucket name = “mybucket”, key name = “teamA/*”). In summary, this mechanism allows:

• Controlled sharing of buckets between users

• Authorization for S3 actions

• Access control at object key prefix level

Bucket policies are defined in JSON and applied to the bucket.

Example 1 — Bucket-Level Access Control

A Deep Archive user “s3user1” has created a bucket “bucket1” and is the owner.

To grant access to s3user2, s3user1 can apply the following policy to bucket1.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["s3user2"]
      },
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::bucket1"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["s3user2"]
      },
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
	"s3:RestoreObject",
	"s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::bucket1/*"
    }
  ]
}

This allows s3user2 to

• See bucket1 by S3 ListBuckets

• See objects in bucket1 by S3 ListObjectsV2

• Do S3 PutObject, GetObject, RestoreObject, DeleteObject to all objects in bucket1

Example 2 — Prefix-Level Access Control

A Deep Archive user “s3user1” has created a bucket “bucketcommon” and is the owner.

The s3user1 can apply the following policy to bucket1 for prefix-level control that would allow s3user2 to access bucketcommon/s3user2/* and s3user3 to access bucketcommon/s3user3/*.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": ["s3user2"] },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::bucketcommon"
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": ["s3user2"] },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:RestoreObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::bucketcommon/s3user2/*"
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": ["s3user3"] },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::bucketcommon"
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": ["s3user3"] },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:RestoreObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::bucketcommon/s3user3/*"
    }
  ]
}

Summary

IBM Storage Deep Archive provides S3‑compatible, user access control that closely follows the AWS S3 bucket and policy model.