[DISCUSS] Design: Per-Bucket Object Storage Credentials and Key Rotation

[dheeraj12347]

Purpose

This PR proposes a design for introducing per-bucket object storage credentials and credential rotation in Apache CloudStack.

This is intentionally a design-only PR. No implementation is included at this stage. The goal is to discuss and validate the proposed architecture before implementation begins.

Background

Currently, object storage credentials are provisioned at the CloudStack account level. Multiple buckets belonging to the same account can therefore share the same object storage credentials.

This creates several limitations:

• A leaked credential can provide access beyond a single bucket.
• Credentials cannot be safely delegated on a per-bucket basis.
• Rotating credentials for one bucket is not currently possible without affecting other buckets.
• There is currently no object-storage API for credential rotation or revocation.

The proposed design introduces bucket-scoped credentials while maintaining backward compatibility for existing buckets.

Proposed Design

The proposal follows the per-bucket credential and two-key rotation approach discussed on the CloudStack mailing list.

Each bucket should be able to have two independently managed credential slots:

Bucket
 |
 +-- Credential 1
 |
 +-- Credential 2

This allows one credential to be replaced or rotated while the other remains usable.

The design also considers:

• Credential creation and retrieval
• Credential rotation
• Credential revocation
• Credential lifecycle/state
• Persistence of the two credential slots
• API changes
• Object-store driver changes
• Migration of existing buckets
• Backward compatibility
• Security and authorization

Backward Compatibility

Existing buckets should not be forced to change credentials during an upgrade.

Where a bucket does not have bucket-specific credentials, the existing account-level credential mechanism can continue to be used.

New buckets can use bucket-specific credentials according to the final agreed design.

An explicit migration mechanism can be provided for existing buckets.

Provider Impact

The design considers the existing object storage providers and driver abstraction, including:

• Ceph
• MinIO
• Cloudian
• Simulator

Provider-specific implementation details will be addressed after the common architecture and lifecycle semantics are agreed upon.

Open Questions

Feedback is particularly requested on:

1. Should bucket-specific credentials be the default for new buckets, or initially be opt-in?
2. What is the preferred persistence model for the two credential slots?
3. What credential lifecycle/state model should be used?
4. What should happen when the final active credential is revoked?
5. What should the rotation API return, particularly regarding secret keys?
6. Should individual and bulk migration of existing buckets be supported?
7. How should providers that cannot support the proposed model be handled?
8. What should the exact API naming and authorization model be?

Scope

This proposal is intentionally focused on bucket-scoped credentials and key rotation.

An IAM/service-account style model where identities are completely decoupled from buckets and managed independently through policies is considered out of scope for this change.

Feedback Requested

Before implementation, feedback is requested on the overall architecture, credential lifecycle, persistence model, API design, migration strategy, and provider abstraction.

Implementation will follow after the design has been reviewed and the open architectural questions have been resolved.

[dheeraj12347]

Hi @wido, @DaanHoogland and Mitchell Drage,

I’ve prepared a design-only PR based on the per-bucket object storage credentials and key rotation discussion:

#14053

The proposal covers the per-bucket credential model, two-key rotation, revocation, API/persistence changes, backward compatibility, migration, provider impact, and security considerations.

I’ve intentionally left the implementation out for now so the design and open architectural questions can be reviewed first.

I’d especially appreciate your feedback on the credential model, rotation semantics, migration approach, and whether per-bucket credentials should be the default for new buckets or initially opt-in.