FaaS Overview
FaaS, or Function-as-a-Service, is a cloud-computing service that allows customers to execute code without managing the complex infrastructure typically associated with building and launching microservices applications. Cloudentity supports ability to execute the authorization policy logics (policies written in REGO) as well as custom extensions scripts in a secure sandbox utilizing the Function as a Service (FaaS) approach. This can be achieved in two ways:
-
Using Fission
Cloudentity uses Fission to run functions of thousands of tenants that we have registered in our SaaS platform. If you do not expect your deployment to have a large number of tenants, use the Setting Up Self-Managed Direct FaaS Environment approach.
-
Setting Up Self-Managed Direct FaaS Environment
Setting up a custom FaaS environment is a recommended way of running Functions as a Service if there is not a large number of tenants running within the deployment. In comparison to setting up FaaS with Fission, creating a custom FaaS environment removes one layer of abstraction and simplifies the management and maintenance of your FaaS infrastructure.
Fission Integration for FaaS
Fission is a fast, open source serverless framework for Kubernetes with a focus on developer productivity and high performance. Fission is based on functions invoked in satelite environments when triggered.
Cloudentity deploys Fission environment pods in an isolated namespace. This
namespace must be precreated. By default, acp-faas
namespace is used. If you want to use
private docker images like rego-env
, a docker secret registry must be added to that namespace.
Prerequisites
- Kubernetes cluster v1.16+
- Helm v3.0+
Install Fission Using Helm
kubectl create namespace fission
kubectl create -k "github.com/fission/fission/crds/v1?ref=v1.20.0"
helm repo add fission-charts https://fission.github.io/fission-charts/
helm repo update
helm install --version v1.20.0 --namespace fission fission fission-charts/fission-all
Learn more
To learn more, visit installation Fission documentation.
Enable Fission Integration
Configure your values.yaml
file to enable Fission Integration
and apply the changes:
faas:
enabled: true
provider: "fission"
Enabling Fission creates the following resources:
- Fission environments for Node.js (where the Extension Scripts are executed) and REGO (where authorization policies are evaluated)
- A network policy that allows only public egress traffic from Fission environments.
Network policy as well as common pods parameters like resources, tolerations, affinity, and more can be modified for fission pods. See values reference.
Set Up Docker Pull Secret For Fission Workers For Cloudentity
kubectl create secret docker-registry docker.cloudentity.io \
--namespace acp-faas \
--docker-server=docker.cloudentity.io \
--docker-username="$DOCKER_USR" \
--docker-password="$DOCKER_PWD"
Verify Integration
-
Check if all fission pods are running.
kubectl get pods --namespace fission
-
Check if all fission pool pods are working.
kubectl get pods --namespace acp-faas
-
Login to the admin portal, navigate to Extensions > Scripts, create a script and execute it to check if everything works correctly.
Setting Up Self-Managed Direct FaaS Environment
Cloudentity supports running Extension scripts and evaluating REGO policies on dedicated node.js/REGO pods. In comparison to setting up FaaS with Fission, creating a custom FaaS environment removes one layer of abstraction and simplifies the management and maintenance of your FaaS infrastructure.
It is possible to create a custom FaaS environment for one tenant or more - the rest will be using Fission, shared pods, or their own dedicated pods. For more details, see the Dedicated Node.js and REGO Pods
Prerequisites
- Kubernetes cluster v1.16+
Enable Direct FaaS Integration
Configure your values.yaml
file to enable Fission Integration
and apply the changes:
faas:
enabled: true
provider: "docker"
Optional: Set Up Autoscaling for Pods
Select one of the autoscaling approaches below:
-
Setup KEDA based autoscaling based on number of incomming script executions. For this mode to work properly, KEDA with HTTP Add-on must be installed in the cluster.
faas: environments: autoscaling: keda: enabled: false minReplicas: 1 maxReplicas: 3 port: 8080 targetPendingRequests: 1 interceptor_dns: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local
Learn more
To learn more, visit Deploying KEDA documentation as well as Installing the KEDA HTTP Add-on.
-
Setup horizontal pod autoscaling based on CPU and/or Memory usage.
faas: environments: autoscaling: hpa: enabled: false minReplicas: 1 maxReplicas: 3 targetCPUUtilizationPercentage: "50" targetMemoryUtilizationPercentage: "50"
Set Up Docker Pull Secret For Direct FaaS pods
kubectl create secret docker-registry docker.cloudentity.io \
--namespace acp-faas \
--docker-server=docker.cloudentity.io \
--docker-username="$DOCKER_USR" \
--docker-password="$DOCKER_PWD"
Result
Your Extension scripts and REGO authorization policies are now executed in satelite Node.js and REGO pods shared by all Cloudentity platform tenants. If you wish some tenant’s to have dedicated Node.js and REGO pods, learn more by reading the Dedicated Node.js and REGO Pods section.
Dedicated Node.js and REGO Pods
In some cases, it may be beneficial to have tenants that have their own dedicated pods: one for Node.js and one for REGO. It can be set up regardless whether you use Fission or only dockerized FaaS environments.
Hybrid Approach: Fission + Dedicated Pods For Selected Tenants
If you have a large number of tenants for which it is possible to share a pair of Node.js and REGO pods for executing Extensions and REGO policies, you may set provider to hybrid mode.
faas:
enabled: true
provider: "hybrid"
-
Desired number of tenants share the same Node.js and the same REGO pod, the rest is using Fission.
flowchart LR t1(Tenant 1) t2(Tenant 2) t3(Tenant 3) t4(Tenant 4) fis(Fission) dpod(Dedicated Node.js and REGO pods) t1-->fis t2-->fis t3-->dpod t4-->dpod -
Desired number of tenants have their own dedicated Node.js pod and REGO pod that they do not share with any other tenant, the rest of the tenants share Fission. This configuration is not fully supported by helm and requires additional manifest to be deployed separately (see below).
flowchart LR t1(Tenant 1) t2(Tenant 2) t3(Tenant 3) t4(Tenant 4) fis(Fission) dpod1(Dedicated Node.js and REGO pods pair 1) dpod2(Dedicated Node.js and REGO pods pair 2) t1-->fis t2-->fis t3-->dpod1 t4-->dpod2Enable Fission as usual and overwrite docker config with dynamic FaaS uri. Do not change the
{{tenantID}}
variable. It is calculated automatically by the Cloudentity platform based on your tenant’s identifier.faas: enabled: true provider: "fission" config: data: docker: node_url: "http://acp-faas-node-v5.acp-faas-{{tenantID}}:8888" rego_url: "http://acp-faas-rego-v5.acp-faas-{{tenantID}}:8888"
You would need to deploy additional FaaS manifest in each namespace that will be used in place of
{{tenantID}}
. Render required files by using helm templating function, replace<tenant>
with actual tenant name:helm template acp acp/acp --set faas.enabled=true --set faas.namespace.name=acp-faas-<tenant> -s templates/faas_*
Apply rendered manifests to the cluster.
FaaS versioning
It might be reuired to operate multiple versions of FaaS pods concurrently. When creating functions, tenants are given the option to select which version each script will run against. This functionality is exclusively supported for Direct Docker FaaS pods, which includes both docker
and hybrid
modes. The environments that are enabled can be managed through the values.yaml
file
faas:
enabled: false
provider: "docker"
environments:
node:
v4:
enabled: true
v5:
enabled: true