cmsgov / serverless-s3-bucket-helper

Serverless S3 Bucket Helper

This plugin sets settings on all S3 buckets. These are settings we generally want everywhere.

Currently,

• versioning is enabled for all buckets, regardless of configuration... non-negotiable
• public access is blocked via 'PublicAccessBlockConfiguration' by default.
• optionally, enable s3 server access logging for all buckets

Usage

plugins:
  - serverless-s3-bucket-helper

s3BucketHelper:
  # Optional setting for enabling s3 server access logging.
  loggingConfiguration:
    destinationBucketName: my-logging-bucket
    logFilePrefix: path/for/logs

Background

This plugin hooks into the serverless lifecycle at "before:deploy:deploy". There, it looks for S3 buckets and potentially modifies each. Currently, versioning is enabled for all buckets and public access is blocked by default. Enabling S3 server access logging requires setting the optional loggingConfiguration for the top level s3BucketHelper property.

serverless-s3-bucket-helper's Issues

Serverless deployment buckets don't block public access on first creation

Type of Issue:

• Bug: Something isn't working

Issue Creator Checklist

• This issue has been thoroughly documented below; a developer should be able to understand the issue by reading it.

What's broken?

Each service deployed by serverless has a corresponding deployment bucket in S3.
This plugin tries to treat the deployment bucket like any other, ensuring its configured correctly.

However, this is not working as intended.

When a new service is created for the very first time, the sls deployment bucket is missed by this plugin and not configured correctly. This misconfiguration is typically resolved almost immediately, as the first deployment of the service (deployment follows creation) fixes it. However, sometimes a Security Hub finding is momentarily generated, and it would be preferred to not have this gotcha.

What's the impact of this bug?

When a service is created for the very first time (new branch/stage), the deployment bucket is created without modification by this plugin, so without versioning enabled or public access blocked.

Steps to Reproduce?

• Start the deployment of a brand new service/stage combination.
• Kill the deployment process once you see the text "Serverless: Checking Stack create progress..."
• Through the console or cli, check the permissions on the deployment bucket attached to that service/stage. It will not be set to block public access.

Assorted Notes/Considerations

• I'm pretty sure the root cause of this issue is an incomplete understanding of serverless. I think on brand new service creation, the coreCloudFormationTemplate drives the stack creation (and thus controls the sls deployment bucket), not the compiledCloudFormationTemplate (which takes over control after initial stack creation).

AC:

• bug as described above is fixed; serverless deployment buckets block public access at all times, including first creation.

Block public access via PublicAccessBlockConfiguration on all buckets, unless explicitly set

Type of Issue:

• Enhancement: New feature or request

Issue Creator Checklist

• This issue has been thoroughly documented below; a developer should be able to understand the issue by reading it.

Background

This plugin stems from needs and requirements for software projects at CMS. One of those requirements is to have our applications' cloud infrastructure meet security requirements driven by rules in AWS Security Hub. This issue proposes an enhancement to the serverless-s3-bucket-helper plugin to help meet one of those rules... S3.8 S3 Block Public Access setting should be enabled at the bucket-level.

"S3.8 S3 Block Public Access setting should be enabled at the bucket-level" stipulates:

This control checks if Amazon S3 buckets have bucket level public access blocks applied. This control fails if any of the bucket level settings are set to "false" public: ignorePublicAcls, blockPublicPolicy, blockPublicAcls, restrictPublicBuckets.

Currently on CMS projects, a lot of buckets do not explicitly block public ACLs and access on a bucket level. This includes serverless deployment buckets, used by serverless to facilitate deployment. This changeset calls for a plugin based approach to meet S3.8's requirements.

WIP

Proposed Approach

This plugin could set the PublicAccessBlockConfiguration for all S3 buckets that do not already have it set. The idea is that by default, we want to block all public access via the bucket. So, if the PublicAccessBlockConfiguration is not already set, let this plugin set it to block. If the PublicAccessBlockConfiguration is already set on a bucket, let this plugin do nothing; this provides a means to use this plugin while also explicitly setting a bucket to allow public access. While allowing public access to a bucket is almost never a good practice, it's important to leave a door open as exceptions occur.

Value

This enhancement would provide consumers, including CMS projects, an out-of-sight/out-of-mind path to meeting S3.8's requirements.

AC:

• Enablement of the serverless-s3-bucket-helper plugin causes all buckets created by the service to block all public access at the bucket level, meeting S3.8 compliance.
• Existing functionality is not broken.

Update required peerDep for serverless?

Type of Issue:

• Question: Further information is requested (I have a question)

Issue Creator Checklist

• This issue has been thoroughly documented below; a developer should be able to understand the issue by reading it.

Question / Request for more Info

The current package.json requires [email protected] as a peer dependency, however the latest update was v2.72.3 a year ago. As projects move towards [email protected] they're forced to ignore this peer dependency through NPM at the risk of breaking changes. This staggers their ability to keep up-to-date with what serverless offers with each new release and patch.

Can a version of this package supporting [email protected] be released to solve for this major version bump in the serverless framework?

AC:

• Question answered by maintainers
• If applicable: ticketed work linked to this question so that I may follow for updates