Open Stack

On Fri, Feb 21, 2014 at 06:37:27PM +0400, Stan Lagun wrote:
> Hi Everyone,
> 
> While looking through Heat templates generation code in Murano I've
> realized it has a major design flaw: there is no isolation between Heat
> resources generated by different apps.

Can you define the requirement for "isolation" in more detail?  Are you
referring simply to namespace isolation, or do you need auth level
isolation, e.g something enforced via keystone?

> Every app manifest can access and modify its environment stack in any way.
> For example it can delete instances and other resources belonging to other
> applications. This may be not so bad for Murano 0.4 but it becomes critical
> for AppCatalog (0.5) as there is no trust relations between applications
> and it may be unacceptable that untrusted application can gain complete
> write access over the whole stack.

All requests to Heat are scoped by tenant/project, so unless you enforce
resource-level access policy (which we sort-of started looking at with
OS::Heat::AccessPolicy), this is expected behavior.

> There is also a problem of name collisions - resources generated by
> different applications may have the same names. This is especially probable
> between resources generated by different instances of the same app. This
> also affects Parameters/Output of Heat templates as each application
> instance must generate unique names for them (and do not forget them later
> as they are needed to read output results).

A heirarchy of nested stacks, with each application defined as a separate
stack seems the obvious solution here.

> I think we need at least to know how we going to solve it before 0.5
> 
> Here is possible directions i can think of:
> 
> 1. Use nested Heat stacks. I'm not sure it solves naming collisions and
> that nested stacks can have their own Output

I think it does, and yes all stacks can have their own outputs, including
nested stacks.

Of particular interest to you may be the provider resource interface to
nested stacks, which will allow you to define (via a series of nested stack
templates) custom resource types defining each of your applications.

See this old blog post, which will give you the providers/environments 101,
and contains links to most of the related heat docs:

http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html

> 2. Control all stack template modifications and track which resource was
> created by which app. Give applications read-only access to resources they
> don't own

I think we need more info on the use-case here, but perhaps you can either
use the AccessPolicy resource, or we can work on defining an enhanced
version which meets your requirements.

> 3. Auto-generate resource names. Auto-add prefixes/suffixes to
> resource/output etc names indicating owning app instance ID and remove them
> upon read access from workflow so that generated names would be invisible
> to workflow. That would also mean all VMs  would have generated names

Heat already does this internally, we create unique names for all your
instances, unless you explicitly provide a name via the OS::Nova::Server
"name" property.

It might help if you could provide a really simplified example of the
problem you are facing, or links to the real templates which we could
review and make suggestions?

Steve