Skip to main content

Running Functions as a Service

With SecureAuth, you can run Extention scripts and evaluate authorization policies with the FaaS (Function as a Service) approach in a separate execution context to increase the system security.

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. SecureAuth 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

    SecureAuth 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 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 satellite environments when triggered.

SecureAuth deploys Fission environment pods in an isolated namespace. This namespace must be pre-created. 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

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, toleration, affinity, and more can be modified for fission pods. See values reference.

Set Up Docker Pull Secret For Fission Workers For SecureAuth

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

  1. Check if all fission pods are running.

    kubectl get pods --namespace fission

  2. Check if all fission pool pods are working.

    kubectl get pods --namespace acp-faas

  3. 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

SecureAuth 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

    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 satellite Node.js and REGO pods shared by all SecureAuth 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.

    FaaS_1.svg

  • 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).

    FaaS_2.svg

    Enable Fission as usual and overwrite docker config with dynamic FaaS uri. Do not change the {{tenantID}} variable. It is calculated automatically by the SecureAuth 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
In this section: