Git Product home page Git Product logo

serverless-aws-signer's Introduction

Serverless plugin for Lambda functions signing using AWS Signer service

serverless Build Status npm version MIT licensed npm downloads

Installation

npm install serverless-aws-signer

Configuration

# add to your serverless.yml

plugins:
  - serverless-aws-signer

custom:
  signer:
    retain: false                                  # Whether to retain signing Profile and S3 buckets during the project termination (`sls remove` command), if they were created by the plugin
    source:
      s3:
        bucketName: source-bucket-for-signer       # [REQUIRED] Source bucket for AWS Signer where zip archive with lambda code will be uploaded
        key: lambda-object-name                    # Filename of the lambda zip archive at S3 (copied by the plugin). Is ignored in case of individually packaged functions
    destination:
      s3:
        bucketName: source-bucket-for-signer       # Destination bucket for AWS Signer where signed zip archive with lambda will appear after signing. Can be the same as source bucket
        prefix: signed-                            # Prefix to be added to the name of the signed archive
    profileName: signing-profile                   # AWS Signing Profle name. Currently needs to be created separately
    signingPolicy: Enforce                         # Whether to disallow code updated signed improperly or just fire a warning

package:
    indvidually: true                              # Plugin works with both individually and commonly packaged functions
   
functions:
  signee:
    handler: index.lambda_handler
    signer:                                         # Any global parameter can be overridden by lambda individual configuration. package.individually.true needs to be enabled for the plugin to parse function configs
      profileName: signing-profile
      signingPolicy: Enforce

Default Configuration

All parameters except for source S3 bucket and Signing profile can be ommitted. In this case they are taken from default values:

  • signer.source.s3.key - defaults to function_name + unix_timestamp
  • signer.destination.s3.bucketName - defaults to the source bucketName value
  • signer.destination.s3.prefix - defaults to signed-
  • signingPolicy - defaults to Enforce
  • retain - defaults to true

Default behavior

If an S3 bucket or a Signing profile are specified in configuration but couldn't be found in target AWS account, plugin will attempt to create them using AWS SDK (Not CloudFormation template).

When project gets terminated, plugin attempts to delete signingProfiles and S3buckets specified in corresponding configuration, unless retain option is set to true. Default value is true

In case one needs to change a signing provider of a lambda function, he'll need to recreate the lambda function, otherwise, AWS will reject the zip code with Lambda code, since it will be signed by a different signing Provider than the one specified in serverless configuration. It happens because signing is done before the CloudFormation template gets deployed

serverless-aws-signer's People

Contributors

jon-berg avatar jradikk avatar stevehine-kainos avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar

serverless-aws-signer's Issues

Built-in cognito handler doesn't seem to be signed

Serverless v2.72.3
I'm getting the following error:

 Serverless Error ----------------------------------------
 
  An error occurred: CustomDashresourceDashexistingDashcupLambdaFunction - Resource handler returned message: "Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for arn:aws:lambda:us-west-2:000000000000:function:foobar-dev-custom-resource-existing-cup. (Service: Lambda, Status Code: 400, Request ID: 8e940609-0000-0000-0000-425a543dc4a5)" (RequestToken: 46558a32-0000-0000-0000-8bc278f436e4, HandlerErrorCode: InvalidRequest).

Seems like this part is creating a lambda which is unrelated to our code (internally generated by serverless?):

// Cognito User Pool
  getCustomResourceCognitoUserPoolHandlerFunctionName() {
    return 'custom-resource-existing-cup';
  },

Here's my event config:

    events:
      - cognitoUserPool:
          pool: dev-foobar
          trigger: PostAuthentication
          existing: true

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.