Access Control Model in StorageRaya (ACL vs IAM)

StorageRaya is an S3-compatible Object Storage service, but its access control model differs from public cloud providers that use centralized IAM policy engines.

This page explains how access control works in StorageRaya, what it supports, what it does not, and how to design secure access patterns using buckets, credentials, and ACLs.

Understanding this model helps you avoid incorrect assumptions and design systems that are secure, predictable, and easy to operate.

Two Common Access Control Models

Object storage platforms generally follow one of these approaches:

1️. IAM-Based Model (Public Cloud Pattern)

Used by providers such as AWS S3.

Characteristics:

• Centralized identity system (IAM users, roles, policies)
• Fine-grained, API-level permissions
• Policies define exactly which actions are allowed:
  • GetObject
  • PutObject
  • DeleteObject
  • ListBucket
• Access is controlled by attaching policies to identities

Strengths:

• Very granular control
• Strong for large enterprises with complex compliance needs

Complexity:

• Requires policy management
• Higher operational overhead

2️. ACL-Based Model (StorageRaya Pattern)

Used by StorageRaya and many S3-compatible storage platforms.

Characteristics:

• Access is scoped at the bucket and object level
• Credentials are issued per bucket
• Permissions are controlled using:
  • Bucket ownership
  • Object and bucket Access Control Lists (ACLs)
• No centralized IAM policy engine

Strengths:

• Simple and predictable
• Easy to operate
• Clear separation between workloads

Trade-off:

• Less granular control at the individual API-action level

How Access Control Works in StorageRaya

In StorageRaya:

• Buckets are the primary security boundary
• Each bucket has its own:
  • Access credentials
  • Ownership
  • ACL configuration
• Applications authenticate directly to a bucket using:
  • Access Key
  • Secret Key

What You Can Control

• Who can access a bucket
• Whether objects can be:
  • Read
  • Written
  • Listed
• Whether objects are public or private

What You Cannot Control

StorageRaya does not provide:

• IAM users or roles
• Policy documents
• Per-API action permissions (for example, “allow PutObject but deny GetObject”)

Security Design Implications

Because StorageRaya does not use an IAM policy engine, security design shifts from identity-based control to architecture-based isolation.

Primary Design Tools

You secure access by using:

• Separate buckets per workload
• Separate credentials per system or application
• ACLs for object and bucket visibility
• Environment separation (dev / staging / prod)

This creates clear, enforceable boundaries without complex policy systems.

Recommended Access Design Patterns

Pattern 1: One Bucket per Workload

Example:

app-uploads-prod
app-uploads-staging
backups-prod
media-public

Benefits:

• Strong isolation
• Simple mental model
• Easy auditing and cleanup

Pattern 2: One Credential per System

Example:

• Web application → app-prod-key
• Backup system → backup-prod-key
• Analytics pipeline → analytics-key

Benefits:

• Limits blast radius if a key is exposed
• Easier rotation
• Clear ownership

Pattern 3: Public vs Private Buckets

• Private buckets
  • Require credentials
  • Used for backups, internal data, application files
• Public buckets
  • Used only for static, non-sensitive content
  • Often paired with CDN

Example Architecture Comparison

IAM-Based Design (Conceptual)

User / App
  ↓
IAM Role / Policy
  ↓
Bucket

Security is enforced by policy rules.

StorageRaya Design (Actual)

User / App
  ↓
Access Key / Secret Key
  ↓
Bucket (ACL Boundary)

Security is enforced by bucket isolation and credential separation.

Enterprise & Compliance Considerations

StorageRaya’s model works well when:

• Workloads can be clearly separated
• Ownership is well-defined
• Systems are designed with bucket-level isolation

For organizations that require:

• Centralized identity governance
• Complex, conditional policies
• Fine-grained per-action permissions

You should design additional controls at the application or platform level, such as:

• API gateways
• Application authorization layers
• Network-level access restrictions
• Audit logging in consuming systems

Common Misconceptions

🚫 “I can create a policy to allow upload but block download”

→ Not supported at the platform level. Use separate buckets and credentials instead.

🚫 “This works like AWS IAM”

→ StorageRaya is S3-compatible at the API level, not at the IAM policy system level.

🚫 “One key is fine for everything”

→ This increases risk and reduces accountability.

When This Model Works Best

StorageRaya’s ACL-based model is ideal for:

• Microservice architectures
• Backup systems
• Media and asset platforms
• Data pipelines
• Team-based environments with clear ownership

It favors architectural clarity over policy complexity.

Summary

• StorageRaya uses an ACL-based, bucket-scoped access model
• It does not use IAM users, roles, or policy documents
• Security is achieved through:
  • Bucket isolation
  • Credential separation
  • ACL configuration
• Enterprise-grade designs should combine this with:
  • Application-level authorization
  • Network controls
  • Operational auditing

Understanding this model ensures your StorageRaya integrations are secure by design, predictable in operation, and easy to scale.

Related Guides

📄 Access & Credentials

📄 Access & Integration

📄 Create a Bucket

📄 StorageRaya Use Cases & Best Practices