Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't send correctly authorization request to Oslo policy

[ruan.he]

Hi Brian and Doug,
I've added this bug to the next Glance meeting agenda.
My college Thomas will assist the meeting. 
Thanks,
Ruan HE

-Original Message-
From: Brian Rosmaita [mailto:rosmaita.foss...@gmail.com] 
Sent: lundi 2 octobre 2017 13:18
To: Doug Hellmann
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't 
send correctly authorization request to Oslo policy

Thanks Doug.

Ruan, please put an item on the Glance meeting agenda.  The meeting is
14:00 UTC on Thursday [0].

thanks,
brian

[0] http://eavesdrop.openstack.org/#Glance_Team_Meeting

On Fri, Sep 29, 2017 at 11:49 AM, Doug Hellmann  wrote:
> The Glance team has weekly meetings just like the Oslo team. You’ll 
> find the details about the time and agenda on eavesdrop.openstack.org. 
> I think it would make sense to add an item to the agenda for their 
> next meeting to discuss this issue, and ask for someone to help guide 
> you in fixing it. If the Oslo team needs to get involved after there 
> is someone from Glance helping, then we can find the right person.
>
> Brian Rosmaita (rosmaita on IRC) is the Glance team PTL. I’ve copied 
> him on this email to make sure he notices this thread.
>
> Doug
>
> On Sep 29, 2017, at 11:24 AM, ruan...@orange.com wrote:
>
> Not yet, we are not familiar with the Glance team.
> Ruan
>
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: vendredi 29 septembre 2017 16:26
> To: openstack-dev
> Subject: Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance 
> doesn't send correctly authorization request to Oslo policy
>
> Excerpts from ruan.he's message of 2017-09-29 12:56:12 +:
>
> Hi folks,
> We are testing the http_check function in Oslo policy, and we figure 
> out a
> bug: https://bugs.launchpad.net/glance/+bug/1720354.
> We believe that this is due to the Glance part since it doesn't well 
> prepare the authorization request (body) to Oslo policy.
> Can we put this topic for the next Oslo meeting?
> Thanks,
> Ruan HE
>
>
> Do you have someone from the Glance team helping already?
>
> Doug
>
> __
>  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
>
> __
> ___
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>
> __
>  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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, 

Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't send correctly authorization request to Oslo policy

[ruan.he]

Not yet, we are not familiar with the Glance team.
Ruan

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: vendredi 29 septembre 2017 16:26
To: openstack-dev
Subject: Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't 
send correctly authorization request to Oslo policy

Excerpts from ruan.he's message of 2017-09-29 12:56:12 +:
> Hi folks,
> We are testing the http_check function in Oslo policy, and we figure out a 
> bug: https://bugs.launchpad.net/glance/+bug/1720354.
> We believe that this is due to the Glance part since it doesn't well prepare 
> the authorization request (body) to Oslo policy.
> Can we put this topic for the next Oslo meeting?
> Thanks,
> Ruan HE
> 

Do you have someone from the Glance team helping already?

Doug

__
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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] [Oslo][oslo.policy] Bug: Glance doesn't send correctly authorization request to Oslo policy

[ruan.he]

Hi folks,
We are testing the http_check function in Oslo policy, and we figure out a bug: 
https://bugs.launchpad.net/glance/+bug/1720354.
We believe that this is due to the Glance part since it doesn't well prepare 
the authorization request (body) to Oslo policy.
Can we put this topic for the next Oslo meeting?
Thanks,
Ruan HE



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[ruan.he]

Dims,
There is a similar prototype  https://review.openstack.org/#/c/237521/. 
Our idea is to provide a more generic one instead of Fortress. 
Ruan


-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: jeudi 10 août 2017 16:32
To: OpenStack Development Mailing List (not for usage questions)
Cc: DUVAL Thomas OBS/OAB
Subject: Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo hook 
for external PDP

Ruan,

Have you prototyped to see if you have all the information you need is 
available in the context (or can be gathered from Nova)?
( quickly check what the existing HttpCheck mechanism sends over the wire )

Thanks,
Dims

On Thu, Aug 10, 2017 at 10:17 AM,   wrote:
> Hello,
>
> We would like to have an external and centralized security policy 
> engine
> (PDP) that can pilot both OpenStack and SDN controllers. For this 
> reason, we have developed and upstreamed a hook for the new 
> OpenDaylight release Carbon 
> (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a 
> similar hook for the OpenStack/Oslo-policy.
>
>
>
> A blueprint was submitted to
> https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-polic
> y, and the spec is submitted to https://review.openstack.org/#/c/492543/.
>
> We hope that this topic can be discussed in the next oslo meeting.
>
> Thank you,
>
> Ruan HE
>
>
>
> __
> ___
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>
>
> __
>  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
>



--
Davanum Srinivas :: https://twitter.com/dims

__
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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[ruan.he]

Hello,
We would like to have an external and centralized security policy engine (PDP) 
that can pilot both OpenStack and SDN controllers. For this reason, we have 
developed and upstreamed a hook for the new OpenDaylight release Carbon 
(https://git.opendaylight.org/gerrit/#/c/46146/), and we'd like to develop a 
similar hook for the OpenStack/Oslo-policy.

A blueprint was submitted to 
https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-policy, and 
the spec is submitted to https://review.openstack.org/#/c/492543/.
We hope that this topic can be discussed in the next oslo meeting.
Thank you,
Ruan HE


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] 2017-1-11 policy meeting

[ruan.he]

Hi Lance,
Your option 3 is not clear for me.
You say that ‘The result would 0 policy files to maintain in tree and 
everything would be in code.’ Without this file, how can we define policies? 
Can user configure policies?
Ruan

From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: mercredi 18 janvier 2017 23:16
To: OpenStack Development Mailing List (not for usage questions); 
openstack-operat...@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] 2017-1-11 policy meeting

Looping this into the operator's list, too!

On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad 
> wrote:
Thanks to Morgan in today's policy meeting [0], we were able to shed some light 
on the reasons for keystone having two policy files. The main reason a second 
policy file was introduced was to recenter RBAC around concepts introduced in 
the V3 API. The problem was that the policy file that came later [1] wasn't a 
drop in replacement for the initial one because it required new roles in order 
to work properly. Switching to the newer policy file by default would break 
deployers who did nothing but implement the basic RBAC roles required by the 
initial version [2]. At the time there was no real way to "migrate" from one 
policy file to another, so two were maintained in tree.

Consolidating to a single file, or set of defaults, has benefits for 
maintainers and deployers, so we covered paths to accomplish that. We were able 
to come up with three paths forward.

  1.  Drop support for the original/initial policy file and only maintain 
policy.v3cloudsample.json
  2.  Leverage `keystone-manage bootstrap` to create the new roles required by 
policy.v3cloudsample.json
  3.  Codify the existing policy file using oslo.policy as a vehicle to 
introduce new defaults from policy.v3cloudsample.json
Everyone seemed to agree the 1st option was the most painful for everyone. 
Option 2 (and maybe 3) would more than likely require some sort of upgrade 
documentation that describes the process.

Without swaying anyone's opinion, I think I tend to lean towards option 3 
because it sounds similar to what nova has done, or is going to do. After 
talking to John Garbutt about some of their nova work, it sounded like one of 
their next steps was to re-evaluate all RBAC roles/rules now that they have 
them in code. If they come across an operation that would benefit from a 
different default value, they can use oslo.policy to deprecate or propose a new 
default (much like how we use oslo.config for changing or deprecating 
configuration values today). From a keystone perspective, this would 
effectively mean we would move what we have in policy.json into code, then do 
the same exercise with policy.v3cloudsample.json. The result would 0 policy 
files to maintain in tree and everything would be in code. From there - we can 
work with other projects to standardize on what various roles mean across 
OpenStack (hopefully following some sort of guide or document).

I'm excited to hear what others think of the current options, or if there is 
another path forward we missed.


[0] 
http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-18-16.00.log.html
[1] 
https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.v3cloudsample.json
[2] 
https://github.com/openstack/keystone/blob/7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.json

On Wed, Jan 11, 2017 at 11:28 AM, Lance Bragstad 
> wrote:
Hey folks,

In case you missed the policy meeting today, we had a good discussion [0] 
around incorporating keystone's policy into code using the Nova approach.

Keystone is in a little bit of a unique position since we maintain two 
different policy files [1] [2], and there were a lot of questions around why we 
have two. This same topic came up in a recent keystone meeting, and we wanted 
to loop Henry Nash into the conversation, since I believe he spearheaded a lot 
of the original policy.v3cloudsample work.

Let's see if we can air out some of that tribal knowledge and answer a couple 
questions.

What was the main initiative for introducing policy.v3cloudsample.json?

Is it possible to consolidate the two?


[0] 
http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-11-16.00.log.html
[1] 
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json
[2] https://github.com/openstack/keystone/blob/master/etc/policy.json



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles