[PetiteCloud] how much security?
Aryeh Friedman
aryeh.friedman at gmail.com
Thu Feb 13 15:04:03 PST 2014
Sounds like a variant of what we call "Cloud Tower" the idea is a single
integrated cloud on a single rack that depending on configuration might
have upto 10 to 20k instances on it (we are assuming most are not auto boot
and normally left off) the exact details are in a forth coming white paper
on the topic
On Thu, Feb 13, 2014 at 5:38 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:
> I was thinking a similar thing. There was a project I came across years
> ago and I can't seem to find it again, kicking myself that I didn't write
> it down.
>
> Basically it was setup as a nothing shared platform that could start with
> an AIO node and add additional nodes as the need arises. It wouldn't mirror
> data to all nodes but would make sure there was N redundant copies of all
> data in the event of a node failure and then restart that VM on a different
> node. It was also smart enough to load balance vm\nodes based on hardware
> capacity. It could also consolidate vm's onto less nodes when demand was
> low and power down the extra nodes, then restart them at a predefined time
> or as load increases.
>
> This way there is no need for large sans and nodes can be built with SSD's
> as they are dropping in price quickly now. I saw a 1TB Samsung 540MB/s read
> and 520MB/s write retailing between $600 and $700 Canadian. So building
> super fast clouds can be very easy for the end user. We just need flexible
> setup routines and lots of controls to prevent fubars and pebkacs.
>
> Michael Thoreson,
>
>
>
> On 13/02/2014 4:20 PM, Aryeh Friedman wrote:
>
>> User I can see and perhaps one small step of small departmental sized
>> units having "clouds with in clouds" but I do not see full fledged
>> "tenants" like RackSpace or large corporate divisions as being needed nor
>> desirable... the reason is once you get off the rack in a typical data
>> center you run into many situations far beyond your (or anyone's) control
>> or understanding for example why have vast disk arrays some where off in
>> the clouds when anything except HUGE DATA applications would need more then
>> what can be offered on rack if you make a single intergrated cloud on a
>> single rack
>>
>>
>> On Thu, Feb 13, 2014 at 4:59 PM, Michael Thoreson <m.thoreson at c4labs.ca<mailto:
>> m.thoreson at c4labs.ca>> wrote:
>>
>> Single admin will only work with hobbiest, extreme home users and
>> small firms. Big firms will want multiple admins for
>> accountability and central management of those admins be it
>> something in PC itself or an AD\LDAP setup.
>>
>> If you have even 2 admins using a single admin account, how do you
>> figure out who did what in the event an admin decided to be malicious.
>>
>> Michael Thoreson,
>>
>>
>> On 13/02/2014 3:43 PM, Aryeh Friedman wrote:
>>
>> These all seem like great plugins but I am a little hesitant
>> to bring such a large layer 1 service down in to the
>> foundation... better might be to offer an API for the layer 1
>> to control it... for DIY clouds the admin can pick whatever
>> they want but my personal recommendation would be if possible
>> a single admin and users use instances not PC it self
>>
>>
>> On Thu, Feb 13, 2014 at 4:35 PM, Michael Thoreson
>> <m.thoreson at c4labs.ca <mailto:m.thoreson at c4labs.ca>
>> <mailto:m.thoreson at c4labs.ca <mailto:m.thoreson at c4labs.ca>>>
>>
>> wrote:
>>
>> Password authentication would be sufficient in the early
>> stages
>> but perhaps there should be minimum length and complexity
>> requirements. Also make sure that whatever password
>> storage back
>> end used will store the passwords safely and effectively.
>> Adding
>> AD and LDAP support would be of big interest in companies. The
>> support can either be direct PC to AD\LDAP or perhaps PC could
>> have an option to use to already existing host users and
>> groups
>> which would include AD\LDAP users if the host is setup before
>> hand. This is of course won't work if the idea of PC is
>> going to
>> be including it's own OS, but I assume PC will just be
>> installed
>> on whatever host OS the admin chooses.
>>
>> Michael Thoreson,
>>
>>
>>
>> On 13/02/2014 11:39 AM, Aryeh Friedman wrote:
>>
>> If petitecloud's goal is only to control stuff at level 0
>> (even if in large clusters) then it is almost certain
>> the only
>> login would be from the admins and only then if
>> something went
>> wrong (we assume that layer 1 will be controlling us
>> via an
>> API) whould they login... given the above is just having a
>> single password good enough security (for now)... i..e no
>> users, tenants, etc.... the idea is we can skip right to
>> clustering then come back to security as we start to need
>> handle multiple users all with the same level of access.
>>
>> -- Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>>
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>>
>>
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net
>>
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>>
>>
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>>
>>
>> --
>> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>>
>>
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
>> petitecloud.nyclocal.net
>>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
> petitecloud.nyclocal.net
>
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140213/d639054d/attachment-0003.htm>
More information about the petitecloud-general
mailing list