The idea of applying the serverless paradigm in the edge looks appealing and promising.
Event-based serverless functions are naturally suited to define computation on IoT data, while containerisations are lightweight and can run on most edge devices, on-demand execution of functions can lead to improved usage of resource-constrained devices, closer to the edge of the Internet. However, the adoption of the FaaS in edge scenarios expose the challenge of preserving and enforcing security constraints. Edge comes along with new distinctive security threats to be faced. Serverless platforms should provide isolation among users and accurate accounting for billing purposes, which might be non-trivial to ensure in highly pervasive edge infrastructures with hundreds of nodes.
In this context, how to secure FaaS orchestration on edge computing is still a largely open research problem, being security monitoring and enforcement more complex to achieve than in traditional Cloud settings due to the aforementioned characteristics of the FaaS and edge. How can we identify open challenges to tackle the above problem ? I have divided my small research into 3 :
1. languages, models and methodologies to define FaaS orchestrations,
2. Platforms, techniques and methodologies to execute FaaS orchestrations on edge.
3. Techniques and methodologies to secure FaaS orchestrations both statically and at runtime.
To better capture and depict the current FaaS world, it is worth mentioning and briefly illustrating the existing platforms being the ones where FaaS has been initially started, developed and put in production environments.
This section gives an overview of existing FaaS platforms recapitulating on their main characteristics and the trends that are ongoing in the serverless settings, already considering the three perspectives analysed AWS Lambda, It is the FaaS platform offered by Amazon. Being integrated with the Amazon Web Services (AWS) suite, it permits to natively run functions — called Lambda functions — written in a set of commonly used programming languages (viz. Java, Go, PowerShell, Node.js, C, Python and Ruby). Besides, it permits defining specific triggers to launch functions and to automatically manage the allocated resources to execute. It features pay-per-use billing, with precision at the level of hundreds of milliseconds. Workflow-based orchestrations of distributed applications can be specified with AWS Step Functions that allows designing workflows by defining a set of states and guarded transactions between them. States can be tasks or language constructs that modify the execution flow. Tasks represent single units of work and they can be Lambda functions, AWS services or activities. Activities are worker services implemented and hosted by the users and featuring an AWS resource address obtainable through AWS console, SDK or API. Workflows have an initial state and a final state, and every state must declare its successor, and whether it represents a successful or failed execution in case it is an end state. Asynchronous tasks are not supported natively. By default, a failure in a task causes the failure of the whole workflow execution. It is possible to specify a retry policy for a state to manage faulty executions. Standard and express workflows are considered. Standard workflows can be used for long running, durable, and auditable workflows, while express workflows are suitable for high-volume, event-processing workloads. The given workflow language is available in a visual graph-based version as well as in JSON format.
Moreover, Amazon permits running Lambda functions on edge nodes using AWS IoT Greengrass that extends Cloud capabilities to local edge devices that connect to IoT devices. It is possible to deploy a Lambda function on such local devices. User configurations enable setting up memory limits for running functions and to selecting the lifecycle type of such functions. Similarly to AWS Step Functions workflows, two types of lifecycles are offered for GreenGrass functions: on-demand for short-lived functions that are stopped after the execution, and long-lived functions that run continuously.
From a security perspective, Amazon promotes a shared responsibility model, dividing the security of the Cloud and in the Cloud. Security of the Cloud is Amazon’s responsibility and it comprehends the infrastructure protection, in terms of hardware security and the layer of software that concerns storage, network and computation.
Security in the Cloud is the client’s responsibility and it comprehends sensitivity of data, company’s requirements, and applicable laws and regulations. To assist clients in performing identity and access management, AWS provides an identity and access management service that helps an administrator in securely controlling access to AWS resources.
It is the FaaS platform offered by Google. Similarly to AWS Lambda and Azure Functions, it supports fewer programming languages (viz. Node.js, Python, Go, and Java). Similarly to Amazon and Microsoft, Cloud Functions use triggers to execute functions. Billing is pay-per-use with precision at the level of hundreds of milliseconds. Google does not provide developers with specific languages and tools to compose serverless functions on its FaaS platform. Naturally, any programming language can be used by application developers to manually orchestrate HTTP requests to function end-points without specific support for FaaS orchestration constructs. Google Cloud Functions security is oriented to the access control, split across identity-based and network-based access control. The identity-based access control is granted on a per-function basis via Cloud access management to allow for control over developer operations or function invocations. In the network-based access control, access is controlled by specifying network settings for individual functions. This allows for more control over the network ingress and egress, i.e. to and from the functions.
It is an open-source FaaS platform, initially created by IBM and, later on, maintained by the Apache Foundation. OpenWhisk allows developers to write serverless functions — called Actions that can be dynamically scheduled and run in response to associated events via called Triggers from external sources or from HTTP requests. The full platform is resource demanding when executed on edge nodes. To get around this limitation and use the same codebase of the main project, OpenWhisk developers reduced the components of the full version to a smaller architecture that is more suited to be placed on edge nodes. They name it Lean OpenWhisk and the architecture on a node is reduced only to the Controller (responsible for load balancing) and the Invoker (responsible for executing serverless functions) of the full version, with a lean load-balancer to manage the handling of functions.
OpenWhisk delegates completely to the platform administrator the duty to secure the target infrastructure and to the functions operators the security of applications.
IBM cloud functions
Many existing platforms are built on top of Kubernetes and use it as their container orchestration engine for serverless functions. They run on private, public or hybrid Clouds and, being container-based, they can support any programming language of choice. The use of Kubernetes as orchestration engine for containers that will run serverless functions implies the possibility to run them on compatible edge nodes. Open source platforms are expected to provide more flexibility and control compared to the commercial ones at the price of having more responsibility in terms of security.
It is an open source community-based serverless framework that permits writing functions in every language, mapping them to incoming HTTP requests or other events. It allows orchestrating Fission functions with FissionWorkflows, still at an early stage of development, by expressing suitable YAML workflows as sequences of tasks to be executed. Tasks can be functions, HTTP requests to a service or control flow constructs. The constructs include conditional branching and many loop variants. The foreach construct features for parallel execution over different parts of the input.
It is a Kubernetes-native serverless framework, open source and community maintained, that allows deploying functions without having to worry about the underlying infrastructure. It uses Custom Resource Definitions (CRDs) to extend the Kubernetes API, which allows developers to interact with functions as if they were native Kubernetes objects. Runtimes and languages needed to deploy a function can be specified by the users.
It is a FaaS platform that leaves higher-level concepts (viz. API, CLIs, tooling) to a vendors to integrate with other platforms. It is open source and community-based. As Kubeless, it uses CRDs to extends the Kubernetes API. It can be integrated with Istio, a service that provides, authentication, authorisation and encryption of communication.
It is an open source serverless platform maintained by OpenFaaS Ltd. It permits, through a command-line interface, packing functions into Docker containers. In each container, a Web server acts as an entry point to the container and allows invoking the hosted function.
It is a serverless platform focused on data, I/O, and computeintensive workloads, maintained by Iguazio Ltd. It provides GPU execution and easy integration with data science libraries and tools. It is the only one of this group that proposes both a vanilla open source version and an enterprise version with extended features, viz. platform hosted on the maintainers’ Cloud and it is provided support for authentication and authorisation.
The above overview of the FaaS platform outlines the state of production-ready platforms out their today, I believe there are more to come so feel free to share in the comments.