Jump to: navigation, search

Difference between revisions of "Meetings/KeystoneMeeting"

(Regular attendees)
(Agenda for next meeting)
Line 14: Line 14:
 
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).
 
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).
  
<b>2016-02-02</b>
+
<b>2016-02-09</b>
* DocImpact <code>stevemar</code>
+
* Trust workflow <code>jorge_munoz</code>
** using DocImpact will now create a bug against the keystone project
+
** Are redelegation and impersonation multually exclusive? IMO, it should.
* ISO27001 Compliance <code>ayoung</code>
+
*** Should it be allowed to create trust with both redelegation and impersonation set to true?
**  Is SQL Backend compliance a requirement?
+
*** Does it make sense to add a new attribute called 'allow_impersonation' to determine if a trust with redelegation is allow to create a trust with impersonation.
* Policy and RBAC <code>ayoung</code>
+
** Can a trust be created with an impersonated token?
** Now that we have is_admin_project how do we deploy without breaking existing policy
+
*** If so, how would the request look?
** Can we do the equivalent of deprecations for the current policy.json file
+
** Can a trust be created with impersonation set to true from a trusted token that only allows redelegation (allow_redelegation=True, Impersonation=False)?
** Should existing policy files be limited to role checks <code>samueldmq</code>
+
** Do need new attribute 'allow_impersonation'?
** Can we layer new RBAC policy on top of existing policy without breaking?
+
** Does the redelegated_trust_id attribute need to be promoted from extras to its own column? (Adding to schema)
** please approve Implied Roles.  Any more nits should be filed as bugs. https://review.openstack.org/#/c/242614/
 
*** Expanding rules in the token can be disabled
 
*** Do we want to autogenerate a policy.json fragment?
 
*** Inference rules still required to break a large role down to smaller for least privilege.
 
* Devstack, identity v3, and breaking the world <code>stevemar</code>
 
** we broke things, details are here: https://etherpad.openstack.org/p/v3-only-devstack
 
** mailing list: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085497.html
 
  
 
==== Review of Keystone Blueprints for No-Spec Requires Status ====
 
==== Review of Keystone Blueprints for No-Spec Requires Status ====
 
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).
 
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).
 
* [https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller Return request Id to caller] <code>bknudson</code>
 
  
 
==== Keystone Weekly Bug Reports ====
 
==== Keystone Weekly Bug Reports ====

Revision as of 21:34, 4 February 2016

Weekly Keystone team meeting

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on IRC in #openstack-meeting, on Tuesdays at 18:00 UTC. Please feel free to add items to the agenda below with your name and we'll cover them.

Regular attendees

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz, jorge_munoz

Agenda for next meeting

Main Agenda

Please add agenda items to the bottom of this section's list (be sure to include your irc_handle!).

2016-02-09

  • Trust workflow jorge_munoz
    • Are redelegation and impersonation multually exclusive? IMO, it should.
      • Should it be allowed to create trust with both redelegation and impersonation set to true?
      • Does it make sense to add a new attribute called 'allow_impersonation' to determine if a trust with redelegation is allow to create a trust with impersonation.
    • Can a trust be created with an impersonated token?
      • If so, how would the request look?
    • Can a trust be created with impersonation set to true from a trusted token that only allows redelegation (allow_redelegation=True, Impersonation=False)?
    • Do need new attribute 'allow_impersonation'?
    • Does the redelegated_trust_id attribute need to be promoted from extras to its own column? (Adding to schema)

Review of Keystone Blueprints for No-Spec Requires Status

Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your irc_handle!).

Keystone Weekly Bug Reports

Bugs for the various Keystone repositories are collects and published to the following links. (lbragstad)

Previous meetings

Logs and meeting summaries of previous meetings are located here.