serverless-iam-roles-per-function
Advanced tools
A Serverless plugin to define IAM Role statements as part of the function definition block
A Serverless plugin to easily define IAM roles per function via the use of iamRoleStatements at the function definition block.
npm install --save-dev serverless-iam-roles-per-function
Or if you want to try out the next upcoming version:
npm install --save-dev serverless-iam-roles-per-function@next
Add the plugin to serverless.yml:
plugins:
- serverless-iam-roles-per-function
Note: Node 6.10 or higher runtime required.
Define iamRoleStatements definitions at the function level:
functions:
func1:
handler: handler.get
iamRoleStatementsName: my-custom-role-name #optional custom role name setting instead of the default generated one
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:GetItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"
...
func2:
handler: handler.put
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:PutItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"
...
The plugin will create a dedicated role for each function that has an iamRoleStatements definition. It will include the permissions for create and write to CloudWatch logs, stream events and if VPC is defined: AWSLambdaVPCAccessExecutionRole will be included (as is done when using iamRoleStatements at the provider level).
if iamRoleStatements are not defined at the function level default behavior is maintained and the function will receive the global iam role. It is possible to define an empty iamRoleStatements for a function and then the function will receive a dedicated role with only the permissions needed for CloudWatch and (if needed) stream events and VPC. Example of defining a function with empty iamRoleStatements and configured VPC. The function will receive a custom role with CloudWatch logs permissions and the policy AWSLambdaVPCAccessExecutionRole:
functions:
func1:
handler: handler.get
iamRoleStatements: []
vpc:
securityGroupIds:
- sg-xxxxxx
subnetIds:
- subnet-xxxx
- subnet-xxxxx
By default, function level iamRoleStatements override the provider level definition. It is also possible to inherit the provider level definition by specifying the option iamRoleStatementsInherit: true:
serverless >= v2.24.0
provider:
name: aws
iam:
role:
statements:
- Effect: "Allow"
Action:
- xray:PutTelemetryRecords
- xray:PutTraceSegments
Resource: "*"
...
functions:
func1:
handler: handler.get
iamRoleStatementsInherit: true
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:GetItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"
serverless < v2.24.0
provider:
name: aws
iamRoleStatements:
- Effect: "Allow"
Action:
- xray:PutTelemetryRecords
- xray:PutTraceSegments
Resource: "*"
...
functions:
func1:
handler: handler.get
iamRoleStatementsInherit: true
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:GetItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"
The generated role for func1 will contain both the statements defined at the provider level and the ones defined at the function level.
If you wish to change the default behavior to inherit instead of override it is possible to specify the following custom configuration:
custom:
serverless-iam-roles-per-function:
defaultInherit: true
The plugin uses a naming convention for function roles which is similar to the naming convention used by the Serverless Framework. Function roles are named with the following convention:
<service-name>-<stage>-<function-name>-<region>-lambdaRole
AWS has a 64 character limit on role names. If the default naming exceeds 64 chars the plugin will remove the suffix: -lambdaRole to shorten the name. If it still exceeds 64 chars an error will be thrown containing a message of the form:
auto generated role name for function: ${functionName} is too long (over 64 chars).
Try setting a custom role name using the property: iamRoleStatementsName.
In this case you should set the role name using the property iamRoleStatementsName. For example:
functions:
func1:
handler: handler.get
iamRoleStatementsName: my-custom-role-name
iamRoleStatements:
- Effect: "Allow"
Action:
- dynamodb:GetItem
Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/mytable"
...
Define iamPermissionsBoundary definitions at the function level:
functions:
func1:
handler: handler.get
iamPermissionsBoundary: !Sub arn:aws:iam::xxxxx:policy/your_permissions_boundary_policy
iamRoleStatementsName: my-custom-role-name
iamRoleStatements:
- Effect: "Allow"
Action:
- sqs:*
Resource: "*"
...
You can set permissionsBoundary for all roles with iamGlobalPermissionsBoundary in custom:
custom:
serverless-iam-roles-per-function:
iamGlobalPermissionsBoundary: !Sub arn:aws:iam::xxxx:policy/permissions-boundary-policy
For more information, see Permissions Boundaries.
Contributions are welcome and appreciated.
npm run release
npm run release (we have the auto-commit option disabled by default).next tag. You will see your version deployed at: https://www.npmjs.com/package/serverless-iam-roles-per-function?activeTab=versions.next tag. For example:
npm install --save-dev serverless-iam-roles-per-function@next
Once a contributed PR (or multiple PRs) have been merged into master, there is need to publish a production release, after we are sure that the release is stable. Maintainers with commit access to the repository can publish a release by merging into the release branch. Steps to follow:
Verify that the current deployed pre-release version under the next tag in npmjs is working properly. Usually, it is best to allow the next version to gain traction a week or two before releasing. Also, if the version solves a specific reported issue, ask the community on the issue to test out the next version.
Make sure the version being used in master hasn't been released. This can happen if a PR was merged without bumping the version by running npm run release. If the version needs to be advanced, open a PR to advance the version as specified here.
Open a PR to merge into the release branch. Use as a base the release branch and compare the tag version to release. For example:
Once approved by another maintainer, merge the PR.
Make sure to check after the Travis CI build completes that the release has been published to the latest tag on nmpjs.
Introduction post: Serverless Framework: Defining Per-Function IAM Roles
Note: Serverless Framework provides support for defining custom IAM roles on a per function level through the use of the role property and creating CloudFormation resources, as documented here. This plugin doesn't support defining both the role property and iamRoleStatements at the function level.
FAQs
A Serverless plugin to define IAM Role statements as part of the function definition block
We found that serverless-iam-roles-per-function demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.