Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

2016-09-22 Thread Alexander Makarov 

Andrew,

the idea is to shift existing RBAC implementation:
currently policy is enforced in the service (Nova, for instance)
against the result of token validation, which is, in general, an access 
check;

I'm thinking about performing policy enforcement along with access check
in a single operation and only if necessary -
not every operation is protected and requires token validation,
though now keystone middleware validates a token on every request.

AFAIK Nova is using some custom logic to change local policies at run-time,
so I assume there may be a benefit in dynamic centralized storage 
managed via API,

so that Horizon can even provide a UI for that.

There are many questions in the matter, and my main is:
if we do RBAC in OpenStack the best way?


On 21.09.2016 20:16, Andrew Laski wrote:


On Wed, Sep 21, 2016, at 12:02 PM, Joshua Harlow wrote:

Andrew Laski wrote:

However, I have asked twice now on the review what the benefit of doing
this is and haven't received a response so I'll ask here. The proposal
would add additional latency to nearly every API operation in a service
and in return what do they get? Now that it's possible to register sane
policy defaults within a project most operators do not even need to
think about policy for projects that do that. And any policy changes
that are necessary are easily handled by a config management system.

I would expect to see a pretty significant benefit in exchange for
moving policy control out of Nova, and so far it's not clear to me what
that would be.

One way to do this is to setup something like etc.d or zookeeper and
have policy files be placed into certain 'keys' in there by keystone,
then consuming projects would 'watch' those keys for being changed (and
get notified when they are changed); the project would then reload its
policy when the other service (keystone) write a new key/policy.

https://coreos.com/etcd/docs/latest/api.html#waiting-for-a-change

or
https://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches

or (pretty sure consul has something similar),

This is pretty standard stuff folks :-/ and it's how afaik things like
https://github.com/skynetservices/skydns work (and more), and it would
avoid that 'additional latency' (unless the other service is adjusting
the policy key every millisecond, which seems sorta unreasonable).

Sure. Or have Keystone be a frontend for ansible/puppet/chef/ What's
not clear to me in any of this is what's the benefit to having Keystone
as a fronted to policy configuration/changes, or be involved in any real
way with authorization decisions? What issue is being solved by getting
Keystone involved?



-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][nova] Anyone interested in writing a policy generator sphinx extension?

2016-09-21 Thread Alexander Makarov 

What if policy will be manageable using RESTful API?
I'd like to validate the idea to handle policies in keystone or 
affiliated service: https://review.openstack.org/#/c/325326/


On 21.09.2016 17:49, Matt Riedemann wrote:
Nova has policy defaults in code now and we can generate the sample 
using oslopolicy-sample-generator but we'd like to get the default 
policy sample in the Nova developer documentation also, like we have 
for nova.conf.sample.


I see we use the sphinxconfiggen extension for building the 
nova.conf.sample in our docs, but I don't see anything like that for 
generating docs for a sample policy file.


Has anyone already started working on that, or is interested in 
working on that? I've never written a sphinx extension before but I'm 
guessing it could be borrowed a bit from how sphinxconfiggen was 
written in oslo.config.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Why not OAuth 2.0 provider?

2016-09-14 Thread Alexander Makarov 
Sorry - lost some links :)

Unified delegation spec:
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-delegation.html
About OAuth2:
https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/

On Wed, Sep 14, 2016 at 10:58 AM, Alexander Makarov <amaka...@mirantis.com>
wrote:

> Actually OAuth support is my next step in "unified delegations" effort
> [0], so it's a good time to think about what version of it should be
> supported.
>
> Along with that I have some concerns about OAuth v2, as IIRC authors
> themselves abandoned the spec. I'll check if something changed since that
> time.
>
> On 13.09.2016 00:43, Steve Martinelli wrote:
>
> 
>
>>
>> Would you please shed some light on how to configure Keystone for OAuth1?
>> Thank you very much.
>>
>
> There is some documentation in the API but nothing formally written out:
> http://developer.openstack.org/api-ref/identity/v3-ext/index.html
>
>
>>
>> I am trying to develop OAuth 2 client for Keystone. We will contribute
>> our OAuth 2 client source code to the community if we can use
>> Google/Facebook to log in to OpenStack through OAuth 2 client.
>>
>>
> Currently you can setup keystone to work with Google / Facebook and other
> social logins. If you've setup keystone to use Shibboleth (which you did, I
> snipped that part of the message), then you can set it up to use these
> social logins as well. See documentation here: http://docs.openstack.
> org/developer/keystone/federation/federated_identity.html#id4
>
>
>> Thanks.
>>
>> Best regards,
>>
>> Winston Hong
>> Ottawa, Ontario
>> Canada
>>
>>
>> Steve Martinelli  Jun 27, 2016, 10:57 PM
>>
>> > So, the os-oauth routes you mention in the documentation do not make
>> > keystone a proper oauth provider. We simply perform delegation (one
>> user
>> > handing some level of permission on a project to another entity) with
>> the
>> > standard flow established in the oauth1.0b specification.
>> >
>> > Historically we chose oauth1.0 because one of the implementers was very
>> > much against a flow based on oauth2.0 (though the names are similar,
>> these
>> > can be treated as two very different beasts, you can read about it here
>> > [1]). Even amongst popular service providers the choice is split down
>> the
>> > middle, some providing support for both [2]
>> >
>> > We haven't bothered to implement support for oauth2.0 since there has
>> been
>> > no feedback or desire from operators to do so. Mostly, we don't want
>> > yet-another-delegation mechanism in keystone, we have trusts and
>> oauth1.0;
>> > should an enticing use case arise to include another, then we can
>> revisit
>> > the discussion.
>> >
>> > [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
>> > [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Why not OAuth 2.0 provider?

2016-09-14 Thread Alexander Makarov 
Actually OAuth support is my next step in "unified delegations" effort 
[0], so it's a good time to think about what version of it should be 
supported.


Along with that I have some concerns about OAuth v2, as IIRC authors 
themselves abandoned the spec. I'll check if something changed since 
that time.



On 13.09.2016 00:43, Steve Martinelli wrote:




Would you please shed some light on how to configure Keystone for
OAuth1? Thank you very much.


There is some documentation in the API but nothing formally written 
out: http://developer.openstack.org/api-ref/identity/v3-ext/index.html



I am trying to develop OAuth 2 client for Keystone. We will
contribute our OAuth 2 client source code to the community if we
can use Google/Facebook to log in to OpenStack through OAuth 2 client.


Currently you can setup keystone to work with Google / Facebook and 
other social logins. If you've setup keystone to use Shibboleth (which 
you did, I snipped that part of the message), then you can set it up 
to use these social logins as well. See documentation here: 
http://docs.openstack.org/developer/keystone/federation/federated_identity.html#id4


Thanks.

Best regards,

Winston Hong
Ottawa, Ontario
Canada


Steve Martinelli  Jun 27, 2016, 10:57 PM

> So, the os-oauth routes you mention in the documentation do not
make
> keystone a proper oauth provider. We simply perform delegation
(one user
> handing some level of permission on a project to another entity)
with the
> standard flow established in the oauth1.0b specification.
>
> Historically we chose oauth1.0 because one of the implementers
was very
> much against a flow based on oauth2.0 (though the names are
similar, these
> can be treated as two very different beasts, you can read about
it here
> [1]). Even amongst popular service providers the choice is split
down the
> middle, some providing support for both [2]
>
> We haven't bothered to implement support for oauth2.0 since
there has been
> no feedback or desire from operators to do so. Mostly, we don't
want
> yet-another-delegation mechanism in keystone, we have trusts and
oauth1.0;
> should an enticing use case arise to include another, then we
can revisit
> the discussion.
>
> [1]
https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/

> [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] what permission is required to create a Keystone trust

2016-09-01 Thread Alexander Makarov 

Hi, Matt!

The issue is most probably in the absence of roles being trusted, which 
are required to create a trust.




On 01.09.2016 06:54, Matt Jia wrote:

Hi,

I am experimenting the Keystone Trusts feature with a script which 
creates a trust between two users.


import keystoneclient.v3 as keystoneclient
#import swiftclient.client as swiftclient


auth_url_v3 = 'http:/xxxt.com:5000/v3/ '


demo = keystoneclient.Client(auth_url=auth_url_v3,
 username='demo',
 password='openstack',
 project='demo')
import pdb; pdb.set_trace()
alt_demo = keystoneclient.Client(auth_url=auth_url_v3,
   username='alt_demo',
   password='openstack',
   project='alt_demo')

trust = demo.trusts.create(trustor_user=demo.user_id,
   trustee_user=alt_demo.user_id,
   project=demo.tenant_id)

When I run this script, I got this error:

Traceback (most recent call last):
  File "test_os_trust_1.py", line 20, in 
project=demo.tenant_id)
  File 
"/usr/lib/python2.7/site-packages/keystoneclient/v3/contrib/trusts.py", 
line 75, in create

**kwargs)
  File "/usr/lib/python2.7/site-packages/keystoneclient/base.py", line 
72, in func

return f(*args, **new_kwargs)
  File "/usr/lib/python2.7/site-packages/keystoneclient/base.py", line 
328, in create

self.key)
  File "/usr/lib/python2.7/site-packages/keystoneclient/base.py", line 
151, in _create

return self._post(url, body, response_key, return_raw, **kwargs)
  File "/usr/lib/python2.7/site-packages/keystoneclient/base.py", line 
165, in _post

resp, body = self.client.post(url, body=body, **kwargs)
  File 
"/usr/lib/python2.7/site-packages/keystoneclient/httpclient.py", line 
635, in post

return self._cs_request(url, 'POST', **kwargs)
  File 
"/usr/lib/python2.7/site-packages/keystoneclient/httpclient.py", line 
621, in _cs_request

return self.request(url, method, **kwargs)
  File 
"/usr/lib/python2.7/site-packages/keystoneclient/httpclient.py", line 
596, in request

resp = super(HTTPClient, self).request(url, method, **kwargs)
  File 
"/usr/lib/python2.7/site-packages/keystoneclient/baseclient.py", line 
21, in request

return self.session.request(url, method, **kwargs)
  File "/usr/lib/python2.7/site-packages/keystoneclient/utils.py", 
line 318, in inner

return func(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", 
line 354, in request

raise exceptions.from_response(resp, method, url)
keystoneclient.openstack.common.apiclient.exceptions.Forbidden: You 
are not authorized to perform the requested action. (HTTP 403) 
(Request-ID: req-6898b073-d467-4f2a-acc0-c4c0ca15970a)


Can anyone explain what sort of permission is required for the demo 
user to create a trust?


Cheers, Matt


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: keystone federation user story

2016-05-24 Thread Alexander Makarov 
Colleagues,

here is an actual use case for shadow users assignments, let's discuss
possible solutions: all suggestions are appreciated.

-- Forwarded message --
From: Andrey Grebennikov <agrebenni...@mirantis.com>
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov <amaka...@mirantis.com>


Main production usecase:
As a system administrator I need to create assignments for federated users
into the projects when the user has not authenticated for the first time.

Two different approaches.
1. A user has to be assigned directly into the project with the role Role1.
Since shadow users were implemented, Keystone database has the record of
the user when the federated user authenticates for the first time. When it
happens, the user gets unscoped token and Keystone registers the user in
the database with generated ID (the result of hashing the name and the
domain). At this point the user cannot get scoped token yet since the user
has not been assigned to any project.
Nonetheless there was a bug https://bugs.launchpad.net/keystone/+bug/1313956
which was abandoned, and the reporter says that currently it is possible to
assign role in the project to non-existing user (API only, no CLI). It
doesn't help much though since it is barely possible to predict the ID of
the user if it doesn't exist yet.

Potential solution - allow per-user project auto-creation. This will allow
the user to get scoped token with a pre-defined role (should be either
mentioned in config or in mapping) and execute operations right away.

Disadvantages: less control and order (will potentially end up with
infinite empty projects).
Benefits: user is authorized right away.

Another potential solution - clearly describe a possibility to assign
shadow user to a project (client should generate the ID correctly), even
though the user has not been authenticated for the first time yet.

Disadvantages: high risk of administrator's mistake when typing user's ID.
Benefits: user doesn't have to execute first dummy authentication in order
to be registered.

2. Operate with the groups. It means that the user is a member of the
remote group and we propose the groups to be assigned to the projects
instead of the users.
There is no concept of shadow groups yet, so it still has to be implemented.

Same problem - in order to be able to assign the group to the project
currently it has to exist in Keystone database.

It should be either allowed to pre-create the project for a group (based on
some specific flags in mappings), or it should be allowed to assign
non-existing groups into the projects.

I'd personally prefer to allow some special attribute to be specified in
either the config or mapping which will allow project auto-creation.
For example, user is added to the group "openstack" in the backend. In this
case this group is the part of SAML assertions (in case when SAML2 is used
as the protocol), and Keystone should recognize this group through the
mapping. When user makes login attempt, Keystone should pre-create the
project and assign pre-defined role in it. User gets access right away.


-- 
Andrey Grebennikov
Deployment Engineer
Mirantis Inc, Mountain View, CA



-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Does anybody need OAuth1 API in keystone?

2016-03-19 Thread Alexander Makarov 
Hi!

I'm working on unifying all the models that store actor access rights to
the resources [0],
and now I'm wondering if we can just drop current OAuth1 implementation [1].
It's definitely not perfect and require considerable effort to bring it in
good shape so the question is if the feature worth the attention?

​[0]​ https://blueprints.launchpad.net/keystone/+spec/unified-delegation
[1] https://github.com/openstack/keystone/tree/master/keystone/oauth1

-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-07 Thread Alexander Makarov 
 the events become so
> expensive? I can think of a few reasons:
>
> a) They are held every six months. I know of no other community or open
> source project that holds *conference-type* events every six months.
>
> b) They are held in extremely expensive hotels and conference centers
> because the number of attendees is so big.
>
> c) Because the conferences have become sales and marketing-focused events,
> companies shell out hundreds of thousands of dollars for schwag, for rented
> event people, for food and beverage sponsorships, for keynote slots, for
> lavish and often ridiculous parties, and more. This cost means less money
> to send engineers to the design summit to do actual work.
>
> I would love to see the OpenStack contributor community take back the
> design summit to its original format and purpose and decouple it from the
> OpenStack Summit's conference portion.
>
> I believe the design summits should be organized by the OpenStack
> contributor community, not the OpenStack Foundation and its marketing and
> event planning staff. This will allow lower-cost venues to be chosen that
> meet the needs only of the small group of active contributors, not of huge
> masses of conference attendees. This will allow contributor companies to
> send *more* engineers to *more* design summits, which is something that
> really needs to happen if we are to grow our active contributor pool.
>
>
>
> So this is more akin to the midcycles? I am in support of this as long as
> we have enough support from the Foundation (also for things such as visa
> letters, etc) to ensure we have large-enough-ish venues for the required
> cross-project working, if this supplanted the mid-cycles as well I could
> see it being a win. Reducing the travel for contributors to 1 or 2 venues
> [especially for those cross-project], would be fantastic.
>
>
>
> Once this decoupling occurs, I think that the OpenStack Summit should be
> renamed to the OpenStack Conference and Expo to better fit its purpose and
> focus. This Conference and Expo event really should be held once a year, in
> my opinion, and continue to be run by the OpenStack Foundation.
>
> I, for one, would welcome events that have no conference check-in area, no
> evening parties with 2000 people, no keynote and powerpoint-as-a-service
> sessions, and no getting pulled into sales meetings.
>
> OK, there, I said it.
>
> Thoughts? Criticism? Support? Suggestions welcome.
>
> -jay
>
>
>
> I, for one, am happy to see this discussion start on the ML.
>
> --Morgan
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Apache2 vs uWSGI vs ...

2015-09-18 Thread Alexander Makarov 
gt;> personally don't have any experience with it, but I seem to remember
>> hearing it has good eventlet support.
>>
>> // jim
>>
>> [0] https://uwsgi-docs.readthedocs.org/en/latest/
>> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html
>> [2] http://gunicorn.org/
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.

2015-07-27 Thread Alexander Makarov 
Actually Fernet token IS the best bet on stability and quality.

On Mon, Jul 27, 2015 at 3:23 PM, Sergii Golovatiuk sgolovat...@mirantis.com
 wrote:

 Guys, I object of merging Fernet tokens. I set -2 for any Fernet related
 activities. Firstly, there are some ongoing discussions how we should
 distribute, revoke, rotate SSL keys for Fernet. Secondly, there some
 discussion in community about potential security concerns where user may
 renew token instantly. Additionally, we've already introduced apache wsgi
 which may have own implication on keystone itself. It's a bit late for 7.0.
 Let's focus on stability and quality.



 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Mon, Jul 27, 2015 at 1:52 PM, Alexander Makarov amaka...@mirantis.com
 wrote:

 I've filed a ticket to test Fernet token on the scale lab:
 https://mirantis.jira.com/browse/MOSS-235

 If this feature is not granted FFE we still can configure it manually by
 changing keystone config.
 So I think internal how-to document backed-up with scale and bvt testing
 will allow our deployers to deliver Fernet to our customers.
 1 more thing: in the Community this feature is considered experimantal,
 so maybe setting it as a default is a bit premature?

 On Mon, Jul 27, 2015 at 2:34 PM, Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 Folks

 We saw several High issues with how keystone manages regular memcached
 tokens. I know, this is not the perfect time as you already decided to push
 it from 7.0, but I would reconsider declaring it as FFE as it affects HA
 and UX poorly. If we can enable tokens simply by altering configuration,
 let's do it. I see commit for this feature is pretty trivial.

 On Fri, Jul 24, 2015 at 9:27 AM, Mike Scherbakov 
 mscherba...@mirantis.com wrote:

 Fuel Library team, I expect your immediate reply here.

 I'd like upgrades team to take a look at this one, as well as at the
 one which moves Keystone under Apache, in order to check that there are no
 issues here.

 -1 from me for this time in the cycle. I'm concerned about:

1. I don't see any reference to blueprint or bug which explains
(with measurements) why we need this change in reference architecture, 
 and
what are the thoughts about it in puppet-openstack, and OpenStack 
 Keystone.
We need to get datapoints, and point to them. Just knowing that Keystone
team implemented support for it doesn't yet mean that we need to rush in
enabling this.
2. It is quite noticeable change, not a simple enhancement. I
reviewed the patch, there are questions raised.
3. It doesn't pass CI, and I don't have information on risks
associated, and additional effort required to get this done (how long 
 would
it take to get it done)
4. This feature increases complexity of reference architecture. Now
I'd like every complexity increase to be optional. I have feedback from 
 the
field, that our prescriptive architecture just doesn't fit users' needs,
and it is so painful to decouple then what is needed vs what is not. 
 Let's
start extending stuff with an easy switch, being propagated from Fuel
Settings. Is it possible to do? How complex would it be?

 If we get answers for all of this, and decide that we still want the
 feature, then it would be great to have it. I just don't feel that it's
 right timing anymore - we entered FF.

 Thanks,

 On Thu, Jul 23, 2015 at 11:53 AM Alexander Makarov 
 amaka...@mirantis.com wrote:

 Colleagues,

 I would like to request an exception from the Feature Freeze for
 Fernet tokens support added to the fuel-library in the following CR:
 https://review.openstack.org/#/c/201029/

 Keystone part of the feature is implemented in the upstream and the
 change impacts setup configuration only.

 Please, respond if you have any questions or concerns related to this
 request.

 Thanks in advance.

 --
 Kind Regards,
 Alexander Makarov,
 Senior Software Developer,

 Mirantis, Inc.
 35b/3, Vorontsovskaya St., 109147, Moscow, Russia

 Tel.: +7 (495) 640-49-04
 Tel.: +7 (926) 204-50-60

 Skype: MAKAPOB.AJIEKCAHDP

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Mike Scherbakov
 #mihgen


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com http://www.mirantis.ru/
 www.mirantis.ru
 vkuk...@mirantis.com

Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.

2015-07-27 Thread Alexander Makarov 
I've filed a ticket to test Fernet token on the scale lab:
https://mirantis.jira.com/browse/MOSS-235

If this feature is not granted FFE we still can configure it manually by
changing keystone config.
So I think internal how-to document backed-up with scale and bvt testing
will allow our deployers to deliver Fernet to our customers.
1 more thing: in the Community this feature is considered experimantal, so
maybe setting it as a default is a bit premature?

On Mon, Jul 27, 2015 at 2:34 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:

 Folks

 We saw several High issues with how keystone manages regular memcached
 tokens. I know, this is not the perfect time as you already decided to push
 it from 7.0, but I would reconsider declaring it as FFE as it affects HA
 and UX poorly. If we can enable tokens simply by altering configuration,
 let's do it. I see commit for this feature is pretty trivial.

 On Fri, Jul 24, 2015 at 9:27 AM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 Fuel Library team, I expect your immediate reply here.

 I'd like upgrades team to take a look at this one, as well as at the one
 which moves Keystone under Apache, in order to check that there are no
 issues here.

 -1 from me for this time in the cycle. I'm concerned about:

1. I don't see any reference to blueprint or bug which explains (with
measurements) why we need this change in reference architecture, and what
are the thoughts about it in puppet-openstack, and OpenStack Keystone. We
need to get datapoints, and point to them. Just knowing that Keystone team
implemented support for it doesn't yet mean that we need to rush in
enabling this.
2. It is quite noticeable change, not a simple enhancement. I
reviewed the patch, there are questions raised.
3. It doesn't pass CI, and I don't have information on risks
associated, and additional effort required to get this done (how long 
 would
it take to get it done)
4. This feature increases complexity of reference architecture. Now
I'd like every complexity increase to be optional. I have feedback from 
 the
field, that our prescriptive architecture just doesn't fit users' needs,
and it is so painful to decouple then what is needed vs what is not. Let's
start extending stuff with an easy switch, being propagated from Fuel
Settings. Is it possible to do? How complex would it be?

 If we get answers for all of this, and decide that we still want the
 feature, then it would be great to have it. I just don't feel that it's
 right timing anymore - we entered FF.

 Thanks,

 On Thu, Jul 23, 2015 at 11:53 AM Alexander Makarov amaka...@mirantis.com
 wrote:

 Colleagues,

 I would like to request an exception from the Feature Freeze for Fernet
 tokens support added to the fuel-library in the following CR:
 https://review.openstack.org/#/c/201029/

 Keystone part of the feature is implemented in the upstream and the
 change impacts setup configuration only.

 Please, respond if you have any questions or concerns related to this
 request.

 Thanks in advance.

 --
 Kind Regards,
 Alexander Makarov,
 Senior Software Developer,

 Mirantis, Inc.
 35b/3, Vorontsovskaya St., 109147, Moscow, Russia

 Tel.: +7 (495) 640-49-04
 Tel.: +7 (926) 204-50-60

 Skype: MAKAPOB.AJIEKCAHDP

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Mike Scherbakov
 #mihgen

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com http://www.mirantis.ru/
 www.mirantis.ru
 vkuk...@mirantis.com

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

2015-07-27 Thread Alexander Makarov 
Greetings!

I'd like to discuss pro's and contra's of having Fernet encryption keys
stored in a database backend.
The idea itself emerged during discussion about synchronizing rotated keys
in HA environment.
Now Fernet keys are stored in the filesystem that has some availability
issues in unstable cluster.
OTOH, making SQL highly available is considered easier than that for a
filesystem.

-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] FF Exception request for Fernet tokens support.

2015-07-23 Thread Alexander Makarov 
Colleagues,

I would like to request an exception from the Feature Freeze for Fernet
tokens support added to the fuel-library in the following CR:
https://review.openstack.org/#/c/201029/

Keystone part of the feature is implemented in the upstream and the change
impacts setup configuration only.

Please, respond if you have any questions or concerns related to this
request.

Thanks in advance.

-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.

2015-07-23 Thread Alexander Makarov 
-- Forwarded message --
From: Alexander Makarov amaka...@mirantis.com
Date: Thu, Jul 23, 2015 at 5:30 PM
Subject: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for
Fernet tokens support.
To: Vitaly Sedelnik vsedel...@mirantis.com, Eugene Bogdanov 
ebogda...@mirantis.com, Igor Marnat imar...@mirantis.com, Ilya Elterman 
ielter...@mirantis.com, Mike Scherbakov mscherba...@mirantis.com, Roman
Alekseenkov ralekseen...@mirantis.com


Colleagues,

I would like to request an exception from the Feature Freeze for Fernet
tokens support added to the fuel-library in the following CR:
https://review.openstack.org/#/c/201029/

Keystone part of the feature is implemented in the upstream and the change
impacts setup configuration only.

Please, respond if you have any questions or concerns related to this
request.

Thanks in advance.

-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP



-- 
Kind Regards,
Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

2015-02-19 Thread Alexander Makarov 
@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov rakhme...@mirantis.com
wrote:

 Hi,


  On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhot...@mirantis.com
 wrote:
 
  Nova client's CLI parameter 'bypass_url' helps me. The client's API also
 has 'management_url' attribute, if this one is specified - the client
 doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
 so client doesn't make extra call to keystone to retrieve new token and
 service_catalog.
 
  Thank you for clarification!


 I want to say an additional “thank you” from me for helping us solve this
 problem that’s been around for a while.

 And just a small conceptual question: in my understanding since trust
 chaining has already landed this kind of reauthentication doesn’t make a
 lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped
 tokens a regular tokens should be considered equal? Or we should still
 assume that trust scoped tokens are sort of limited? If yes then how
 exactly they must be understood?


 Thanks!

 Renat Akhmerov
 @ Mirantis Inc.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

2015-02-19 Thread Alexander Makarov 
@Renat, I like the idea. For now we have a spec:
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst
It's consiedered to be enough but as for me it lacks TL;DR section :)

On Thu, Feb 19, 2015 at 8:15 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:


 On 19 Feb 2015, at 18:32, Alexander Makarov amaka...@mirantis.com wrote:

 @Renat, They are conceptually different:
 - regular tokens are created for the owner of addressed resource
 - trust scoped tokens are for trustees and have some security restrictions.
 The case is about disallowing a trustee to aquire a regular token allowing
 him anything the trustor is allowed. It'd be an exploit.


 Alexander,

 Thanks for explanations. I kind of get the general idea, yes. What is best
 source where we could go and read in details about that? The only page I
 was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts but
 it would be nice if something more tutorial-like existed.

 Renat Akhmerov
 @ Mirantis Inc.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

2015-02-16 Thread Alexander Makarov 
We could soften this limitation a little by returning token client tries to
authenticate with.
I think we need to discuss it in community.

On Mon, Feb 16, 2015 at 6:47 PM, Steven Hardy sha...@redhat.com wrote:

 On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote:
 Yeah, clarification from keystone folks would be really helpful.
 If Nikolaya**s info is correct (I believe it is) then I actually
 dona**t
 understand why trusts are needed at all, they seem to be useless. My
 assumption is that they can be used only if we send requests directly
 to
 OpenStack services (w/o using clients) with trust scoped token
 included in
 headers, that might work although I didna**t checked that yet myself.
 So please help us understand which one of my following assumptions is
 correct?
  1. We dona**t understand what trusts are.
  2. We use them in a wrong way. (If yes, then whata**s the correct
 usage?)

 One or both of these seems likely, possibly combined with bugs in the
 clients where they try to get a new token instead of using the one you
 provide (this is a common pattern in the shell case, as the token is
 re-requested to get a service catalog).

 This provides some (heat specific) information which may help somewhat:


 http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html

  3. Trust mechanism itself is in development and cana**t be used at
 this
 point.

 IME trusts work fine, Heat has been using them since Havana with few
 problems.

  4. OpenStack clients need to be changed in some way to somehow bypass
 this keystone limitation?

 AFAICS it's not a keystone limitation, the behavior you're seeing is
 expected, and the 403 mentioned by Nikolay is just trusts working as
 designed.

 The key thing from a client perspective is:

 1. If you pass a trust-scoped token into the client, you must not request
 another token, normally this means you must provide an endpoint as you
 can't run the normal auth code which retrieves the service catalog.

 2. If you could pass a trust ID in, with a non-trust-scoped token, or
 username/password, the above limitation is removed, but AFAIK none of the
 CLI interfaces support a trust ID yet.

 3. If you're using a trust scoped token, you cannot create another trust
 (unless you've enabled chained delegation, which only landed recently in
 keystone).  This means, for example, that you can't create a heat stack
 with a trust scoped token (when heat is configured to use trusts), unless
 you use chained delegation, because we create a trust internally.

 When you understand these constraints, it's definitely possible to create a
 trust and use it for requests to other services, for example, here's how
 you could use a trust-scoped token to call heat:

 heat --os-auth-token trust-scoped-token --os-no-client-auth
 --heat-url http://192.168.0.4:8004/v1/project-id stack-list

 The pattern heat uses internally to work with trusts is:

 1. Use a trust_id and service user credentials to get a trust scoped token
 2. Pass the trust-scoped token into python clients for other projects,
 using the endpoint obtained during (1)

 This works fine, what you can't do is pass the trust scoped token in
 without explicitly defining the endpoint, because this triggers
 reauthentication, which as you've discovered, won't work.

 Hope that helps!

 Steve

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

2015-02-16 Thread Alexander Makarov 
https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication

On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov amaka...@mirantis.com
wrote:

 We could soften this limitation a little by returning token client tries
 to authenticate with.
 I think we need to discuss it in community.

 On Mon, Feb 16, 2015 at 6:47 PM, Steven Hardy sha...@redhat.com wrote:

 On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote:
 Yeah, clarification from keystone folks would be really helpful.
 If Nikolaya**s info is correct (I believe it is) then I actually
 dona**t
 understand why trusts are needed at all, they seem to be useless. My
 assumption is that they can be used only if we send requests
 directly to
 OpenStack services (w/o using clients) with trust scoped token
 included in
 headers, that might work although I didna**t checked that yet myself.
 So please help us understand which one of my following assumptions is
 correct?
  1. We dona**t understand what trusts are.
  2. We use them in a wrong way. (If yes, then whata**s the correct
 usage?)

 One or both of these seems likely, possibly combined with bugs in the
 clients where they try to get a new token instead of using the one you
 provide (this is a common pattern in the shell case, as the token is
 re-requested to get a service catalog).

 This provides some (heat specific) information which may help somewhat:


 http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html

  3. Trust mechanism itself is in development and cana**t be used at
 this
 point.

 IME trusts work fine, Heat has been using them since Havana with few
 problems.

  4. OpenStack clients need to be changed in some way to somehow
 bypass
 this keystone limitation?

 AFAICS it's not a keystone limitation, the behavior you're seeing is
 expected, and the 403 mentioned by Nikolay is just trusts working as
 designed.

 The key thing from a client perspective is:

 1. If you pass a trust-scoped token into the client, you must not request
 another token, normally this means you must provide an endpoint as you
 can't run the normal auth code which retrieves the service catalog.

 2. If you could pass a trust ID in, with a non-trust-scoped token, or
 username/password, the above limitation is removed, but AFAIK none of the
 CLI interfaces support a trust ID yet.

 3. If you're using a trust scoped token, you cannot create another trust
 (unless you've enabled chained delegation, which only landed recently in
 keystone).  This means, for example, that you can't create a heat stack
 with a trust scoped token (when heat is configured to use trusts), unless
 you use chained delegation, because we create a trust internally.

 When you understand these constraints, it's definitely possible to create
 a
 trust and use it for requests to other services, for example, here's how
 you could use a trust-scoped token to call heat:

 heat --os-auth-token trust-scoped-token --os-no-client-auth
 --heat-url http://192.168.0.4:8004/v1/project-id stack-list

 The pattern heat uses internally to work with trusts is:

 1. Use a trust_id and service user credentials to get a trust scoped token
 2. Pass the trust-scoped token into python clients for other projects,
 using the endpoint obtained during (1)

 This works fine, what you can't do is pass the trust scoped token in
 without explicitly defining the endpoint, because this triggers
 reauthentication, which as you've discovered, won't work.

 Hope that helps!

 Steve

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kind Regards,
 Alexander Makarov,
 Senoir Software Developer,

 Mirantis, Inc.
 35b/3, Vorontsovskaya St., 109147, Moscow, Russia

 Tel.: +7 (495) 640-49-04
 Tel.: +7 (926) 204-50-60

 Skype: MAKAPOB.AJIEKCAHDP




-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova]

2015-02-13 Thread Alexander Makarov 
Adam, Nova client does it for some reason during a call to
nova.servers.list()


On Thu, Feb 12, 2015 at 10:03 PM, Adam Young ayo...@redhat.com wrote:

  On 02/12/2015 10:40 AM, Alexander Makarov wrote:

 A trust token cannot be used to get another token:

 https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
 You have to make your Nova client use the very same trust scoped token
 obtained from authentication using trust without trying to authenticate
 with it one more time.



 Actually, there have been some recent changes to allow re-delegation of
 Trusts, but for older deployments, you are correct.  I hadn't seen anywhere
 here that he was trying to use a trust token to get another token, though.



 On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayo...@redhat.com wrote:

  On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote:

 No, I just checked it. Nova receives trust token and raise this error.

  In my script, I see:

  http://paste.openstack.org/show/171452/

  And as you can see, token from trust differs from direct user's token.


  The original user needs to have the appropriate role to perform the
 operation on the specified project.  I see the admin role is created on the
 trust. If the trustor did not have that role, the trustee would not be able
 to exececute the trust and get a token.  It looks like you were able to
 execute the trust and get a token,  but I would like you to confirm that,
 and not just trust the keystone client:  either put debug statements in
 Keystone or call the POST to tokens from curl with the appropriate options
 to get a trust token.  In short, make sure you have not fooled yourself.
 You can also look in the token table inside Keystone to see the data for
 the trust token, or validate the token  via curl to see the data in it.  In
 all cases, there should be an OS-TRUST stanza in the token data.


 If it is still failing, there might be some issue on the Policy side.  I
 have been assuming that you are running with the default policy for Nova.

 http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

 I'm not sure which rule matches for list servers (Nova developer input
 would be appreciated)  but I'm guessing it is executing the rule

 admin_or_owner: is_admin:True or project_id:%(project_id)s,

 Since that is the default. I am guessing that the project_id in question
 comes from the token here, as that seems to be common, but if not, it might
 be that the two values are mismatched. Perhaps there Proejct ID value from
 the client env var is sent, and matches what the trustor normally works as,
 not the project in question.  If these two values don't match, then, yes,
 the rule would fail.




 On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayo...@redhat.com wrote:

   On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote:

 Hi !

  I investigated trust's use cases and encountered the problem: When I
 use auth_token obtained from keystoneclient using trust, I get *403*
 Forbidden error:  *You are not authorized to perform the requested
 action.*

  Steps to reproduce:

  - Import v3 keystoneclient (used keystone and keystoneclient from
 master, tried also to use stable/icehouse)
 - Import v3 novaclient
 - initialize the keystoneclient:
   keystone = keystoneclient.Client(username=username,
 password=password, tenant_name=tenant_name, auth_url=auth_url)

  - create a trust:
   trust = keystone.trusts.create(
 keystone.user_id,
 keystone.user_id,
 impersonation=True,
 role_names=['admin'],
 project=keystone.project_id
   )

  - initialize new keystoneclient:
client_from_trust = keystoneclient.Client(
 username=username, password=password,
 trust_id=trust.id, auth_url=auth_url,
   )

  - create nova client using new token from new client:
nova = novaclient.Client(
 auth_token=client_from_trust.auth_token,
 auth_url=auth_url_v2,
 project_id=from_trust.project_id,
 service_type='compute',
 username=None,
 api_key=None
   )

  - do simple request to nova:
   nova.servers.list()

  - get the error described above.


 Maybe I misunderstood something but what is wrong? I supposed I just can
 work with nova like it was initialized using direct token.


  From what you wrote here it should work, but since Heat has been doing
 stuff like this for a while, I'm pretty sure it is your setup and not a
 fundamental problem.

 I'd take a look at what is going back and forth on the wire and make
 sure the right token is being sent to Nova.  If it is the original users
 token and not the trust token, then you would see that error.


  --
  Best Regards,
 Nikolay


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova]

2015-02-12 Thread Alexander Makarov 
-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev