<div dir="ltr">The thing that screwed us up at Ames back in the day was deleting misplaced data ( should that happen ).  Swift was basically incapable of it at the time, cinder didn't even exist.  <div><br></div><div>Ultimately I ended up heading in the direction of spinning up separate cloud environments entirely for each cloud.  Mind you we were using modified bexar back then.</div><div><br></div><div>Last I saw you could do full zone isolation even network layer isolation ( with the right setup - greets to bigswitch ) and you were pretty okay then.</div><div><br></div><div>I see no reason why you con't stand up ITAR / non ITAR cloud components then just build a cleaning system that deprovisioned gear ... cleaned it and reprovisioned as needed to meet scaling needs ( albeit slowly ).</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 22, 2017 at 7:29 PM, Blair Bethwaite <span dir="ltr"><<a href="mailto:blair.bethwaite@gmail.com" target="_blank">blair.bethwaite@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.<br><div class="gmail_extra"><br><div class="gmail_quote">On 23 Mar. 2017 2:28 am, "Jonathan D. Proulx" <<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>> wrote:<br type="attribution"><blockquote class="m_-5130946061434652947quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 21, 2017 at 09:03:36PM -0400, Davanum Srinivas wrote:<br>
:Oops, Hit send before i finished<br>
<div class="m_-5130946061434652947quoted-text">:<br>
:<a href="https://info.massopencloud.org/wp-content/uploads/2016/03/Workshop-Resource-Federation-in-a-Multi-Landlord-Cloud.pdf" rel="noreferrer" target="_blank">https://info.massopencloud.or<wbr>g/wp-content/uploads/2016/03/<wbr>Workshop-Resource-Federation-<wbr>in-a-Multi-Landlord-Cloud.pdf</a><br>
:<a href="https://git.openstack.org/cgit/openstack/mixmatch" rel="noreferrer" target="_blank">https://git.openstack.org/cgi<wbr>t/openstack/mixmatch</a><br>
:<br>
:Essentially you can do a single cinder proxy that can work with<br>
:multiple cinder backends (one use case)<br>
<br>
</div>The mixmatch suff is interesting but it's designed ofr sharing rather<br>
than exclusion, is very young and adds complexity that's likely not<br>
wanted here. It is a good read though!<br>
<br>
For Block Storage you can have 'volume types' with different back ends and<br>
you can set quotas per project for each instance type.  I've used this<br>
to deprecate old storage by setting quota on 'old' type to zero.<br>
Presumably you you have an ITAR type that ITAR projects had quota on<br>
and a nonITAR type for other projects and never the twains should<br>
meet.<br>
<br>
For VMS I use host aggregates and instance metadata to seperate<br>
'special' hardware.  Again instance access can be per project so<br>
having ITAR and notITAR aggregates and matiching instance types with<br>
appopriate access lists can likely solve that.<br>
<br>
I've not tried to do anything similar with Image Storage, so  not sure<br>
if there's a way to restrict projects to specific glance stores.  IF<br>
all images were nonITAR and only provisioned with restricted<br>
info after launch *maybe* you could get away with that, though I<br>
suppose you'd need to disallow snapshots for ITAR projects<br>
at least...perhaps someone has a better answer here.<br>
<br>
-Jon<br>
<br>
:<br>
:Thanks,<br>
<div class="m_-5130946061434652947elided-text">:Dims<br>
:<br>
:On Tue, Mar 21, 2017 at 8:59 PM, Davanum Srinivas <<a href="mailto:davanum@gmail.com" target="_blank">davanum@gmail.com</a>> wrote:<br>
:> Jonathan,<br>
:><br>
:> The folks from Boston University have done some work around this idea:<br>
:><br>
:> <a href="https://github.com/openstack/mixmatch/blob/master/doc/source/architecture.rst" rel="noreferrer" target="_blank">https://github.com/openstack/m<wbr>ixmatch/blob/master/doc/source<wbr>/architecture.rst</a><br>
:><br>
:><br>
:> On Tue, Mar 21, 2017 at 7:33 PM, Jonathan Mills <<a href="mailto:jonmills@gmail.com" target="_blank">jonmills@gmail.com</a>> wrote:<br>
:>> Friends,<br>
:>><br>
:>> I’m reaching out for assistance from anyone who may have confronted the<br>
:>> issue of dealing with ITAR data in an OpenStack cloud being used in some<br>
:>> department of the Federal Gov.<br>
:>><br>
:>> ITAR (<a href="https://www.pmddtc.state.gov/regulations_laws/itar.html" rel="noreferrer" target="_blank">https://www.pmddtc.state.gov/<wbr>regulations_laws/itar.html</a>) is a less<br>
:>> restrictive level of security than classified data, but it has some thorny<br>
:>> aspects to it, particularly where media is concerned:<br>
:>><br>
:>> * you cannot co-mingle ITAR and non-ITAR data on the same physical hard<br>
:>> drives, and any drive, once it has been “tainted” with any ITAR data, is now<br>
:>> an ITAR drive<br>
:>><br>
:>> * when ITAR data is destroyed, a DBAN is insufficient — instead, you<br>
:>> physically shred the drive.  No need to elaborate on how destructive this<br>
:>> can get if you accidentally mingle ITAR with non-ITAR<br>
:>><br>
:>> Certainly the multi-tenant model of OpenStack holds great promise in Federal<br>
:>> agencies for supporting both ITAR and non-ITAR worlds, but great care must<br>
:>> be taken that *somehow* things like Glance and Cinder don’t get mixed up.<br>
:>> One must ensure that the ITAR tenants can only access Glance/Cinder in ways<br>
:>> such that their backend storage is physically separate from any non-ITAR<br>
:>> tenants.  Certainly I understand that Glance/Cinder can support multiple<br>
:>> storage backend types, such as File & Ceph, and maybe that is an avenue to<br>
:>> explore to achieving the physical separation.  But what if you want to have<br>
:>> multiple different File backends?<br>
:>><br>
:>> Do the ACLs exist to ensure that non-ITAR tenants can’t access ITAR<br>
:>> Glance/Cinder backends, and vice versa?<br>
:>><br>
:>> Or…is it simpler to just build two OpenStack clouds….?<br>
:>><br>
:>> Your thoughts will be most appreciated,<br>
:>><br>
:>><br>
:>> Jonathan Mills<br>
:>><br>
:>> NASA Goddard Space Flight Center<br>
:>><br>
:>><br>
:>> ______________________________<wbr>_________________<br>
:>> OpenStack-operators mailing list<br>
:>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
:>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
:>><br>
:><br>
:><br>
:><br>
:> --<br>
:> Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>
:<br>
:<br>
:<br>
:--<br>
:Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>
:<br>
:_____________________________<wbr>__________________<br>
:OpenStack-operators mailing list<br>
:<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.ope<wbr>nstack.org</a><br>
:<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-operators</a><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</div></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br></blockquote></div><br></div>