Closed amwolff closed 3 months ago
Egon suggested we need to think about what happens on the frontend: what if someone shares a project with another user? Right now, they get a complete set of permissions. If we share a project, we might want to share only a default set of permissions. The satellite UI should probably display warnings about locked object versions, e.g., when sharing the project. /cc @ferristocrat @mobyvb
Short term solution: Display warning that sharing a project also shares locked object versions when inviting users. Alternatively, hide locked objects from project members and only allow owner to see them. Long term solution: Support different permission levels for project members, and allow setting permission levels as admin/owner
cc @ferristocrat
I would go with a single lock
(verb) permission that allows all actions related to object locking:
This way, this new permission will be as coarse-grained as the existing read,
write,
list,
and delete
permissions, which cover several methods. In the future, if we see a need, we may introduce more fine-grained permissions as AWS does - a separate permission for each method.
We should make nothing special when displaying the new lock
permission in the New Access wizard. As far as I can see there is no default pre-selected permissions. The user must explicitly choose permission. If they select "All permissions", well... it means exactly this - they grant all permissions (including object lock) for this new access.
The new Lock
permission allows for retention periods and legal holds to be placed on and retrieved from objects.
It also allows for object lock configurations to be placed on and retrieved from buckets.
This permission encompasses all of these S3 permissions:
s3:BypassGovernanceRetention
s3:GetBucketObjectLockConfiguration
s3:GetObjectLegalHold
s3:GetObjectRetention
s3:PutBucketObjectLockConfiguration
s3:PutObjectLegalHold
s3:PutObjectRetention
Amendments to the behavior of existing actions if Lock
is set on the provided API key:
GetObject
and HeadObject
should return the following HTTP response headers:
x-amz-object-lock-legal-hold
: Indicates whether this object has an active legal hold.x-amz-object-lock-mode
: The Object Lock mode that's currently in place for this object.x-amz-object-lock-retain-until-date
: The date and time when this object's Object Lock will expire.PutObject
, CopyObject
, and CreateMultipartUpload
should accept the following HTTP response headers:
x-amz-object-lock-legal-hold
: Specifies whether a legal hold will be applied to this object.x-amz-object-lock-mode
: The Object Lock mode that you want to apply to this object.x-amz-object-lock-retain-until-date
: The date and time when this object's Object Lock will expire.CreateBucket
should accept the following HTTP response header:
x-amz-bucket-object-lock-enabled
: Specifies whether you want S3 Object Lock to be enabled for the new bucket.Actions enabled by Lock
:
GetObjectLockConfiguration
GetObjectLegalHold
GetObjectRetention
PutObjectLockConfiguration
PutObjectLegalHold
PutObjectRetention
Change macaroon: implement object lock permission mentions this issue.
Change satellite/satellitedb: add version column to api_keys table mentions this issue.
Change metainfo: use API key version when authorizing actions mentions this issue.
Change access: support Object Lock permission mentions this issue.
Goal
This issue is to make meaningful progress on Object Lock implementation within core and edge services. Specifically, to support immutable backups in backup software products like Veeam.
What needs to be done? • Acceptance Criteria
Implement this section of the draft design doc.
Depends on…
411
Links