Enarx FAQ
The project aim is this:
- Create a way to create and run "private, fungible, serverless" applications using Trusted Execution Environments (TEEs). In other words, to provide a platform abstraction for TEEs.
The problem we're trying to address is that there are many sensitive workloads that you shouldn't entrust to a public cloud to run, or may even have concerns about running on on-premises systems. TEEs (see below) provide a great opportunity to help secure these workloads, but they're not easy to use. Enarx aims to make it simple to deploy workloads to a variety of different TEE technologies in the cloud, on your premises or elsewhere, and to ensure that your application workload is as secure as possible.
You can find a basic introduction here: Introducing Enarx.
If you like your information presented visually, here's the problem we're looking to solve.
Enarx pronunciation guide (British English) {media}(https://github.com/enarx/enarx.github.io/blob/master/enarx.mp3)
The way you'd pronounce the letter "n", then "arks". En-arks. Enarx. Simple.
It's almost Latin for "in the citadel" or "within the stronghold". Nathaniel McCallum and Mike Bursell, who are ultimately to blame for the project, are both old/ancient language geeks, and wanted a cool name. We tried lots: some were rubbish, some were taken. We chose Enarx, which also (luckily) turned out not to be trademark-encumbered.
Absolutely. All of Enarx is, and always will be, open source. We use the Apache 2.0 license.
Everybody. No: really. Do you have some sensitive data or processes? Yes, you do. So you're a potential Enarx user.
(2019-06-27) Sadly not. We're working hard, and we'd love people to work with us. We hope to be adding more information very soon, to allow you to get started. If you want more, or something sooner, please feel free to add an Issue, and we'll see what we can do.
A TEE is Trusted Execution Environment. TEE technology is such a key part of the architecture of Enarx that is has its own page: TEEs (Trusted Execution Environments).
A Keep is the Enarx project's term for a TEE instance with all of the Enarx runtime and associated pieces inside it.
Would it be possible to implement containers within TEEs? That depends somewhat on the TEE implementation, but the answer is a "kind of yes". However, when you run containers on a host, the interactions that the container runtime has with the host leak all sorts of information that we really don't want to be making available to it. One of the design goals of Enarx is to reduce the number of layers that you need to trust, so this isn't a great fit. We know that containers are great, and one of the interesting sets of questions around Enarx revolves around exactly how you orchestrate Keeps, but whatever that looks like, we won't be doing something which meets the specification for containers, for the reasons outlined above.
No. Enarx uses attestation as part of its workflow, but it is not a host attestation project (like Keylime or ISECL). Host attestation projects tackle the issue of trust in the host in a different way to Enarx, by measuring the various layers of the stack - typically at boot-up - to check that they are as expected, and have not been substituted for untrusted pieces. Enarx aims to remove the need to trust these layers by taking them out of the stack. We expect both approaches to coexist, at least until TEEs are ubiquitous and people choose to execute all of their workloads in Enarx Keeps!
There are currently no plans for Enarx to support RT execution. The architecture of TEEs means that it would be difficult to make the sorts of guarantees about timely execution that RT applications require, and doing this on top of another operating system (Linux, the host) is not considered feasible at this time.
There's not much here yet, and we're working on that. You can find information on how to get started over at How to contribute.
No single company or organisation "owns" Enarx. It's open source software. Copyright on code is owned by whoever contributes it to the project. For more information, try this definition from Opensource.com or our license page (spoiler: it's Apache 2.0).
Well, Mike Bursell wrote quite a lot of this, which is why it's in pristine British English, with the exception of:
- any typos
- the few times that Nathaniel McCallum pressured him into writing something understandable by broader audiences
- (why can't we have Enarx' as the possessive for "Enarx"?)
- the word "LICENSE", which is an important part of the project, and has established meaning within the project hierarchy.