Could just avoid Glance snapshots and indeed Nova ephemeral storage altogether by exclusively booting from volume with your ITAR volume type or AZ. I don't know what other ITAR regulations there might be, but if it's just what JM mentioned earlier then doing so would let you have ITAR and non-ITAR VMs hosted on the same compute nodes as there would be no local HDD storage involved.
On 23 Mar. 2017 2:28 am, "Jonathan D. Proulx" <[email protected]> wrote: 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 <[email protected]> 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 <[email protected]> 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 :>> [email protected] :>> 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 :[email protected] :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
