storj/edge

Create new Object Lock-related permissions

Closed this issue · 8 comments

amwolff commented

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…

Links

amwolff commented

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

mobyvb commented

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

kaloyan-raev commented

I would go with a single lock (verb) permission that allows all actions related to object locking:

  • Reading bucket's object lock config
  • Configuring object lock for a bucket
  • Setting the object's retention period
  • Reading the object's retention period
  • etc.

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.

jewharton commented

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