Improving Auditing in Keystone

Improving Auditing in Keystone

Keystone has supported entity notifications since Havana. The original implementation scoped the notification payload to the entity type and its unique ID. The original idea was that the application consuming the notification would know what type of resource changed and could then ask Keystone for more information using the ID. For example, an application could listen for notifications specific to users and ask for more information with the ID in the payload. This flow works when the resource is created or updated, but it breaks when resources are deleted because Keystone doesn’t support soft deletions. This was noted in a recent bug opened against Keystone. So, how do we improve the auditability of Keystone given the original notification pattern?

Discussing this in the hallway track at the Newton summit, it seems we can move forward with one of three options. First, we can improve the notification framework to include more information so that querying Keystone isn’t necessary. Second, database triggers could be used to dump all Keystone entities into a separate database. This is technically available today since it is all database work. The consuming application would then query the other database for information about what Keystone sent in the notification, regardless of the entity being deleted. Third, we could introduce soft deletes and expand APIs in Keystone that return deleted references.

Expanding Notification Payloads

The advantages of this approach is that we already have a notification framework that allows us to send payloads. The disadvantage is that we are now in charge of all the things that people care about in those payloads. Some deployer might want to have usernames in the notification, some might want a different attribute. It is easy to see how this can turn into a slippery slope of just shoving attributes into the payload. What if one deployer wants an attribute that another can’t expose? This means that notification payloads are going to be custom for each entity in Keystone.

Database Triggers

This option raises the bar for operational consumption of notifications. Keystone will supply a notification when things change, but in order to get information about the resource there has to be some additional DBA type work done to query against. One advantage of this approach is that it pairs the database operations with the application consuming the notifications. The result is that the database triggers/operations can be tailored to the application that has to query the database. For example, if the consuming application only cares about users it doesn’t make sense to set up triggers for role assignments.

Soft Deletes

This seems to be the heavy-handed approach. This would require changing all of Keystone’s backends to honor a soft delete, as well modify the API to return soft deleted entities. But, Keystone would also be the source of truth for the consuming application.

I’m hoping to discuss this a bit more with various operators and developers here at the summit and write a follow-up post.

 

Photo Credit: Nick Youngson 

Why you should contribute to open-source in college

Why you should contribute to open-source in college

OpenStack Keystone Mitaka Summit Summary

OpenStack Keystone Mitaka Summit Summary