4 ms·

To clarify, you need a Google account for providing service to the network, but it's not required for starting instances. Instance starts also support dynamic

To clarify, you need a Google account for providing service to the network, but it's not required for starting instances. Instance starts also support dynamic callbacks, so you can bounce the start off StackMonkey to another instance that provides credentials and provisioning info. There's a security brief at the bottom of the readme: https://github.com/StackMonkey/utter-va#security https://github.com/StackMonkey/utter-va#security. The pool is intended to function as an aggregation point for the instances. There should not be a way for a bad actor to use the pool to affect appliances or compromise instances. And the code is Open Source under the MIT license, as all infrastructure code should be. If you find an issue, please open a ticket: https://github.com/StackMonkey/utter-pool/issues https://github.com/StackMonkey/utter-pool/issues

mintplant 12y ago
> There should not be a way for a bad actor to use the pool to affect appliances or compromise instances. How do you accomplish this?
- kordless 12y ago
  Appliances create addresses and map them to instance templates. Appliances send those mappings to the pool where they are placed in an NDB database used for searching. Users can search or have prior knowledge of an address to get instance addresses. Appliances listen to the blockchain for payments sent to the address and make instance starts based on those payments. Before an instance is started, the pool may send data to the appliance to effect provisioning tasks. Alternately, a callback URL can be returned, which is then used to 'bounce' the provisioning request to a third party site. Note the pool never sends a start request directly to an appliance. Instances 'time out' when they run out of time, but that could also be done using another payment to another address. Provisioning requests are probably the weakest link currently, but we have plans for dealing with that shortly.

mintplant 12y ago

> There should not be a way for a bad actor to use the pool to affect appliances or compromise instances. How do you accomplish this?

kordless 12y ago
Appliances create addresses and map them to instance templates. Appliances send those mappings to the pool where they are placed in an NDB database used for searching. Users can search or have prior knowledge of an address to get instance addresses. Appliances listen to the blockchain for payments sent to the address and make instance starts based on those payments. Before an instance is started, the pool may send data to the appliance to effect provisioning tasks. Alternately, a callback URL can be returned, which is then used to 'bounce' the provisioning request to a third party site. Note the pool never sends a start request directly to an appliance. Instances 'time out' when they run out of time, but that could also be done using another payment to another address. Provisioning requests are probably the weakest link currently, but we have plans for dealing with that shortly.