# 008 - Authorizer Dynamic RBAC Migration

By
Alexander Zabielski

Last Modified: August 12th, 2025

Title: Migration to a Dynamic RBAC Model with DynamoDB

Status: Implemented

# Context

Our current AWS authorizer uses a static, YAML-based approach to manage Role-Based Access Control (RBAC). In this model, permissions for each user role and corresponding API endpoints are defined within a YAML file that is part of the authorizer's codebase. This approach presents significant operational challenges:

  • Infrequent Updates: Any change to an endpoint's permission requirements, or the introduction of a new endpoint, necessitates a code update to the YAML file, a pull request, code review, and a full CI/CD pipeline deployment. This process is slow and creates unnecessary development overhead for what is essentially a data change.

  • Lack of Agility: The static nature of the configuration file limits our ability to respond quickly to new business requirements. It ties our authorization logic directly to our deployment cycle.

  • Poor Separation of Concerns: Authorization data is tightly coupled with the application code, which violates the principle of separation of concerns and makes the system less flexible and harder to maintain.

  • Manual Error Potential: Manual updates to the YAML file can lead to syntax errors, misconfigurations, or merge conflicts, introducing risk into the deployment process.

This decision is needed to decouple our authorization data from the authorizer's code, enabling a more flexible, scalable, and agile RBAC system that can be updated independently of application deployments.

# Decision

We will migrate from our static YAML-based RBAC system to a dynamic model. This will involve storing all role-based permissions and endpoint mappings in a dedicated DynamoDB table. The AWS Authorizer will be refactored to read this permission data at runtime from the DynamoDB table instead of a local YAML file.

# Rationale

This decision is driven by the need for a highly flexible and low-latency authorization system that can be managed dynamically.

  1. Factors that influenced the decision:

    • Dynamic Updates: Using DynamoDB allows us to update authorization policies by simply changing data in a table, without requiring a new code deployment. This dramatically speeds up the process of granting or revoking access to endpoints.

    • Scalability: DynamoDB is a highly scalable, fully managed NoSQL database that can handle the low-latency key-value lookups required by a busy authorizer without performance degradation.

    • Centralized Source of Truth: The DynamoDB table becomes the single source of truth for all authorization policies, ensuring consistency across all environments and reducing the risk of configuration drift.

    • Reduced Developer Overhead: Freeing developers from the need to manage authorization policies in code allows them to focus on core application logic.

  2. Evidence/Research: DynamoDB is a well-established and performant solution for key-value lookups, making it an ideal backend for a dynamic authorization service. Its low latency and ability to handle high throughput are critical for an authorizer, which runs on every API call. The amazon-dynamodb provider is a core part of the AWS ecosystem, which we already heavily utilize.

  3. Strengths of the chosen solution:

    • Agility: Authorization changes can be implemented in minutes rather than hours or days.

    • Decoupling: Decouples policy data from application code, improving maintainability and development workflow.

    • Centralized Management: Provides a single, easy-to-manage location for all RBAC policies.

    • Performance: DynamoDB's low-latency performance is a strong fit for a real-time authorizer.

# Implications

Migrating to a dynamic RBAC model will impact our processes and team responsibilities.

  1. People/Training:

    • The platform team will need to define a clear data structure for the DynamoDB table.

    • All developers will need to understand the new process for updating permissions via the DynamoDB table rather than the old YAML files.

    • We may need to create or update scripts/tools for managing the DynamoDB data to avoid manual console changes.

  2. Process Adjustments:

    • A new operational process will need to be established for making changes to the RBAC policies in the DynamoDB table, including potential for change tracking and approval.

    • The old YAML files will be deprecated and eventually removed from the codebase.

    • The CI/CD pipeline for the authorizer will be updated to add steps for managing the DynamoDB table, such as creating backups or validating schema changes.

  3. Tooling:

    • The AWS Authorizer function's code will be updated to include a DynamoDB client and logic to query the table.

    • This change can be implemented using Terraform to define and manage the DynamoDB table as an infrastructure resource.

  4. Risks:

    • Migration Complexity: The initial migration of all existing YAML policies to the new DynamoDB structure requires careful planning and execution to avoid any downtime or authorization errors.

    • Data Integrity: Without a proper management process, there is a risk of data corruption or unauthorized changes to the permissions table.

    • Performance Tuning: While DynamoDB is performant, improper configuration of read capacity or partition keys could lead to performance issues in a high-traffic environment.

    • Security: Securing the DynamoDB table itself, and the authorizer's access to it, is paramount.

# Trade-Offs

  • Benefits:

    • Highly Flexible: Can update authorization rules without redeploying code.

    • Reduced Operational Overhead: Streamlines the process for permission changes.

    • Improved Agility: Faster time-to-market for new features requiring authorization updates.

    • Centralized Policy Management: Single source of truth for all RBAC rules.

  • Drawbacks:

    • Initial Migration Effort: Requires a one-time effort to create the DynamoDB table and migrate existing policies.

    • New Data Store to Manage: Adds a new operational component (the DynamoDB table) to our infrastructure.

    • Security of the Data Store: Requires careful attention to the security of the DynamoDB table.

    • Potential for Misconfiguration: Data-level changes can be more subtle than code changes and may require a new process for validation.

# Key Evaluation Metrics

Define clear criteria to measure whether the decision solves the intended problems.

  • Time to Update Permissions: Measure the time taken to update permissions in the new system compared to the old YAML-based approach. Expect a significant reduction in time.

  • Authorizer Deployment Frequency: Track the number of authorizer code deployments, expecting a significant decrease as permission changes no longer require code releases.

  • Authorization-Related Incidents: Monitor the number of production incidents caused by incorrect permissions, aiming for a reduction as the centralized system matures.

  • Developer Feedback: Gather feedback from developers on the ease and speed of managing permissions with the new system.

  • Performance Metrics: Measure the latency of authorization checks in the authorizer, ensuring it remains within acceptable thresholds. This should be lower since we are using DynamoDB's low-latency capabilities and lambda memory caching.

# Conclusion

We strongly recommend moving forward with the migration to a dynamic RBAC model using DynamoDB. This change will drastically improve our team's agility, reduce operational overhead, and create a more scalable and maintainable authorization system. While the initial migration will require careful planning, the long-term benefits of decoupling authorization data from application code are substantial and will positively impact our entire development lifecycle.

The next steps include:

  1. Designing the DynamoDB table schema for RBAC policies.

  2. Developing a proof of concept to refactor the authorizer.

  3. Creating a plan for migrating existing policies into the new system.

  4. Defining the new process for managing permission updates.

# References

© Copyright 2026 - Ricoh USA - All rights reserved