Serverless initial implementation [MAJOR] (#250)

* serverless initial commit

* feat: Initial changes to module, docs, and apply process for serverless

* move sam policy out into user_access files

* small syntax fixes

* add security group and VPC connection for lambda

* create user-db from lambda instead of k8s

* support database list and mysql

* App secret name from /kubernetes to /application

* fix wrong env-var and unnecessary escape

* split route53 and loggroup IAM permissions

* Move k8s auth out of infra terraform (#246)

* refactor: move k8s auth out of infra terraform and into kubernetes

* fix: removed a couple leftover reference to k8s in infrastructure tf

* fix: fix name of var and tf typo

* fix: made variable name more clear

* fix: remove unnecessary merge

* fix: misc fixes, plus added some deps to avoid race conditions

* fix: bump eks and user_access module versions

* fix: Add missing vars in prod/main.tf

* add some documentation around setting up auth0

* work in progress diagrams for serverless

* template out auth0 due to provider constrains

* more documentation around serverless

* better naming and adding comments

* fix syntax error in user_access.tf

* fix some prod deployment problems

* fixes secret prefix and assumable roles

* fixes around roles and permissions

* update diagrams

* makefile and typo fixes

* bump user_auth for secret creation conflict

Co-authored-by: Bill Monkman <[email protected]>

Author: davidcheung

Makefile

@@ -5,7 +5,7 @@ SHELL := /bin/bash
 run: make-apply
 
 make-apply:
-	cd $(PROJECT_DIR) && AUTO_APPROVE="-auto-approve" make
+	@export AUTO_APPROVE="-auto-approve" && cd $(PROJECT_DIR) && (if [[ "${backendApplicationHosting}" =~ "kubernetes" ]]; then make apply; else make apply-without-eks; fi)
 
 summary:
 	@echo "zero-aws-eks-stack:"

README.md

@@ -28,10 +28,10 @@ The root folder is used for declaring parameters required by the templates, and
 ```
 
 ## AWS EKS Stack
-The Zero-awk-eks stack is designed with scalability and maintainability in mind, this repo is a series of templates indented to be filled in with modules parameters, and executed by zero 
+The Zero-aws-eks stack is designed with scalability and maintainability in mind, this repo is a series of templates indented to be filled in with modules parameters, and executed by zero
 This is a [Zero][zero] module which sets up a
 hosting environment on AWS running Kubernetes. It will generate terraform output
-which describes the environment mapped in this [architecture diagram][arch-diagram]. 
+which describes the environment mapped in this [architecture diagram][arch-diagram].
 
 **Resource List**: [Link][resource-list]
 

doc-site/docs/components/kubernetes/external-secrets.md

@@ -20,10 +20,10 @@ You can see the `external-secrets` configuration in [kubernetes/overlays/staging
 
 To work with the secret in AWS you can use the web interface or the cli tool:
 ```
- aws secretsmanager get-secret-value --secret=<project-name>/kubernetes/stage/<project-name>
+ aws secretsmanager get-secret-value --secret=<project-name>/application/stage/<project-name>
 ```
 
-The intent is that the last part of the secret name is the component of your application this secret is for. For example: if you were adding a new billing service, the secret might be called `<project-name>/kubernetes/stage/billing`
+The intent is that the last part of the secret name is the component of your application this secret is for. For example: if you were adding a new billing service, the secret might be called `<project-name>/application/stage/billing`
 
 ## Documentation
 Checkout [External secrets's documentation][docs] for more information.

doc-site/docs/components/serverless/authentication.md

@@ -0,0 +1,34 @@
+---
+title: Authentication
+sidebar_label: Authentication
+sidebar_position: 3
+---
+
+Authentication is invoked through the API gateway, this allows the decoupling of Authentication from the business logic, and also allows reusing this authentication logic for other endpoints.
+
+Our implementation uses the [Lambda-authorizer flow][lambda-authorizer-flow] documented in AWS, this gives more flexibility of the behavior than the JWT authorizer flow which perform similar functionality. Such as implementing login/logout/callback endpoints, configuring HTTPs cookie and etc.
+
+## OIDC Authorizer
+Supports OpenID Connect compliant solutions with Oauth2 based authentication flow
+
+| Environment Variables  | Description | Defaults |
+|------------------------|-------------|----------|
+| NODE_ENV               | When set as `development` the authenticator listens on a PORT instead of exporting as lambda function  | - |
+| ISSUER_BASE_URL        | Issuer with OpenID Connect configured, should have a `.well-known/openid-configuration` setup | - |
+| CLIENT_ID              | Client ID for issuer to exchange for tokens | - |
+| CLIENT_SECRET          | Client Secret for issuer to exchange for tokens | - |
+| COOKIE_DOMAIN          | Scoping Cookies to be only readable in configured domains | - |
+| COOKIE_SIGNING_SECRET  | Secret used to encrypt the cookie secret | - |
+| AUTH_ENDPOINT          | Authentication service callbacks to exchange and set token | - |
+| FRONTEND_URL           | Frontend for CORS and redirection to web application | - |
+| AUTH_SCOPE             | scope of authentication | `openid profile email` |
+| ALLOW_INSECURE_COOKIES | Allow insecure cookie to be set on client, this should only be allowed in testing environments | `false` |
+| JWT_COOKIE_KEY         | By default authenticator will sign a JWE, specify this key to set a JWT in the cookie | - |
+
+## Auth Middleware
+Authenticator is invoked by API Gateway and the context is passed down via `requestContext.authorizer.lambda`, all the JWT claims will also be available in this context, to change or modify the context you can update the authorizer lambda function.
+
+## Application
+By default all endpoints except for `GET /status*` will go through authentication, this is configured in `template.yaml` in the backend application.
+
+[lambda-authorizer-flow]: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html#api-gateway-lambda-authorizer-flow 

doc-site/docs/components/serverless/concepts.md

@@ -0,0 +1,19 @@
+---
+title: Concepts and building blocks
+sidebar_label: Concepts
+sidebar_position: 1
+---
+
+## CI/CD Pipeline
+We use Github actions to invoke the Cloudformation pipeline, it consists of 2 steps:
+- `aws sam build`
+- `aws sam deploy`
+The `build` step compiles the container images, and the `deploy` step uses Cloudformation to get the resources to the desired state.
+
+## Environment Configuration
+Managed by `config.toml` in the backend repository.
+This is the deploy step's configuration, determines where the artifacts are saved and allows configuration of parameters of each environment, such as image repositories and S3 to store build configurations.
+
+## CloudFormation template
+Managed by `template.yaml` in the backend repository.
+This is the configuration of your infrastructure and application setup, this configures how the Gateway, authenticator, application, logging and routes are setup.

doc-site/docs/components/serverless/routing.md

@@ -0,0 +1,39 @@
+---
+title: Routing
+sidebar_label: Routing
+sidebar_position: 2
+---
+
+
+## Routes
+All the routes are configured in AWS API Gateway in backend's [`template.yaml`][template-yaml]
+
+## Domain
+The domain is expected to pointed to an AWS hosted-zone same as our EKS setup, in terraform we provision a TLS certificate and store the ARN in SSM for reference in the `template.yaml`. With the Certificate setup AWS SAM will help you modify the Route53 entry to point to API Gateway.
+
+### Authenticator
+Endpoints setup for authenticator, these are used to facilitate the login and token exchange flow, and allow web applications to get the authentication status of a client.
+- `GET /login`
+- `GET /logout`
+- `GET /callback`
+- `GET /whoami`
+
+
+
+### Application
+#### Requires Authentication
+- `GET /{proxy+}`
+- `POST /{proxy+}`
+- `PUT /{proxy+}`
+- `PATCH /{proxy+}`
+- `DELETE /{proxy+}`
+
+:::note 
+Wildcard HTTP Method is not used because if `OPTIONS` are routed to the application it will need to specifically handle this case
+:::
+#### No Authentication
+- `GET /status`
+
+
+
+[template-yaml]: https://github.com/commitdev/zero-backend-node/blob/577af42c78f936b9e6d8cd09eac0f57a610b5cd2/templates/template.yaml