Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ObjectLock as a storage attribute #124

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

flavianh
Copy link
Contributor

"Object Lock can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely. You can use Object Lock to help meet regulatory requirements that require WORM storage, or to simply add another layer of protection against object changes and deletion."

This pull request only adds the ability to set Object Lock to "indefinite".

/!\ I don't know how to properly test this?

@fredericbarthelet
Copy link
Collaborator

fredericbarthelet commented Oct 26, 2021

Hey @flavianh, thanks for this proposal :) !

Our goal with Lift is to provide AWS-agnostic feature configuration - in the form of constructs - enabling more developers, not familiar with AWS ecosystem to join the serverless revolution. ObjectLock is strongly linked to AWS. Looking at the documentation, this opens up abilities to implement legal hold and retention periods policies on each object version in a bucket when uploading a new object.

A good way to approach this (and the type of configuration provided in the construct) is to think in terms of feature enabled by this configuration. What do you think of something like retention with an integer representing a value in days that would:

  • enable ObjectLock on the bucket (what you did in your PR)
  • add an ObjectLockConfiguration with the configured period (+ choosing between governance and compliance mode)

WDYT ?

In the meantime, if setting this property is urgent in your case, you can easily override this property without a dedicated option on the construct using the resources.extensions property from Serverless framework:

resources:
  extensions:
    MyAppBucket: // Replace  with the actual logicalId of the S3 bucket from the cloudformation ressources tab
      Properties:
        ObjectLockEnabled: true

As far as tests are concerned, you can add a configured storage construct using your new property in test/fixtures/storage/serverless.yml and then implement a test following exemples from test/unit/storage.test.ts to check that output Cloudformation contains the ObjectLockEnabled when the corresponding construct parameter is set.

@mnapoli mnapoli added the enhancement New feature or request label Nov 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants