Placing FaaS in the Fog, Securely Alessandro Bocci1 , Stefano Forti1 , Gian-Luigi Ferrari1 and Antonio Brogi1 1 University of Pisa, Pisa, Italy Abstract Placing FaaS applications onto Fog infrastructures is an open problem presenting various challenges. It requires considering hardware and software requirements of single functions as well as Quality of Service requirements of the overall application. In this article, we propose a declarative methodology to address the placement of FaaS applications onto Fog infrastructures, supported by a running prototype. Our methodology considers hardware and software requirements, and latency constraints on function- function and function-service interactions. Particular attention is given to information flow security constraints and trust relations among the involved stakeholders, to rank eligible output placements. A lifelike motivating example from augmented reality is used to showcase the prototype. Keywords Information-Flow Security, Function-as-a-Service, FaaS, Fog 1. Introduction The Function-as-a-Service (FaaS) model, started up by Amazon with AWS Lambda [1] in 2015, was primarily intended for Cloud settings. This brought an evolution in how software is organised and deployed in the Cloud [2]. Meanwhile, Fog computing [3, 4] emerged to exploit processing, storage and networking along the Cloud-IoT continuum – from personal devices, through network switches, to Cloud datacentres. The Fog is designed to support the stringent Quality of Service (QoS) requirements (e.g. on latency, security) of next-gen IoT applications as well as to improve the Quality of Experience (QoE) of the existing ones [5, 6, 7]. Indeed, Fog Computing permits processing – where it is best-suited along the Cloud-IoT continuum – the huge amounts of data that the Internet of Things (IoT) is producing daily so to enable prompter and insightful responses to sensed events. The FaaS paradigm supports the orchestration of stateless, event-triggered functions, ab- stracting from the target deployment stack, and possibly interacting with external services (e.g. databases, ML engines, geo-localisation engines) [8, 9]. Event-based serverless functions are naturally suited to define computation on IoT data, containerisation technologies are lightweight and seamlessly deployable on Fog nodes, and on-demand execution of functions can lead to improved usage of resource-constrained devices [10, 11, 12]. The natural combination of FaaS and Fog computing brings with it various challenges of both foundational and technological nature. In particular, a key issue concerns the definition of novel and effective strategies to place serverless functions over the pervasive Fog computing nodes. The placement problem, i.e. ITASEC21: Italian Conference on Cybersecurity, April 07–9, 2021 Envelope-Open alessandro.bocci@phd.unipi.it (A. Bocci); stefano.forti@di.unipi.it (S. Forti); gian-luigi.ferrari@unipi.it (G. Ferrari); antonio.brogi@unipi.it (A. Brogi) Orcid 0000-0002-7000-2103 (A. Bocci); 0000-0002-4159-8761 (S. Forti); 0000-0003-3548-5514 (G. Ferrari); 0000-0003-2048-2468 (A. Brogi) © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) finding the mappings from functions to Fog nodes, requires to consider hardware, software and QoS requirements of single functions as well as their composition into complex applications, and requirements on function bindings with external services. As other application placement problems in the Fog, deciding on the above is NP-hard, thus worst-case exp-time [13]. Speaking of QoS, FaaS placement requires constraining the function-function and function- service latencies, which are crucial to support latency-sensitive applications [14]. Furthermore, guaranteeing a high level of security is an important QoS aspect to consider [15, 16, 17] as a security flaw in a single function (or in its interactions with external services) may induce an overall security flaw of the function composition. Placing FaaS to Fog nodes therefore needs to consider different security contexts, the security level of data flowing between functions, and trust relations among application operators, and infrastructure and external service providers. All these are utterly important to avoid data leaks, e.g. by placing functions handling sensitive data onto insecure or untrusted nodes, or by binding a function to a service managed by an untrusted provider [18]. This article builds over our previous work on secure and trust-aware multiservice application placement in the Fog [17]. Our approach permits to express security requirements of IoT applications, as well as infrastructure security capabilities taking into account a trust model of the involved entities. An explainable assessment of the security level of the possible deployments is automatically derived.In this article, we showcase an extension of [17] over a lifelike motivating example. The extension includes three main directions: (𝑎) The definition of a declarative model to represent function requirements including security policies, and trust relations, (𝑏) The (formal) logical definition of the function placement problem, which exploits information- flow security [19] to determine functions’ security contexts, and commutative semirings to model and propagate trust [20], and (𝑐) A prototype1 of the above, FaaS2Fog, implemented by relying upon an algebraic extension of Prolog, to determine eligible placements (i.e. mappings from functions to Fog nodes) and function-service bindings (i.e. mappings from functions’ service requirements to actual service instances). We consider a simple orchestration mechanism where FaaS services are chained together as sequences of functions. We call it FaaS chains, and they represent a first step towards placing more complex FaaS orchestrations (e.g. those of OpenWhisk [21]). FaaS2Fog employs information-flow security [19] to avoid information leaks to untrusted/insecure nodes or services, and checks all hardware, software and latency chains requirements. Our approach features two desirable properties to support the placement of FaaS in the Fog. First, it is declarative, hence more concise, easier to understand and maintain compared with procedural solutions, and it offers high flexibility and extensibility, to accommodate the ever-changing needs of Fog scenarios. Second, it is intrinsically explainable as it derives proofs for input queries by relying on Prolog resolution engines, and it can be easily extended to justify why a certain placement decision was made, in the spirit of explainable AI [22]. The rest of this article is organised as follows. After describing a lifelike motivating example from augmented reality (Sect. 2), we illustrate FaaS2Fog methodology (Sect. 3), used to solve 1 Open sourced and freely available at: https://github.com/di-unipi-socc/FaaS2Fog. and discuss the motivating example (Sect. 4). After presenting closely related work (Sect. 5), we conclude by pointing to some directions for future work (Sect. 6). 2. Motivating Example This section illustrates a lifelike motivating example to highlight the challenges related to the FaaS chain placement problem. Consider an Augmented Reality (AR) application trying to avoid people gatherings in commercial areas of a city centre, so to contrast the spreading of Covid-19, by load-balancing people presence across similar shops. When users point with their smartphones the entrance of a shop they are about to enter, the application renders over the video 3D information about the number of people inside and its overall capacity. If a high risk of gathering is detected, the application suggests alternative similar locations to the users by giving them 3D AR directions, along with incentives (e.g. discounts, special offers) to move away from the gathering area. Such an application is implemented by a FaaS chain (Fig. 1): 1. 𝑓𝐿𝑜𝑔𝑖𝑛 , which authenticates the user into the service, 2. 𝑓𝑆ℎ𝑜𝑝 , which recognises the shop entrance in the framed images, so to discriminate among physically close activities, 3. 𝑓𝐺𝑒𝑜 , which identifies the shop by its image and coordinates via an external map service, also retrieving all shop information, 4. 𝑓𝐺𝑎𝑡ℎ𝑒𝑟 , which computes the risk of gathering (based on crowd-sensed information), individuates alternative shops and incentives to move there, 5. 𝑓𝐴𝑅 , which renders AR information over the framed video footage and sends it back to the mobile client. For each function in the chain, Fig. 1 lists the software requirements in terms of required runtime support, and the hardware requirements. For instance, function 𝑓𝑆ℎ𝑜𝑝 needs Python3 and NumPy to be available on the deployment node, along with 2 GB of RAM, and 4 vCPUs at 1.5 GHz at least. Coordinates, ShopInfo, UserInfo 13 ms 30 ms 12 ms ShopInfo GahterInfo 12 ms 10 ms 13 ms 10 ms 15 ms UserInfo, fLogin Screenshot, f FLogin Shop Screenshot, fGeo Screenshot, fGather Screenshot, f AR Screenshot, [py3] [py3] Coordinates, [py3,numPy] [py3,numPy] CroppedShop, [js] [js] CroppedShop, [js] InfoToDraw [py3,numPy] [py3,numPy] Coordinates, 1GB 1GB RAM RAM SensorsInfo 2GB RAM 2GB RAM Coordinates, 1GB 1GB RAM RAM ShopInfo 1GB 1GB RAM RAM 2GB RAM 2GB RAM SensorsInfo 2vCPUs 2vCPUs 4vCPUs 4vCPUs SensorsInfo 2vCPUs 2vCPUs 2vCPUs 2vCPUs 4vCPUs 4vCPUs 0.5GHz 0.5GHz 1.5GHz 1.5GHz 0.4GHz 0.4GHz 0.5GHz 0.5GHz 1.2GHz 1.2GHz Figure 1: Example FaaS chain. Each function connects to the type of external service(s) it will need to bind with at runtime (represented as dashed circles). As an example, function 𝑓𝐿𝑜𝑔𝑖𝑛 needs to bind to an instance of the userDB service. Function-function and function-service interactions (represented as arrows) are annotated with the parameters they exchange and with the maximum end-to-end latency they tolerate between their deployment nodes. For instance, 𝑓𝐿𝑜𝑔𝑖𝑛 passes to 𝑓𝑆ℎ𝑜𝑝 a Screenshot of the framed shop, with its geographical Coordinates, and SensorsInfo from the client smartphone. Such interaction tolerates a latency of at most 10 ms. To prevent sensible data from leaking, chain input parameters are labelled with suitable security types, as those in the lattice of Fig. 2, modelling the security level pertaining to certain sensible data from top (i.e. secret) to low (i.e. public). Those security labels propagate with data along the function chain (and across external services), determining top a security context for each function (and service), based medium on the data it will process. For instance, 𝑓𝐿𝑜𝑔𝑖𝑛 inputs UserInfo, Screenshot, Coordinates, SensorsInfo can be low labelled by the tuple (top, low, low, low), assigning to Figure 2: Example security lattice. such function the highest type among those, i.e. top. Se- curity types propagate to the outputs (Screenshot, Coordinates, SensorsInfo) with the labels (low, low, low), which will be used in turn to determine the (low) security context of 𝑓𝑆ℎ𝑜𝑝 . Finally, we assume that chain triggers come from event generators – invoking suitable orches- trator API – that are connected to infrastructure nodes. In our example, the event generator is the client application, which we assume to connect to the closest available node. Functions in each chain are executed sequentially, and the final result of the computation is returned to the client application. Fig. 3 sketches the target (city centre) Fog infrastructure, upon which the chains described above will be placed and run. Nodes are owned and managed by different providers, the information we need are their software and hardware capabilities, the services they host, and their security countermeasures, expressed as per the taxonomy of Fig. 4 (as in [17]). The countermeasures will be used to specify (i) the security policies in force and (ii) to assign security labels to nodes. Service Service Service cloudNode Id Type Provider (cloudProvider) myUsers userDB appOp [all] ∞GB,∞CPUs,∞GHz cMaps maps cloudProvider [all] openM maps openS 30 ms myShop shops. appOp ispRouter (telco) [py3,js,numPy] 4GB,4vCPUs,2GHz [antiTamp,pubKeyE] 5 ms 6 ms 7 ms 8 ms switch southAntenna 12 ms northAntenna private1 (university) 80 ms (telco) (telco) (privateCitizen1) [py3,js] [py3,numPy] [js] [js] 5 ms 2GB,2vCPUs,2GHz 7 ms 2GB,4vCPUs,1.5GHz 2GB,2vCPUs,1.5GHz 1GB,2vCPUs,2.5GHz [pubKeyE] [pubKeyE] [antiTamp,pubKeyE] [] 7 ms labServer 7 ms officeServer private2 (university) (university) (privateCitizen2) [py3,js,numPy] [py3] [py3] 4GB,4vCPUs,2GHz 1GB,2vCPUs,1GHz 0.5GB,1vCPUs,1GHz [antiTamp,pubKeyE] [] [pubKeyE] Figure 3: Example Fog infrastructure. As an example, node switch, owned by university, supports Python and Javascript code, and features 2 GB of RAM, 2 vCPUs at 2 GHz, and public key encryption as security countermeasure. Services instances are managed by their providers that detail information about service types and deployment nodes. For instance, service cMaps provided by cloudProvider is of type maps and is deployed to node cloudNode. Links between nodes are annotated with their end-to-end latency, e.g. the latency between ispRouter and northAntenna is 8 ms. FOG SECURITY Virtualisation Communication Data Physical Other Access Logs Certificates Backup Access Control Audit Anti-tampering Authentication Firewall Encrypted Storage Capabilities IoT Data Encryp- Obfuscated Stor- Host IDS tion age Node Isolation Process Isolation Mechanims Permission Model Network IDS Resource Usage Public Key Cryp- Monitoring tography Restore Points Wireless Security User Data Isola- tion Figure 4: Security capabilities for Fog computing. Deploying the chain in Fig. 1 onto infrastructure of Fig. 3 requires satisfying all functions’ software, hardware and latency requirements, and determining a suitable binding from functions to the service instances they need. Furthermore, function labels and node labels should be compatible, i.e. a node can host a function only if it features an equal or higher security label. As an example, the application operator can establish that a node featuring public key encryption without anti-tampering is labelled as medium security. This means that the node can only support functions labelled either low or medium. Note that this is required to avoid leaking data from a higher to a lower security context. The problem we aim at solving in the above scenario is as follows: Is there any eligible placement and service binding of chainGath over the available Fog infrastructure, such that all software, hardware, latency, external service, security requirements are met, and data leaks are avoided? Can trust relations among involved stakeholders help in evaluating the quality of eligible placements? In Sect. 4 we will show how our methodology and prototype FaaS2Fog can be used to answer the above questions. 3. Methodology In this section, we describe our methodology to place FaaS chains to Fog infrastructure. We illustrate both the modelling (Sect. 3.1) and the declarative solution (Sect. 3.2) of the problem, showing the main Prolog2 facts where clarifications are needed. 3.1. Modelling Applications, Infrastructures and Trust Declaring FaaS Chains. Application operators declare the requirements of a function F they will chain into FaaS applications using functionReqs(F, SoftwareRequirements, HardwareRequirements, ServiceTypeRequirements). Such requirements include SoftwareRequirements and HardwareRequirements, as well as Service- TypeRequirements used to bind at run time service instances to be invoked by the function. The function behaviour of a function F is defined by a relation between security types of input data (Inputs), output data (Outputs) and data exchanged with external services (Service- Interactions). The declaration of function behaviours is functionBehaviour(F, Inputs, ServiceInteractions, Outputs):- ... We assume that such information can be defined manually, or obtained by exploiting static analyses and type systems (see e.g. [23, 24]). A Function chain FChain managed by Operator is declared as functionChain(FChain, Operator, EventTrigger, Functions, Latencies). where are included the list of Functions forming the chain, the FaaS Operator, the EventTrig- ger associated with the chain, and the maximum tolerated Latencies from the trigger to the first chain function, and between consecutive chained functions. Chain triggers are denoted by pairs containing the trigger source and the list of security labels of its parameters (e.g. [top,low,low,low]). Those security labels will match the input types of the first function and propagate along the chain according to declared function behaviours. Chained functions are denoted by pairs containing a function identifier and a list of actual service instances each function will bind to. Bindings either specify a certain service instance identifier or are left unbound, meaning that any service of the required type can satisfy the requirement. Application operators also declare a lattice of the security types to define their functions and function chains, as the one in Fig. 2, using g_lattice_higherThan(Higher, Lower). to represent each ordered pair of the lattice with the Higher and the Lower security types. Declaring Fog Infrastructures. Infrastructure node are declared as node(NodeId, ProvId, SecCaps, SWCaps, HWCaps). including the NodeId (e.g. its IP address) and the security, software and hardware capabilities featured by the node (viz. SecCaps, SWCaps and HWCaps), which enable FaaS2Fog to check the latter against function requirements. Security capabilities are lists of literals from Fig. 4. End-to-end links between nodes (NId1 and NId2) are associated with the average Latency in milliseconds experienced between the nodes, declared as 2 A Prolog program is a finite set of clauses of the form: a :- b1, ... , bn. stating that a holds when b1 ∧ ⋯ ∧ bn holds, where n≥0 and a, b1, ..., bn are atomic literals. Clauses with empty condition are also called facts. Prolog variables begin with upper-case letters, lists are denoted by square brackets, and negation by \+. Conventionally, a Prolog predicate pred with N arguments is indicated as pred/N. g_link(NId1, NId2, Latency). External services, running on available nodes, are declared by service providers as service(ServiceId, ServiceProvider, ServiceType, NodeId). where are specified the ServiceId, the identifier of the ServiceProvider, the ServiceType, and the NodeId of the service host node. The declaration of an event generator EG is eventGenerator(EG, EventType, NodeId). and it includes the EventType of generated triggers it can generate as well as the NodeId of the node with which it is connected. It is worth noting that data about infrastructure capabilities, services and event generators can be obtained by exploiting available monitoring tools targeting Fog settings (e.g. FogMon [25], or one of the tools surveyed in [26]). Declaring Security Policies. The security context of nodes and external services is determined according to the security policies specified by application operators. Node and service labelling is performed as per the same security types of functions parameters to guarantee that types can be checked against each other and to enforce that functions are placed onto nodes and interacts with services that feature at least their security type. Node labelling is specified by the declaration assignNodeLabel(Node, SecurityContextLabel) :- ... meaning that the SecurityContextLabel is assigned to the Node if all conditions of the right hand-side of the rule hold. For example, a node is labelled top only if such node features both anti-tampering and public key encryption among its security capabilities. Analogously, external services are labelled by defining the security policies based on the available service information. Declaring Trust Opinions. All involved stakeholders (i.e. application operators, infrastructure providers, service providers) can declare trust opinions towards each other. Following [20], trust relations are modelled as pairs (𝑇 , 𝐶) ∈ [0, 1] × [0, 1] where 𝑇 represents a level of trust (the higher the better) and 𝐶 the confidence in (i.e. the quality of) such value 𝑇, based on trust monitoring data. By employing a dialect of Prolog, viz. 𝛼-Problog [27], trust opinions are declared as facts annotated with (𝑇 , 𝐶), in the form (T,C)::trustOpinion(Stakeholder1, Stakeholder2). where Stakeholder1 declares her trust level and confidence toward Stakeholder2. 3.2. Placing FaaS Chains onto Fog Infrastructures In this section, we briefly illustrate how FaaS2Fog determines FaaS application placements, based on the modelling described in the previous section. Fig. 5 lists the faas2fog/2 predicate, giving an overview of the overall functioning of our prototype. After retrieving a function chain by its identifier CId (line 2), faas2fog/2 retrieves also an event generator associated to the chain, if any (line 3). Then, after propagating security types along the FaaS chain to determine the security contexts needed by each function (line 4), faas2fog/2 determines an eligible FaaS chain Placement satisfying all set requirements (line 5). 1 faas2fog(CId, Placement):- 2 functionChain(CId, AppOp, (GeneratorId,TriggerTypes), FList, LatReqs), 3 eventGenerator(GeneratorId, GeneratorNode), 4 typePropagation(TriggerTypes, FList, TFList), 5 mapping(AppOp, TFList, LatReqs, GeneratorNode, Placement). Figure 5: The faas2fog/2 predicate. FaaS2Fog carries out three main steps to determine eligible placement of FaaS application: 1. Propagating Security Types. First, the typePropagation/3 predicate listed in Fig. 6 performs security type propagation along the chain to be placed. By recursively scanning the list of chained functions, typePropagation/3 instantiates the security types of all (input, output, exter- nal) parameters using the functionBehaviour/4 predicate, declared by the application operator for each function (line 3). The current function F is then assigned the highest security type FType among the security labels of the parameters it handles determined by highestType/2 (lines 4–6). The third argument of typePropagation/3 accumulates this new information for all functions. Newly determined output types are used as input types for the next function in the chain, and so on so forth. 1 typePropagation(_, [], []). 2 typePropagation(InTypes,[(F,FServices)|FunctionList], [(F,FServices,FType)|TypedFunctionList]):- 3 functionBehaviour(F, InTypes, InteractionsTypes, OutTypes), 4 append(InTypes, InteractionsTypes, TempTypes), append(TempTypes, OutTypes, AllTypes), sort(AllTypes, AllTypesSorted), 5 highestType(AllTypesSorted,FType), 6 typePropagation(OutTypes, FunctionList, TypedFunctionList). Figure 6: The typePropagation/3 predicate. 2. Resource- & QoS-aware Placement. After this step, the mapping/7 (Fig. 7) scans the list of typed functions TFList and determines an eligible placement for each of them, until the list is empty (line 1). For each function F to be placed, mapping/7 non-deterministically selects a candidate node N (line 3) and checks the latency constraint between N and the node of the previously allocated function3 (line 4). Then, software and hardware requirements of F are checked against N capabilities (lines 5–6). Notably, the predicate hwReqsOK/5 also checks whether cumulative hardware requirements allow placing F onto N, i.e. whether, due to the allocation of previous functions OldAllocHW, the current capacity of N can still host F as well. If this is possible, the hardware allocation is updated by summing the hardware required by F to the allocated hardware at N into AllocHW. Consequently, the compatibleNodeType/2 predicate checks whether the security context of N (determined by the assignNodeLabel/2 provided by the application operator) is compatible with the security context required by the function. Finally, the bindServices/6 predicate determines if bindings to external services comply to security and latency constraints of the function to be placed. Note that when a binding requirement is left unbound, bindServices/6 can determine eligible services (if any) that satisfy the requirements. Each placement and binding for F is accumulated in the last parameter of mapping/7, in tuples like on(F,N,FBinding). Such result will be returned by faas2fog/2. 3. Trust Propagation. FaaS2Fog also considers trust relations by using the semiring-based 3 In case of the first function, mapping/7 checks the latency from the event generator. 1 mapping(_, [], [], _, AllocHW, AllocHW, []). 2 mapping(AppOp, [(F,FServices,FType)|TFList], [ReqLatency|LatReqs], PreviousNode, OldAllocHW, NewAllocHW, [on(F,N,FBinding)|P]):- 3 getNode(N, SWCaps, HWCaps), 4 link(PreviousNode, N, FeatLatency), FeatLatency =< ReqLatency, 5 functionReqs(F, SWReqs, HWReqs, FServicesReqs), 6 swReqsOK(SWReqs, SWCaps), 7 hwReqsOK(HWReqs, HWCaps, N, OldAllocHW, AllocHW), 8 compatibleNodeType(FType,N), 9 bindServices(AppOp, N, FServices, FType, FServicesReqs, FBinding), 10 mapping(AppOp, TFList, LatReqs, N, AllocHW, NewAllocHW, P). Figure 7: The mapping/7 predicate. modelling of [20] to aggregate opinions from different stakeholders. Trust propagation is conditioned to a maximum radius of 3 hops in the trust graph, assuming that each stakeholder trusts herself with a (1, 1) opinion. Following the model of [20], we propagate trust from 𝐴 to 𝐵 as follows: opinions along paths from 𝐴 to 𝐵 are multiplied, while opinions across paths from 𝐴 to 𝐵 are summed. We employ the multiplication (⊗) and sum (⊕) operations of Fig. 8, implemented as in [17] via 𝛼-Problog. Trust relations are checked between the appli- cation operator and the node operator where functions are placed. Analogously, trust re- ⟨𝑇 , 𝐶⟩ ⊗ ⟨𝑇 ′ , 𝐶 ′ ⟩ = ⟨𝑇 𝑇 ′ , 𝐶𝐶 ′ ⟩ lations are checked between the application if 𝐶 > 𝐶 ′ ⎧⟨𝑇 , 𝐶⟩ operator and external service providers. Re- ′ ′ ⟨𝑇 , 𝐶⟩ ⊕ ⟨𝑇 , 𝐶 ⟩ = ⟨𝑇 , 𝐶 ⟩′ ′ if 𝐶 ′ > 𝐶 lying on 𝛼-Problog, FaaS2Fog annotates each ⎨ ′ ′ ⎩⟨max{𝑇 , 𝑇 }, 𝐶⟩, if 𝐶 = 𝐶 output eligible placement with its overall trust assessment computed as described above. Figure 8: Semiring ⊗ and ⊕ operations. 4. Motivating Example Revisited In this section, we solve the motivating example4 of Sect. 2 by answering the questions raised therein. Security policies to label services specify that all the services provided by appOp are labelled top, the maps services provided by cloudProvider are labelled medium, and all the other services are labelled low. We assume that input parameters generated by userDevices triggering the chain are labelled [top,low,low,low], only considering user’s data as sensitive information. Given these ingredients, we simply query the main predicate of FaaS2Fog, faas2fog(chainGath, Placement), to determine eligible placements for the FaaS chain. FaaS2Fog matches trigger types with the input labels of function 𝑓𝐿𝑜𝑔𝑖𝑛 (UserInfo, Screenshot, Coordinates, SensorsInfo) and, by propagation, it determines the labelling of functions5 as: (𝑓𝐿𝑜𝑔𝑖𝑛 , top), (𝑓𝑆ℎ𝑜𝑝𝑠 , low), (𝑓𝐺𝑒𝑜 , low), (𝑓𝐺𝑎𝑡ℎ𝑒𝑟 , medium), and (𝑓𝐴𝑅 , medium). Afterwards, eligible placements and service bindings meeting all software, hardware, latency, and security requirements of the chain of Fig. 1 are looked for by the placement phase. Table 1 summarises all obtained results. They are 9 eligible placements 4 Full example code at: https://github.com/di-unipi-socc/FaaS2Fog/tree/main/examples/ITASEC21 5 Note that, labelling Coordinates as medium, we would obtain a different labelling, i.e. (𝑓𝐿𝑜𝑔𝑖𝑛 , top), (𝑓𝑆ℎ𝑜𝑝𝑠 , medium), (𝑓𝐺𝑒𝑜 , medium), (𝑓𝐺𝑎𝑡ℎ𝑒𝑟 , medium), and (𝑓𝐴𝑅 , medium). and bindings – 𝑃1-𝑃9, one per row – that satisfy all set requirements. Each column in the table corresponds to a chain function and lists the placement node and the service bindings. It is worth mentioning that while service bindings are already specified for 𝑓𝐿𝑜𝑔𝑖𝑛 (with the service myUserDB) and for 𝑓𝐺𝑎𝑡ℎ𝑒𝑟 (with the service myGatherS), the binding of 𝑓𝐺𝑒𝑜 was left unbound and is determined by FaaS2Fog so to meet the required low security context. As a consequence, depending also on function-service latency considerations, such requirement is bound either to the openM (e.g. 𝑃1) or to the cMaps instance (e.g. 𝑃2). f Login f Shop f Geo f Gather f AR Node Bindings Node Bindings Node Bindings Node Bindings Node Bindings P1 ispRouter myUserDB labServer - ispRouter openM switch myGathS southAntenna - P2 ispRouter myUserDB labServer - ispRouter cMaps switch myGathS southAntenna - P3 ispRouter myUserDB labServer - switch openM ispRouter myGathS southAntenna - P4 ispRouter myUserDB southAntenna - ispRouter cMaps switch myGathS labServer - P5 ispRouter myUserDB southAntenna - ispRouter openM switch myGathS labServer - P6 ispRouter myUserDB southAntenna - northAntenna openM ispRouter myGathS labServer - P7 ispRouter myUserDB southAntenna - private1 openM ispRouter myGathS labServer - P8 ispRouter myUserDB southAntenna - switch openM ispRouter myGathS labServer - P9 labServer myUserDB ispRouter - labServer openM switch myGathS southAntenna - Table 1 Eligible placements for the example. We now also consider the trust network of Fig. 9, where links are annotated with (Trust, Confidence) values. For instance, appOp has a trust level of 0.99 with confidence 0.9 toward the telco provider, and a trust level of 0.9 with confidence 0.9 toward the cloudProvider provider. Table 2 lists the trust and confidence values associated to the found placements 𝑃1–𝑃9, listed in Table 1. Trust assessment allows application operators to select one (or more) best candidate placement(s), as well as to set a minimum trust level to meet. For instance, blindly choosing the first result 𝑃1 of Table 1 actually leads to selecting one of the placements which can be trusted less (viz. (0.27, 0.23)) among the eligible ones. By considering trust assessment, the application operator will instead likely choose 𝑃4, with the best trust level (viz. (0.77, 0.48)). 0.9,0.9 telco university Trust 0.5,0.9 P1 (0.27, 0.23) 0.99,0.9 0.8,0.85 0.9,0.9 P2 (0.61, 0.31) private1 P3 (0.27, 0.23) appOp P4 (0.77, 0.48) 0.6,1 P5 (0.34, 0.35) 0.9,0.9 0.9,0.9 P6 (0.34, 0.31) private2 0.8,1 P7 (0.17, 0.28) 0.8,0.9 openS P8 (0.30, 0.28) 0.89,0.9 P9 (0.24, 0.21) cloudProvider Figure 9 Table 2 Example trust network. Ranking of eligible placements. . 5. Related Work In this section, we survey some closely related work proposing declarative solutions to resource management in Cloud or Fog scenarios and techniques to assist the placement of orchestrated serverless functions in the Fog. Speaking of declarative approaches to resource management, some have been proposed to manage Cloud resources (e.g. [28]) and to improve network usage (e.g. [29]). We employed 𝛼-Problog prototypes to assess the security and trust levels of different multiservice application placements [17], and to securely place VNF chains and steer traffic across them [30]. The taxonomy of Fig. 4 to express security policies was introduced in [17], where trust relations modelled via semirings were introduced. Differently from FaaS2Fog, it determines placements of multiservice applications (i.e. not FaaS-based) without considering information flow security, external service interactions, nor hardware and software requirements of services to be placed. Similarly, focussing on Software-defined Networking (SDN) domains, [30] considers neither trust relations nor information flow security, but only security requirements as AND-OR combinations of the taxonomy elements. Closely related to these, [31] devises a (non-declarative) solution to the problem of placing multiservice applications over multiple nodes, configuring hardware/software security controls without considering information-flow nor trust. Targeting FaaS architectures, Pinto et al. [32] dynamically decide whether to run a serverless function within the local Edge network or in the Cloud, based on monitored data. An Edge proxy is in charge of making such a decision, also considering network failures. On the same line, Das et al. [33] present an edge-based framework to dynamically decide whether to execute a function in the Cloud or locally, by estimating operational costs and improving end-to-end latencies. Similarly, Aske and Zhao [34] present a serverless monitoring and scheduling system to select FaaS providers, based on average execution time, affinity constraints, and costs – possibly considering user-defined scheduling policies. Cho et al. [35] discuss a solution to distribute FaaS tasks over hierarchical Fog infrastructures, by employing a token bucket algorithm and einforcement learning to optimise workload distribution and response times. Cicconetti et al. [36] propose an architecture to realise serverless computing SDN scenarios where network routers assign function execution to edge devices based on arbitrary costs (e.g. latency, bandwidth, energy). The infrastructure is monitored and updated by SDN controllers, and different strategies try to optimise operational costs and load-balancing. More recently, based on their model to annotate function requirements [37], Rausch et al. [38] discuss a Kubernetes-based scheduler to optimise the placement of FaaS in the Fog based on a linear combination of proximity to image registries and to data producers, available node resources and Edge or Cloud locality. Bermbach et al. [39] take an infrastructure provider’s perspective to FaaS placement in the Fog, using distributed auctions. Programmers submit functions to target nodes along with a resource bid, based on which nodes decide whether to run functions. Only [40] and [41] exploit information flow security to check that no leak is present in FaaS orchestrations, at runtime. Differently from FaaS2Fog, security types are not exploited to deter- mine eligible FaaS placements. To the best of our knowledge, none of the previously proposed approaches considers information-flow security, or infrastructure security countermeasures, or trust relations when performing latency-aware placement of FaaS orchestrations in the Fog. 6. Concluding Remarks This article introduced a life-like example concerning the problem of determining eligible placements of FaaS chains to Fog infrastructures, that is addressed with a declarative method- ology and its prototype, FaaS2Fog. Our approach considers hardware, software and latency requirements, and exploits information-flow security policies as well as infrastructure security capabilities. Eligible placements are ranked by employing semiring-based trust relations among the involved stakeholders. From the architectural viewpoint, FaaS2Fog employs information on the application, on its security types and on infrastructure labelling policies (declared by application operators), data on infrastructure capabilities (collected via distributed monitoring tools, and declared by infrastructure operators), and trust relations (declared by all involved providers). Our approach shows some qualifying strenghts to address FaaS placement in Fog scenarios. Its declarative nature makes it easier to define FaaS chain requirements and security policies, infrastructure capabilities, and trust relations. Moreover, it naturally supports a flexible approach since it allows the definition of new requirements (e.g. bandwidth, availability of specialised hardware) or security considerations (e.g. provider whitelisting). Finally, placement explanation can be obtained by taking advantage of proof paths determined via the 𝛼-Problog engine. Thus, employing explainable placements combined with information-flow and trust assessment can reduce the possibility of leaking critical data to untrusted or insecure parties during the deployment of FaaS chains. On the other hand, FaaS2Fog does not yet handle structured FaaS orchestrations, obtained by combining functions with traditional control mechanisms (e.g. branches, loops). This needs to be addressed to model more complex use cases, also extending information flow analyses to the general case. Additionally, human-readable explanations on why a certain placement was (or was not) output would further improve interactions with the users and their trust in systems based on the proposed methodology. Finally, FaaS2Fog incurs in worst-case exp-time to determine valid placements. As serverless functions are usually on-demand and short-lived, it is crucial to assess execution times over larger examples, and to improve on those via heuristics or continuous reasoning [42]. In addition to tackling all aforementioned points, in our future work we plan to extend the methodology underlying FaaS2Fog by formally defining type judgement rules for a feature- complete orchestration language, showing how they can be naturally expressed in 𝛼-Problog. Last, we intend to implement a service based on FaaS2Fog and on the Logic-Programming-as- a-Service paradigm [43], and to experiment with actual FaaS deployments in Fog settings by relying on open-source orchestration engines such as OpenWhisk with IBM Composer [21]. Acknowledgments This work has been partly supported by project “Lightweight Self-adaptive Cloud-IoT Monitoring across Fed4FIRE+ Testbed” (LiSCIo) funded by Fed4Fire+ and“Continuous QoS-compliant Man- agement of Software Applications over the Cloud-IoT Continuum” (CONTWARE) funded by the Conference of Italian University Rectors. References [1] AWS Lambda, https://aws.amazon.com/it/lambda/, Accessed: Apr. 2021. [2] V. Yussupov, J. Soldani, U. Breitenbücher, A. Brogi, F. Leymann, FaaSten your decisions: A classification framework and technology review of Function-as-a-Service platforms, Journal of Systems and Software 175 (2021) 110906. [3] F. Bonomi, R. Milito, P. Natarajan, J. Zhu, Fog computing: A platform for internet of things and analytics, in: Big data and internet of things, volume 546, 2014, pp. 169–186. [4] P. Habibi, M. Farhoudi, S. Kazemian, S. Khorsandi, A. Leon-Garcia, Fog Computing: A Comprehensive Architectural Survey, IEEE Access 8 (2020) 69105–69133. [5] R. Mahmud, S. N. Srirama, K. Ramamohanarao, R. Buyya, Quality of Experience (QoE)- aware placement of applications in Fog computing environments, J. Parallel Distributed Comput. 132 (2019) 190–203. [6] C. Guerrero, I. Lera, C. Juiz, Evaluation and efficiency comparison of evolutionary algo- rithms for service placement optimization in fog architectures, Future Gener. Comput. Syst. 97 (2019) 131–144. [7] A. Brogi, S. Forti, A. Ibrahim, Optimising QoS-assurance, Resource Usage and Cost of Fog Application Deployments, in: CLOSER (Selected Papers), CCIS, volume 1073, 2018, pp. 168–189. [8] I. B. et al., Serverless computing: Current trends and open problems, in: Res. Adv. in Cloud Comp., 2017, pp. 1–20. [9] E. Jonas, J. Schleier-Smith, V. Sreekanti, C. Tsai, A. Khandelwal, Q. Pu, V. Shankar, J. Carreira, K. Krauth, N. J. Yadwadkar, J. E. Gonzalez, R. A. Popa, I. Stoica, D. A. Patterson, Cloud Programming Simplified: A Berkeley View on Serverless Computing, CoRR abs/1902.03383 (2019). [10] M. S. Raghavendra, P. Chawla, A review on container-based lightweight virtualization for fog computing, in: ICRITO, 2018, pp. 378–384. [11] D. von Leon, L. Miori, J. Sanin, N. El Ioini, S. Helmer, C. Pahl, A lightweight container middleware for edge cloud architectures, Fog and edge computing (2019) 145–170. [12] T. Pfandzelter, D. Bermbach, tinyfaas: A lightweight faas platform for edge environments, in: ICFC, 2020, pp. 17–24. [13] A. Brogi, S. Forti, QoS-Aware Deployment of IoT Applications Through the Fog, IEEE Internet Things J. 4 (2017) 1185–1192. [14] M. Großmann, C. Ioannidis, D. T. Le, Applicability of serverless computing in fog computing environments for iot scenarios, in: UCC Companion, 2019, pp. 29–34. [15] J. Ni, K. Zhang, X. Lin, X. Shen, Securing fog computing for internet of things applications: Challenges and solutions, IEEE Comm. Surveys & Tutorials 20 (2017) 601–628. [16] L. M. Vaquero, F. Cuadrado, Y. Elkhatib, J. Bernal-Bernabe, S. N. Srirama, M. F. Zhani, Research challenges in nextgen service orchestration, Future Gener. Comput. Syst. 90 (2019) 20–38. [17] S. Forti, G. L. Ferrari, A. Brogi, Secure cloud-edge deployments, with trust, Future Gener. Comput. Syst. 102 (2020) 775–788. [18] A. Bocci, S. Forti, G.-L. Ferrari, A. Brogi, Secure FaaS orchestration in the fog: how far are we?, Computing (2021) 1–32. [19] A. Sabelfeld, A. C. Myers, Language-based information-flow security, IEEE J. Sel. Areas Commun. 21 (2003) 5–19. [20] S. Bistarelli, S. N. Foley, B. O’Sullivan, F. Santini, Semiring-based frameworks for trust propagation in small-world networks and coalition formation criteria, SCN 3 (2010) 595–610. [21] IBM OpenWhisk, https://cloud.ibm.com/docs/openwhisk, Accessed: Apr. 2021. [22] H. Hagras, Toward human-understandable, explainable AI, Computer 51 (2018) 28–36. [23] F. Pottier, C. Skalka, S. F. Smith, A systematic approach to static access control, ACM Trans. Program. Lang. Syst. 27 (2005) 344–382. [24] M. Bartoletti, P. Degano, G. L. Ferrari, R. Zunino, Semantics-based design for secure web services, IEEE Trans. Software Eng. 34 (2008) 33–49. [25] S. Forti, M. Gaglianese, A. Brogi, Lightweight self-organising distributed monitoring of Fog infrastructures, Future Gener. Comput. Syst. 114 (2021) 605–618. [26] S. Taherizadeh, A. C. Jones, I. Taylor, Z. Zhao, V. Stankovski, Monitoring self-adaptive applications within edge computing frameworks: A state-of-the-art review, J. Syst. Softw. 136 (2018) 19–38. [27] A. Kimmig, G. Van den Broeck, L. De Raedt, An algebraic Prolog for reasoning about possible worlds, in: AAAI, 2011. [28] S. Kadioglu, M. Colena, S. Sebbah, Heterogeneous resource allocation in Cloud Manage- ment, in: NCA 2016, 2016, pp. 35–38. [29] T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell, S. Shenker, Practical declarative network management, in: WREN, 2009, pp. 1–10. [30] S. Forti, F. Paganelli, A. Brogi, Probabilistic QoS-aware Placement of VNF chains at the Edge, Theory Pract. Log. Program. (2021). In press. [31] Z. Á. Mann, Secure software placement and configuration, Future Gener. Comput. Syst. 110 (2020) 243–253. [32] D. Pinto, J. P. Dias, H. S. Ferreira, Dynamic allocation of serverless functions in iot environments, in: EUC, 2018, pp. 1–8. [33] A. Das, S. Imai, S. Patterson, M. P. Wittie, Performance Optimization for Edge-Cloud Serverless Platforms via Dynamic Task Placement, in: CCGRID, 2020, pp. 41–50. [34] A. Aske, X. Zhao, Supporting multi-provider serverless computing on the edge, in: ICPP, 2018, pp. 20:1–20:6. [35] C. Cho, S. Shin, H. Jeon, S. Yoon, Qos-aware workload distribution in hierarchical edge clouds: A reinforcement learning approach, IEEE Access 8 (2020) 193297–193313. [36] C. Cicconetti, M. Conti, A. Passarella, A decentralized framework for serverless edge computing in the internet of things, IEEE Trans. Netw. Serv. Manag. (2020) 1–14. [37] T. Rausch, W. Hummer, V. Muthusamy, A. Rashed, S. Dustdar, Towards a serverless platform for edge AI, in: HotEdge, 2019. [38] T. Rausch, A. Rashed, S. Dustdar, Optimized container scheduling for data-intensive serverless edge computing, FGCS 114 (2021) 259–271. [39] D. Bermbach, S. Maghsudi, J. Hasenburg, T. Pfandzelter, Towards auction-based function placement in serverless fog platforms, in: ICFC, 2020, pp. 25–31. [40] K. Alpernas, C. Flanagan, S. Fouladi, L. Ryzhyk, M. Sagiv, T. Schmitz, K. Winstein, Secure serverless computing using dynamic information flow control, OOPSLA 2 (2018) 1–26. [41] P. Datta, P. Kumar, T. Morris, M. Grace, A. Rahmati, A. Bates, Valve: Securing function workflows on serverless computing platforms, in: WWW, 2020, pp. 939–950. [42] S. Forti, A. Brogi, Continuous Reasoning for Managing Next-Gen Distributed Applications, in: ICLP (Technical Communications), volume 325 of EPTCS, 2020, pp. 164–177. [43] R. Calegari, E. Denti, S. Mariani, A. Omicini, Logic programming as a service, Theory Pract. Log. Program. 18 (2018) 846–873.