<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Bug/RFE is up!<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/neutron/+bug/1669630">https://bugs.launchpad.net/neutron/+bug/1669630</a><br>
<br>
Hopefully that sums of what I'm ideally after well enough, and is
useful to the greater community and project as a whole.<br>
<br>
Cheers,<br>
Adrian Turjak<br>
<br>
<div class="moz-cite-prefix">On 01/03/17 22:00, Adrian Turjak wrote:<br>
</div>
<blockquote
cite="mid:a415de7d-284b-435f-a38f-2cc6881c8661@email.android.com"
type="cite">
<div dir="auto">
<div>Hello Kevin,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks for the prompt response! This is
fantastic. I'll throw up a blueprint together tomorrow.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Backwards compatibility is the biggest issue, as
anyone currently using the feature and assuming no approval
step is going to be hit by it. The only sensible solution I
can see being easy to accomplish is to make the change as a
config setting that a deployer has to turn on. Then should
someone want the approval step, they can issue a deprecation
warning and eventually make the switch. Private clouds likely
wouldn't turn the acceptance workflow on but for public clouds
like us it would work. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Also for deployers yet to expose the feature,
they can make the change as they open the policy for the
service.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Trying to fit both versions (no acceptance,
required acceptance) together would be a mess. Best to just
offer the option as which is wanted to the deployer and avoid
the pain of trying to safely and securely do both when they
conflict.</div>
<div dir="auto"><br>
</div>
<div dir="auto">The ability to limit it to the same project tree
or a project you have roles in would be nice, but I fully
agree that trying to introduce a connection here to Keystone
could be a pain. If made as a another configuration option it
could work possibly. Neutron already has a keystone admin
user, and doing the required calls to keystone here wouldn't
be too hard. Checking for the same tree is an easy upwards
traversal, once root is reached, compare root for both
projects, sadly more than one API call, but not too bad. User
role checking is easy, and just a single call to the role
assignments API. As for rechecking, I wouldn't bother.
Projects can't be reparented, and while user roles can change
it is mostly safe to assume that this network sharing was safe
due to them having a role originally. No polling needed. My
idea here was to do the checks, and if neither was true, then
require acceptance.</div>
<div dir="auto"><br>
</div>
<div dir="auto">At any rate, even just an acceptance workflow
would solve my core problem, but I'll write up the proposal
for the full plan, and we can redesign from there!</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards,</div>
<div dir="auto">Adrian Turjak</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_extra" dir="auto"><br>
<div class="gmail_quote">On 1/03/2017 9:27 PM, Kevin Benton
<a class="moz-txt-link-rfc2396E" href="mailto:kevin@benton.pub"><kevin@benton.pub></a> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Adrian,
<div><br>
</div>
<div>Thanks for the write-up.</div>
<div><br>
</div>
<div>I think adding an approval workflow to Neutron is
a reasonable feature request. It probably wouldn't
be back-portable because it's going to require an
API change and a new column in the database for
approval state so you would have to patch it in
manually in your cloud (assuming you don't want to
wait for Pike).</div>
<div><br>
</div>
<div>The tricky part is going to be figuring out how
to handle API backward compatibility. Requiring an
extra step before a project is allowed to use a
network shared to it would break existing automation
that depends on the current workflow. </div>
<div><br>
</div>
<div><br>
</div>
<div>Please file an request for enhancement against
Neutron[1] and we can continue the discussion of how
to implement this on the bug report.</div>
<div><br>
</div>
<div><br>
</div>
<div>As for your option 2, the reason Neutron can't do
something like that automatically right now is due
to a lack of strong Keystone integration. Outside of
the middleware that authenticates requests, Neutron
doesn't even know keystone exists. We have no way to
prevent changes on the keystone side that would
violate the current RBAC policies (e.g. a user is
using a network that they wouldn't be able to use
after a keystone modification). We also have no
framework in place to even see keystone alterations
when they happen so it would require constant
background polling.</div>
<div><br>
</div>
<div><br>
</div>
<div>1. <a moz-do-not-send="true"
href="https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements">https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements</a></div>
<div><br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Kevin Benton</div>
</div>
<div><br>
<div class="elided-text">On Tue, Feb 28, 2017 at 7:43
PM, Adrian Turjak <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:adriant@catalyst.net.nz">adriant@catalyst.net.nz</a>></span>
wrote:<br>
<blockquote style="margin:0 0 0
0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
Openstack-Devs,<br>
<br>
I'm just trying to find out if there is any
proposed work to make the<br>
network RBAC a bit safer.<br>
<br>
For context, I'm part of a company running a
public cloud and we would<br>
like to expose Network RBAC to customers who have
multiple projects so<br>
that they can share networks between them. The
problem is that the<br>
network RBAC policy is too limited.<br>
<br>
If you know the project id, you can share a
network to that project id.<br>
This allows you to name a network 'public' or
'default' and share it to<br>
others in hopes of them connecting to it where you
then potentially<br>
compromise their instances. Effectively this
allows honey-pot networks.<br>
The only layer of safely you have is first needing
to gleam a project id<br>
before you can do this, effectively security
through obscurity, which is<br>
a terrible approach.<br>
<br>
Ideally network RBAC should work the same as image
sharing in Glance.<br>
You share a network, and the other project must
accept it before it<br>
becomes usable. This doesn't stop a too trusting
party from accepting an<br>
unsafe network, but it means they have some
warning before doing<br>
anything silly. Otherwise the onus is on them to
always be vigilant for<br>
shared networks that shouldn't be there, which is
not exactly something<br>
we want our customers to have to worry about.<br>
<br>
Are there plans to implement some sort of
acceptance process for network<br>
RBAC in Neutron, or a willingness to? Other
options are to only allow<br>
sharing to projects you have a role in, or
projects in same hierarchical<br>
'tree'. If I throw up a spec/blueprint for this is
there interest in<br>
following through with dev work, or would there be
support if I or other<br>
members of our company decide to help implement
such a change?<br>
<br>
If not, I've considered a few options I can do
around this, and I'd be<br>
curious on people's thoughts:<br>
1. Expose Network RBAC as is and setup automated
auditing to check for<br>
shared networks policies outside of their
hierarchical tree, or between<br>
projects that don't have shared users.<br>
2. Build into our workflow service a new plugin to
expose a neutron<br>
RBAC-like API which in the background uses the
Neutron API with an admin<br>
account on your behalf. This service would enforce
a level of custom<br>
policy that we'd want before allowing the creation
of a network RBAC<br>
policy. That way networks can only be shared
between projects in the<br>
same tree, or if the requesting user has roles in
both projects. If<br>
anyone attempts to share beyond that scope, we
will require an admin to<br>
approve the request before the network is shared,
or simply deny it.<br>
Think of this as a wrapper/proxy around Network
RBAC to allow<br>
stronger/flexible policy. In this scenario the
Neutron policy would<br>
limit RBAC to admin only.<br>
<br>
Option 1 is easy, but reactive, which in larger
deployments, or with<br>
larger customer bases isn't great since parsing
that much data as a<br>
human is hard, and writing the auditing to tell us
what is 'unsafe'<br>
correctly isn't easy. We may not always catch
things fast enough, or<br>
we'll catch too much and have to process it.<br>
Option 2 is a bit more work, and means clients
have to interact with a<br>
different API instead (which we'd document to our
customers and provide<br>
a horizon panel for it), but gives us as deployers
far more safety and<br>
security.<br>
<br>
So, what to do? Is it worth trying to make this
feature safer in<br>
Neutron? Will we get the support to make it
happen? Or should we just<br>
develop something around it so it works for us as
we need it to? It's a<br>
very useful feature, but as it stands it's too
unsafe to expose in a<br>
public cloud environment.<br>
<br>
Regards,<br>
Adrian Turjak<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">Hello Kevin,
Thanks for the prompt response! This is fantastic. I'll throw up a blueprint together tomorrow.
Backwards compatibility is the biggest issue, as anyone currently using the feature and assuming no approval step is going to be hit by it. The only sensible solution I can see being easy to accomplish is to make the change as a config setting that a deployer has to turn on. Then should someone want the approval step, they can issue a deprecation warning and eventually make the switch. Private clouds likely wouldn't turn the acceptance workflow on but for public clouds like us it would work.
Also for deployers yet to expose the feature, they can make the change as they open the policy for the service.
Trying to fit both versions (no acceptance, required acceptance) together would be a mess. Best to just offer the option as which is wanted to the deployer and avoid the pain of trying to safely and securely do both when they conflict.
The ability to limit it to the same project tree or a project you have roles in would be nice, but I fully agree that trying to introduce a connection here to Keystone could be a pain. If made as a another configuration option it could work possibly. Neutron already has a keystone admin user, and doing the required calls to keystone here wouldn't be too hard. Checking for the same tree is an easy upwards traversal, once root is reached, compare root for both projects, sadly more than one API call, but not too bad. User role checking is easy, and just a single call to the role assignments API. As for rechecking, I wouldn't bother. Projects can't be reparented, and while user roles can change it is mostly safe to assume that this network sharing was safe due to them having a role originally. No polling needed. My idea here was to do the checks, and if neither was true, then require acceptance.
At any rate, even just an acceptance workflow would solve my core problem, but I'll write up the proposal for the full plan, and we can redesign from there!
Regards,
Adrian Turjak
On 1/03/2017 9:27 PM, Kevin Benton <a class="moz-txt-link-rfc2396E" href="mailto:kevin@benton.pub"><kevin@benton.pub></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi Adrian,
Thanks for the write-up.
I think adding an approval workflow to Neutron is a reasonable feature request. It probably wouldn't be back-portable because it's going to require an API change and a new column in the database for approval state so you would have to patch it in manually in your cloud (assuming you don't want to wait for Pike).
The tricky part is going to be figuring out how to handle API backward compatibility. Requiring an extra step before a project is allowed to use a network shared to it would break existing automation that depends on the current workflow.
Please file an request for enhancement against Neutron[1] and we can continue the discussion of how to implement this on the bug report.
As for your option 2, the reason Neutron can't do something like that automatically right now is due to a lack of strong Keystone integration. Outside of the middleware that authenticates requests, Neutron doesn't even know keystone exists. We have no way to prevent changes on the keystone side that would violate the current RBAC policies (e.g. a user is using a network that they wouldn't be able to use after a keystone modification). We also have no framework in place to even see keystone alterations when they happen so it would require constant background polling.
1. <a class="moz-txt-link-freetext" href="https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements">https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements</a>
Cheers,
Kevin Benton
On Tue, Feb 28, 2017 at 7:43 PM, Adrian Turjak <a class="moz-txt-link-rfc2396E" href="mailto:adriant@catalyst.net.nz"><adriant@catalyst.net.nz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hello Openstack-Devs,
I'm just trying to find out if there is any proposed work to make the
network RBAC a bit safer.
For context, I'm part of a company running a public cloud and we would
like to expose Network RBAC to customers who have multiple projects so
that they can share networks between them. The problem is that the
network RBAC policy is too limited.
If you know the project id, you can share a network to that project id.
This allows you to name a network 'public' or 'default' and share it to
others in hopes of them connecting to it where you then potentially
compromise their instances. Effectively this allows honey-pot networks.
The only layer of safely you have is first needing to gleam a project id
before you can do this, effectively security through obscurity, which is
a terrible approach.
Ideally network RBAC should work the same as image sharing in Glance.
You share a network, and the other project must accept it before it
becomes usable. This doesn't stop a too trusting party from accepting an
unsafe network, but it means they have some warning before doing
anything silly. Otherwise the onus is on them to always be vigilant for
shared networks that shouldn't be there, which is not exactly something
we want our customers to have to worry about.
Are there plans to implement some sort of acceptance process for network
RBAC in Neutron, or a willingness to? Other options are to only allow
sharing to projects you have a role in, or projects in same hierarchical
'tree'. If I throw up a spec/blueprint for this is there interest in
following through with dev work, or would there be support if I or other
members of our company decide to help implement such a change?
If not, I've considered a few options I can do around this, and I'd be
curious on people's thoughts:
1. Expose Network RBAC as is and setup automated auditing to check for
shared networks policies outside of their hierarchical tree, or between
projects that don't have shared users.
2. Build into our workflow service a new plugin to expose a neutron
RBAC-like API which in the background uses the Neutron API with an admin
account on your behalf. This service would enforce a level of custom
policy that we'd want before allowing the creation of a network RBAC
policy. That way networks can only be shared between projects in the
same tree, or if the requesting user has roles in both projects. If
anyone attempts to share beyond that scope, we will require an admin to
approve the request before the network is shared, or simply deny it.
Think of this as a wrapper/proxy around Network RBAC to allow
stronger/flexible policy. In this scenario the Neutron policy would
limit RBAC to admin only.
Option 1 is easy, but reactive, which in larger deployments, or with
larger customer bases isn't great since parsing that much data as a
human is hard, and writing the auditing to tell us what is 'unsafe'
correctly isn't easy. We may not always catch things fast enough, or
we'll catch too much and have to process it.
Option 2 is a bit more work, and means clients have to interact with a
different API instead (which we'd document to our customers and provide
a horizon panel for it), but gives us as deployers far more safety and
security.
So, what to do? Is it worth trying to make this feature safer in
Neutron? Will we get the support to make it happen? Or should we just
develop something around it so it works for us as we need it to? It's a
very useful feature, but as it stands it's too unsafe to expose in a
public cloud environment.
Regards,
Adrian Turjak
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>