You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -149,6 +149,10 @@ constructs:
149
149
150
150
More constructs are coming soon! Got suggestions? [Open and upvote drafts](https://github.com/getlift/lift/discussions/categories/constructs).
151
151
152
+
## Lift-specific configuration
153
+
154
+
Lift default behaviors can be override and configured as per your likings using the `lift` property at the root of your `serverless.yml` file. This property is optional as well as all the [configurable options within](docs/configuration.md). Configurations specified at this level affect all constructs defined within the same service file.
155
+
152
156
## Ejecting
153
157
154
158
You can eject from Lift at any time: Lift is based on CloudFormation. That allows anyone to kickstart a project with Lift, and fallback to CloudFormation if you ever grow out of it.
This documentation describes all available properties that can specified in the `lift` property at the root of your service file. All options defined here affect all the constructs defined in the same service file
4
+
5
+
## Automatic permissions
6
+
7
+
Each construct ships with a pre-defined list of IAM permissions that will be added to the IAM role used by all Lambda functions defined in the same service file and provisionned using the Serverless Framework capabilities. This is to ensure new-comers don't struggle with finding the correct permission sets to interact with the deployed constructs.
8
+
9
+
For exemple, the [`storage` construct](storage.md) will happen the following permissions to the IAM role provisionned by the Serverless Framework and used by all Lambda functions within the same service file:
10
+
11
+
-`s3:PutObject`
12
+
-`s3:GetObject`
13
+
-`s3:DeleteObject`
14
+
-`s3:ListBucket`
15
+
16
+
You can use the `automaticPermissions` options if you want to opt out of this default behavior. This can be especially useful for production environment where you want to provision fined-grained permissions based on your actual usage of the construct - i.e. you may want to only read from the bucket provisionned uisng the `storage` construct.
17
+
18
+
Here is an exemple `serverless.yml` service file disabling automatic permission for a `storage` construct:
Copy file name to clipboardExpand all lines: docs/serverless-types.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Lift TypeScript definitions
1
+
# Lift-specific configuration
2
2
3
3
While YAML remains the most popular declarative syntax for Serverless service file definition - a.k.a `serverless.yml` - you can also use Javascript/TypeScript definitions - i.e. `serverless.js` and `serverless.ts`. You can find more information on using JS/TS service file in the [Serverless official documentation](https://www.serverless.com/framework/docs/providers/aws/guide/intro#services).
0 commit comments