Open Stack

On Tue, Mar 21, 2017 at 09:03:36PM -0400, Davanum Srinivas wrote:
:Oops, Hit send before i finished
:
:https://info.massopencloud.org/wp-content/uploads/2016/03/Workshop-Resource-Federation-in-a-Multi-Landlord-Cloud.pdf
:https://git.openstack.org/cgit/openstack/mixmatch
:
:Essentially you can do a single cinder proxy that can work with
:multiple cinder backends (one use case)

The mixmatch suff is interesting but it's designed ofr sharing rather
than exclusion, is very young and adds complexity that's likely not
wanted here. It is a good read though!

For Block Storage you can have 'volume types' with different back ends and
you can set quotas per project for each instance type.  I've used this
to deprecate old storage by setting quota on 'old' type to zero.
Presumably you you have an ITAR type that ITAR projects had quota on
and a nonITAR type for other projects and never the twains should
meet.

For VMS I use host aggregates and instance metadata to seperate
'special' hardware.  Again instance access can be per project so
having ITAR and notITAR aggregates and matiching instance types with
appopriate access lists can likely solve that.

I've not tried to do anything similar with Image Storage, so  not sure
if there's a way to restrict projects to specific glance stores.  IF
all images were nonITAR and only provisioned with restricted
info after launch *maybe* you could get away with that, though I
suppose you'd need to disallow snapshots for ITAR projects
at least...perhaps someone has a better answer here.

-Jon

:
:Thanks,
:Dims
:
:On Tue, Mar 21, 2017 at 8:59 PM, Davanum Srinivas <davanum at gmail.com> wrote:
:> Jonathan,
:>
:> The folks from Boston University have done some work around this idea:
:>
:> https://github.com/openstack/mixmatch/blob/master/doc/source/architecture.rst
:>
:>
:> On Tue, Mar 21, 2017 at 7:33 PM, Jonathan Mills <jonmills at gmail.com> wrote:
:>> Friends,
:>>
:>> I’m reaching out for assistance from anyone who may have confronted the
:>> issue of dealing with ITAR data in an OpenStack cloud being used in some
:>> department of the Federal Gov.
:>>
:>> ITAR (https://www.pmddtc.state.gov/regulations_laws/itar.html) is a less
:>> restrictive level of security than classified data, but it has some thorny
:>> aspects to it, particularly where media is concerned:
:>>
:>> * you cannot co-mingle ITAR and non-ITAR data on the same physical hard
:>> drives, and any drive, once it has been “tainted” with any ITAR data, is now
:>> an ITAR drive
:>>
:>> * when ITAR data is destroyed, a DBAN is insufficient — instead, you
:>> physically shred the drive.  No need to elaborate on how destructive this
:>> can get if you accidentally mingle ITAR with non-ITAR
:>>
:>> Certainly the multi-tenant model of OpenStack holds great promise in Federal
:>> agencies for supporting both ITAR and non-ITAR worlds, but great care must
:>> be taken that *somehow* things like Glance and Cinder don’t get mixed up.
:>> One must ensure that the ITAR tenants can only access Glance/Cinder in ways
:>> such that their backend storage is physically separate from any non-ITAR
:>> tenants.  Certainly I understand that Glance/Cinder can support multiple
:>> storage backend types, such as File & Ceph, and maybe that is an avenue to
:>> explore to achieving the physical separation.  But what if you want to have
:>> multiple different File backends?
:>>
:>> Do the ACLs exist to ensure that non-ITAR tenants can’t access ITAR
:>> Glance/Cinder backends, and vice versa?
:>>
:>> Or…is it simpler to just build two OpenStack clouds….?
:>>
:>> Your thoughts will be most appreciated,
:>>
:>>
:>> Jonathan Mills
:>>
:>> NASA Goddard Space Flight Center
:>>
:>>
:>> _______________________________________________
:>> OpenStack-operators mailing list
:>> OpenStack-operators at lists.openstack.org
:>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
:>>
:>
:>
:>
:> --
:> Davanum Srinivas :: https://twitter.com/dims
:
:
:
:-- 
:Davanum Srinivas :: https://twitter.com/dims
:
:_______________________________________________
:OpenStack-operators mailing list
:OpenStack-operators at lists.openstack.org
:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators