Agreed, this sounds like a good direction to go, and would also fill the role
of 'guest agents(VMware tools, etc) as this would handle the standard use cases.
+1
I hope more people get in on this discussion.
Sent from my iPhone
On Dec 15, 2012, at 12:55 PM, John Kinsella <j...@stratosec.co> wrote:
> Good point, there…maybe what we need here is to beef up the password server
> idea to provide a standardized conduit to get info down to a VM. Similar to
> EC2's user-data.
>
> Data I could see this framework providing:
> * System passwords
> * Additional IPs (so need to be able to return data sets, JSON-style maybe?)
> * Encryption keys
> * Metadata about the VM ("webserver," "database," "high-availability,"
> "master")
> * What else?
>
> One very important piece that's missing is a timeout - need to be able to
> have the object server provide the object(s) when a VM boots, but should be
> able to specify for some objects that after X seconds that data should be
> thrown away. Hugely important for encryption keys (I want to provide key to
> decryption system at boot, but don't want malicious user to be able to login
> a week later and easily get that key).
>
> So I'd suggest maybe have one spec to update/expand the password server to be
> an object server, and then Jayapal's multiple-IP spec would integrate with
> that.
>
> Super awesome bonus points: support for fetching/storing said objects in HSM.
> I've got one vendor in mind who has a sw solution we're looking at, but
> following a PKCS#11 format would probably be best.
>
> John
>
> On Dec 15, 2012, at 11:52 AM, "Kelceydamage@bbits" <kel...@bbits.ca>
> wrote:
>
>> This is a prime example where guest scripts make sense for automating the
>> interface alias creation. I still think I'm missing something however, does
>> this include a new fetch IP API?
>>
>> Also the 30 IP limit seems out of place, when I can go in right now and give
>> any guest VM 256+ interface aliases without restriction. The default
>> isolated network behind any VR is also a /24. Maybe adjust the limit to 256.
>> That way it's more of a logical boundary.
>>
>> Thanks
>>
>> Sent from my iPhone
>>
>> On Dec 15, 2012, at 8:38 AM, John Kinsella <j...@stratosec.co> wrote:
>>
>>> I'd remove the limitation of having 30 IPs per interface. Modern OSes can
>>> support way more.
>>>
>>> Why no support for basic networking? I can see a small hosting provider
>>> with a basic setup wanting to manage web servers...
>>>
>>> John
>>>
>>> On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi
>>> <jayapalreddy.ur...@citrix.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Current guest VM by default having one NIC and one IP address assigned.
>>>> If your wants extra IP for the guest VM, there no provision from the CS.
>>>>
>>>> Using multiple IP address per NIC feature CS can associate IP address for
>>>> the NIC, user can take that IP and assign it to the VM.
>>>>
>>>> Please find the FS for the more details.
>>>>
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address+per+NIC
>>>>
>>>> Please provide your comments on the FS.
>>>>
>>>>
>>>> Thanks,
>>>> jayapal
>>>
>>> Stratosec - Secure Infrastructure as a Service
>>> o: 415.315.9385
>>> @johnlkinsella
>>>
>>
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
