3 ms·

After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [secu

After working on a microservices framework I've opinions about frameworks but one thing that caught my attention is the shifting of outbound network calls [security responsibility] from firewalls to the [application] runtime.......driven by a config file. It'd be interesting to hear from some security engineers here -- there will likely have to be some tooling written for them, etc., but this is one of the more interesting things about spin/WASM. I wonder how this will scale to large apps -- assumning thats one of the goals...if the target is just some kinda serverless cruft then maaaybe that can work, but I can already foresee a small config template hell unravelling in front of my eyes. I might be missing something fundamental here, so take what I said with a pinch of salt.

matei_radu 5y ago
(one of the Spin authors here.) This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. We have not explored exactly how large scale apps will look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience. That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!
- gyre007 5y ago
  > This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.
  - pmontra 5y ago
    Web apps always had a chance to decide who to talk to. This is trivial when they are clients of some other APIs, so about server side choices: - domains, if reverse proxies / firewalls give them the IP of the client - routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes) - users, with many different authentication systems - data, with validations. The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.

matei_radu 5y ago

(one of the Spin authors here.) This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. We have not explored exactly how large scale apps will look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience. That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!

gyre007 5y ago
> This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox. Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.
- pmontra 5y ago
  Web apps always had a chance to decide who to talk to. This is trivial when they are clients of some other APIs, so about server side choices: - domains, if reverse proxies / firewalls give them the IP of the client - routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes) - users, with many different authentication systems - data, with validations. The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.