dheeraj12347 opened a new pull request, #14053:
URL: https://github.com/apache/cloudstack/pull/14053
## 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:
```text
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
