In order to facilitate routing of notifications and approvals I built a minimal directory service that provides both contacts and permissions abstractions allowing it to sit in the middle of multiple services as glue. Directory service is a thin overlay of AWS Lambda and API Gateway managing data in DynamoDB. It’s designed to be both simple, flexible and accessible via standard API calls. The main point of interaction is intended to be the API, however there is also a user interface designed for humans to manage the data. It’s designed to be conceptually similar to tags, allowing for arbitrary one to many or many to many relationships.
Access to the API is restricted via two API keys, a public key which allows GET requests and an admin key which allows POST and DELETE requests. The frontend uses google for authentication but also requires you to be a full or group admin in the directory service itself.
Groups (or User Groups) are just collections of people. You can either assign a user to an existing group by selecting the group from the dropdown, or you can create a new group by entering a unique name into the Group Name field. You can also add contact information for a new group directly from this screen.
While contact entries can be arbitrary, the intent currently is to use them to tie together users or groups to notification methods.
Permissions are tied to groups and query-able by a service and an action. The keyword “all” is special and will match on any query; think of it as a wildcard query. Permissions also have a special field service_action which is a composite key used with the DELETE and GET methods to ensure you’re interacting with the correct thing.
- Service Admins - allowed to do all the things
- Group admins - allowed to manage members of any groups they’re members of
If you’re a global admin, you will have access to the admin management interface giving you the ability to add new global and group admins.
Here's how you might use the directory service to provide contact information and permissions inside a slack based approval pipeline.
- An AWS Code Pipeline with an approval step executes
- An event is triggered in Event Bridge, which is detected by the Notifier Lambda
- The Notifier Lambda reads the routing tag from the pipeline and queries the directory service for the group and contact information of the approvers
- The Notifier Lambda sends a message to the group’s slack contact requesting approval
- Someone selects Yes or No on the dialog box
- The Approval Lambda verifies if the responder is a member of a group that has appropriate permissions to respond to the request
- If they don’t, a message is sent back to the responder telling them they don’t have permissions
- If they do, the Approval Lambda sends the Approval/Rejection to the Code Pipeline API and notifies the responder that the request was completed