422 karma · joined October 16, 2013
We have plans but ultimately won't really know until we're in the thick of it.
Our plans though are to limit bandwidth and ban abusers. We'll work with Stripe's Radar platform to reduce the stolen credit card fraud.
Our cold-start times have a way to go, they're around 1 minute on the first invocation of some set of binaries and less than 20 seconds on subsequent invocations.
We've done a lot more work on optimizing the subsequent invocations time, including even running a forked version of docker (it reduces docker save time by 100x or more)
This is a primary scenario for us though and there's a lot of room for further optimization. We'll be posting figures and progress regularly post-launch.
EDIT:
I missed some of your questions, we need to upload your project's binaries only (not package manager binaries). So languages with larger binary sizes will have longer cold start times. Overall this comes down to the factoring of the project though.
We should be able to support Go since the binary is static linked, but it has less portability than other managed languages so we've targetted those first as lower hanging fruit.
In terms of DOS'ing our services, we limit disk space usage per job, and are working on bandwidth limitations (this is a weakness, but for now we'll just ban abusers and work with those with legit needs)
I'm moving over some of my own services to Coherence so it's very much intended to "run your whole business".
Deploying a modern infrastructure is complex and takes time to learn. The common denominator is that you usually just want to run code on those machines. Coherence makes that as simple as possible by integrating into the language itself.
This is just the base and there's much more to come!
A malicious user that manages to break out of the container environment will only have access to other instances of their own applications. Stronger security policies exist between users.
Coherence API is a twist on serverless that lets you deploy and run code the same way you call a local function. It integrates with the programming language so you can just pass a func and it's getting run. No need to change your workflow or toolset.
I'll be here to answer any questions.
"A capacity factor of 100 percent means the wind farm would be sending 30MW of power to the grid every minute of every day since it's been in operation."
The "sending" portion makes me interpret this in the sense of 30MW per minute.
One of those little inconsistencies that stood out to me...
Scratches head MW = 1000J / s
What happens when you send 30MW per minute..
30MW per minute = 1000J / s / m
Hmmm
The main benefit of dropshipping is usually that you don't manage any inventory, but prices and really anything but making the sale to the customer is out of your control. Serious problems can arise when your customer's expectations and your suppliers expectations (or failure to uphold thereof) are mismatched.
Serious problems like this can lead to account terminations on amazon or other platforms, forcing dropshippers without rock solid suppliers (and processes) onto custom websites, or non-mainstream platforms.
To be able to manage a decently large store well, expect to invest hundreds of hours in software and more in support. Just take it seriously with the long term outlook and you're much more likely to succeed.
I was inspired by sandstorm's supervisor.c++ while looking into container security which actually eventually led me to this issue.
> For example, Docker mounts /proc, albeit read-only;
I can't find too much information on this, does docker mount /proc from the host by default in each of the containers?
> In general, if you are going to run possibly-malicious code, the better way to reduce your risk is not to use a better sandbox, but to use multiple layered sandboxes. The effect is multiplicative: now the attacker must simultaneously obtain zero-days in both layers. For example, Google Chrome employs the V8 sandbox as well as a secondary container-based sandbox.
I think that sandboxing the language is pretty tough in the general case, since every language takes a lot of effort. In non-managed, compiled languages, it will be even tougher.
What is your opinion on tools like SELinux as a secondary layers?
I'm wondering if containers could abuse ARP to find the neighboring addresses.
This is just not true. Docker by default requires hardening, but container implementations are fairly secure. With Kernel/OS hardening they are quite secure.
Docker security by default is actually quite good outside of a few issues (like raw sockets), and as long as you don't mount '/' or something. Seccomp is enabled by default to mitigate attack surface on the kernel, SELinux can be enabled to further enforce access control.
Plenty of sandboxes are relying on containers now seemingly successfully. Sandstorm.io is a good example (and where I picked up a lot of tips for securing containers).
If you're convinced otherwise, feel free to share some research.
I'm afraid my initiation to ebtables (and iptables) was yesterday, so feedback such as this is highly appreciated. I will explore this and add a test to the repo.
> I guess it's not clear to me if the vulnerability/bug/whatever here is "two conspiring containers can establish a covert channel" or "a malicious container can send normal-looking traffic to a container, bypassing that container's firewall rules."
In the context of a sandbox, I purport the vulnerability is that a malicious container can bypass the firewall. The covert channel is largely inevitable because ultimately the containers can modulate cpu usage to communicate via cpu timing (I read this in a security paper somewhere, not sure how actual implementation works).
The impact of bypassing the firewall can be serious if the non-malicious container exposes any service without proper authentication (as is often done behind VPCs in the cloud).
Given that a high number of official containers contain known vulnerabilities (according to dockerhub). This is a potential issue for a large number of docker users.
> It does seem like the right answer is unique bridge networks per container.
My thinking is along the same lines, although I'm wondering if a container can communicate with the host if L2 packets may be able to traverse the network bridges. If anyone has input here, it'd be greatly appreciated.
Not familiar with freeBSD jails.
Relevant filed issue: https://github.com/moby/moby/issues/36355
There are three immediate workarounds.
1. Dropping `CAP_SYS_RAW` in docker run will prevent the raw socket from being opened (and is always a good idea).
2. Placing each container on it's own bridge network blocks this communication but requires you to manually specify the subnets of those networks to work around dockers default limit of 31 networks.
3. Create ebtables rules, to filter below the ip layer (layer 2) see the repo for an example.
Debugging code and reading others code are the two big ones to point out that are usually equally important to writing good code.
I have experienced that you can compare programmers in these tasks on a micro level and see drastic different results.
Top programmers tend to not only write code with good foundations, but also have an uncanny sense for the root of seemingly obscure issues, as well as the ability to understand other code almost on sight.
Try messing with the build of a React.js app, and I'll come see how you're doing next week.
Things should be getting easier, and the information overload less. For all scenarios, not just the easy ones. I think more advanced developer tools will be the main driver of this.
In my experience apologies are not making things better, but saying yeah that’s my fault and moving forward does.
What does this even mean..
> "That your post elicited outrage from a large body of people who study sociology, politics, and culture should provide you with some evidence that, perhaps, you are wrong."
Argumentum ad populum. Appeal to Authority. Slightly softballed with the perhaps, but it doesn't make it better.
If all we ever did was listen to the experts, the earth would be flat still.
> "So, maybe it’s a real problem when you share your thoughts on something you don’t understand."
Where's the line where you're "understanding" enough to talk about things?
I can't get through the fallacious logic enough to see the real argument here.
Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it).
Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that?
In the grand scope, is it really a bad thing?
We end up with X ways to solve problem Y and you never know X + 1 could have some advantages. Exploration should be encouraged IMO!