Policy-based access control (PBAC)

Before delving into the Cedar policy model, it is important to understand PBAC, which is the broader concept that Verified Permissions leverages. PBAC is more dynamic than role-based access control (RBAC), allowing for real-time evaluation of contextual information. Unlike RBAC, which is rigid and role-centric, or attribute-based access control (ABAC), which is flexible but can become complex, PBAC offers a balanced approach. It allows you to manage permissions using high-level policies, making it particularly useful in microservices architectures where you need to manage a multitude of fine-grained permissions across various services.

PBAC provides enhanced flexibility and scalability in your authorization strategy. It allows you to define policies that can be globally applied across multiple services, thereby reducing complexity and administrative overhead.

Verified Permissions is a concrete implementation of PBAC that is designed to work seamlessly in AWS environments.

Cedar policy model

Cedar, is designed to separate business logic from application-level authorization logic. This separation is crucial for enhancing security and simplifying application development. When your microservices receive a request, it can be prefaced with a call to the Cedar authorization engine. This engine evaluates the request in real time, determining whether it should be allowed or denied based on your defined policies.

Before delving into the Cedar policy example, it is worth noting that Cedar’s syntax is designed for readability and expressiveness. Each policy statement consists of conditions (when) and permissions (permit or deny), making it intuitive to define complex authorization rules. For instance, let’s say you have a policy that allows only Cognito users with a custom attribute Department set to the value HR to delete a specific file. In Cedar, this could be represented as the following:

permit(
  principal,
  action == Action::”delete”,
  resource == File::”payroll.csv”
)
when {principal.custom.department == “HR”};

This policy can be evaluated in real time as requests come into your microservices, ensuring that only users with the HR department attribute are allowed to delete the specified file.

By isolating application-level authorization logic from the core business logic, Cedar allows developers to focus on building features and improving the user experience without compromising security.

In conclusion, the combination of IAM, Cognito, and Verified Permissions provides a robust framework for achieving fine-grained access control in a microservices architecture deployed on AWS.

Summary

In this comprehensive chapter, we delved into the world of microservices, starting with a critical evaluation of why they are increasingly becoming the architecture of choice. We contrasted the monolithic and microservices approaches, weighing their respective pros and cons, and provided use cases to help you make an informed decision. The chapter then transitioned into the complex landscape of security considerations unique to microservices. We discussed the paradigm shift in complexity and responsibilities, emphasizing the need for a new approach to access control and security measures. We also explored the zero trust principle and the importance of encryption, along with the types of communication—synchronous and asynchronous. AWS App Mesh and Amazon API Gateway were introduced as essential tools for managing and securing service-to-service communication. The latter part of the chapter focused on implementing fine-grained access control, highlighting the role of IAM and the utilization of Amazon Cognito for end-user authentication. We also discussed the need to decouple authorizations using AWS Verified Permissions.

As we transition to the next chapter, we will build on these foundational principles to focus on the unique security considerations of serverless deployments on AWS, which are commonly used to implement microservices architectures.