OpenStack Summit Sydney Recap
Despite the 20+ hour commute for most attendees, Sydney was an amazing location. I personally have a better understanding of what native Australian OpenStack developers have to experience multiple times a year (sorry, Jamie). The venue itself was brand new, having officially opened shortly before the summit. It was also walking distance to a bunch of cool things, like the Sydney Opera House and the Royal Botanic Gardens. The conference center overlooked Darling Harbour, which was reminiscent of the conference location for the Vancouver summit.
In lieu of rambling about the venue and Sydney, which should be pulled into a separate blog post entirely, I'll get to my notes and scatter pictures of Australian cuisine along the way. Enjoy!
Operator & User Feedback
All of keystone's forum sessions were dedicated to gathering feedback. A few outcomes from the Queens PTG were quite complicated and span multiple release, making feedback that much more important. In general, I'd say we had substantial attendance in all sessions, which is encouraging.
Application Credentials Feedback
This was formally known as API keys and the direction was reworked during the Queens PTG. Instead of associating the application credentials to the project's life-cycle, it was decided to keep it at the user's life-cycle. This is a very good example of usability vs. security, and during the PTG we decided to err on the side of security. For more context on the exact details, check out Colleen's summary.
We started the session by recapping the problem and describing the new direction as a result of the PTG discussions. The operators and developers in the room agreed on the approach and that it is still needed. We summarized the advantages and gaps with the current proposal as a group:
- Associating policies (not roles) to an application credential will not be implemented in the MVP
- The life-cycle won't be tied to the project, it will be tied to the user that creates it (e.g. once the user is deleted, their application credentials will cease to work)
- Users won't have to expose their credentials to applications
- Users won't have to open internal tickets to create service accounts, especially in scenarios where OpenStack is backed with a corporate LDAP deployment managed by a separate department
There weren't any stop-ship issues raised in the feedback session, so you can expect application credential work to continue as planned.
RBAC & Policy Feedback
With RBAC discussions and resulting road-map taking up most of the PTG, this topic needed its own feedback session. We attempted to limit describing the road-map to leave time for operators to poke holes in the approach. The discussion actually generated a lot of questions about how things will work and what things should look like in the future. Questions didn't just come from operators, but other OpenStack developers. I found this refreshing because the dialog was proof that other people working within the OpenStack ecosystem were understanding it. Not just the approach, but how we were going to get there and the advantages of the work. Once we reached this point in the discussion, I chalked the session up to a success, but the discussion continued into three important sub-topics.
First, people started asking questions about breaking system-scope into hierarchies (e.g. I can give Jane the ability to administer the nova service in the us-east region). A set of examples that led to this is documented in a Trello card on the road-map. I think the visual representation of the end-state really helped here. Several operators in the room were excited about this possibility and that we're building the system to account for that in the future.
Second, there were several questions about API based policies that customers can control (think AWS IAM policies). A customer managing their OpenStack project can create a custom policy that they can assign to various members of their project. We talked about the existing oslo.policy work that will make this easier.
Lastly, we discussed usability. How does a user consuming these APIs know if they need a project-scoped token or a system-scoped token to do something? Walking around with two separate tokens and randomly trying both is not only inefficient but confusing. We started discussing the possibility of a per-service capabilities API. The general idea would be that a user could present their roles via a token to a service and ask, "What APIs can I use?" The service would run the roles through its policy enforcement engine to generate a list of policies they can execute. At this point, the service could return those policies to the user or continue to filter them based on the configuration of the deployment. For example, nova could remove the live migrate API from the list of capabilities if the configured virtualization driver doesn't support live migration.
Much like the application credential talk, the session was filled with productive questions. As I mentioned, I think the dialog served as proof that people were understanding the direction and long-term vision, and that felt like a big win.
Our general feedback session was focused on a specific federated case that's been discussed previously, twice actually. One proposal in Mitaka and the other to get general consensus to the backlog. It turns out we have users in Europe who are dealing with a couple requirements that didn't seem apparent in the original dialog:
- Authorization data must not come from the source of authentication (e.g. attributes from your SAML assertion or LDAP entity must not put you in specific OpenStack groups or give you OpenStack role assignments)
- Data replication at the database layer might not be possible due to data security issues between countries
If my memory serves me correctly, the keystone team shied away from this proposal because it felt like we were building data replication abilities into keystone's API. Instead, we wanted to improve keystone's performance so we didn't have to build contingencies into the API that we would have to support forever. I'm not sure we really understood the data restriction requirements at the time.
That said, an operator based in Europe was able to whiteboard things in a way that highlighted these requirements. The discussion took a different direction and resulted in action items. We're hoping to continue the discussion through the specifications process where we can document the outcomes in a way that relates to the new requirements.
Several members of the keystone team gave some great talks. I wanted to link a few of the recorded ones.
Demystifying Identity Federation
Colleen gave a great talk on debugging federated identity. Complete with a live demo.
Custom RBAC: Can I Do That?
We have a lot of operators that have to deal with customizing policy to fit real-world use cases. Matthew falls into one of those camps. Luckily, he spent some time sharing that knowledge in the Architecture & Operations track.
Slides are available on SlideShare.
Kristi and I gave the project update for keystone, recapping what we accomplished in Pike, what we're working on for Queens, and looking ahead to Rocky.
Slides are available on SlideShare.
JWT was mentioned during the project update, which led to some good hallway conversations, like using JWT to implement federation. This is something we will address in the future, but the immediate benefits lets OpenStack standardize on a format used in other parts of the industry.
With that, thanks for sticking through the summary and food pics! Feel free to reach out if you have any comments or concerns about the summary.
Photo Credit: A shot my wife and I took from the Royal Botanic Gardens overlooking the Sydney Opera House.