Businessman hand holding cloud computing online connecting to big data analytics. Block chain network technology and intelligence data storage develop smart decision in global business solution.
Cloud-native/microservices-based products are complex, as is building access control and management rights for these products. And every pull request only makes things worse. Most developers end up building authorization or access controls for their product multiple times, forcing them to refactor for each new customer, product, or security requirement.
To make people's lives and work easier, it's important to understand the unique challenges of building cloud native permissions, as well as five best practices for building cloud native permissions that can save developers a lot of trouble.
The application and access permissions have changed
In the past, developers have used a single framework with authorization or access control, such as Django or Spring, to build authorization, but these are no longer applicable when creating cloud-native applications.
There are several reasons for this:
First, the applications themselves are no longer monolithic -- they are microservice-based and are becoming highly fragmented. This is also worth noting when developers need to consolidate devices or instances that are deployed on the edge and typically also require access control.
Second, cloud-native applications often need to integrate third-party services (such as billing, authentication, databases, analytics, and so on) and be able to control access to them in addition to the microservices of the developer's own application.
Third, more dynamic and distributed applications need to use a bunch of different authorization models (such as RBAC, ReBAC, ABAC) based on multiple data sources and increasingly complex rules. Finally, security, privacy and compliance requirements are also on the rise (in the face of increasingly sophisticated cyber threats) and becoming very complex. Developers find themselves managing not only who should have access to the data, but also how it is propagated across different services.
The reality of authorization
All of these new requirements require a different way of thinking about licensing:
Empowerment is no longer an afterthought; it must be planned in advance.
Empowerment is an ongoing effort, not a one-time issue. It has to evolve along with the product.
Authorization is key to the customer experience because it affects how users connect and invite others to use the product. If the experience is bad, they won't like it.
Authorize connections to a larger identity and access management space.
Five best practices for building cloud native permissions
To handle all of these changes, there are some best practices that can help developers build cloud-native permissions and have time to actually develop functionality rather than being overwhelmed with processing permissions.
Decouple policy and code
One of the most important practices for building cloud-native permissions is decoupling policy and code. Mixing authorization layer code with the application code itself can be problematic. More importantly, it makes it difficult to upgrade, add functionality, and monitor code as a whole when copying code between different microservices. Each change requires refactoring a lot of code that only diverges further from each other as these microservices grow.
This can be avoided by (ideally) decoupling the policy from the code by creating a separate authorization microservice that other services will use to meet their authorization needs. For example, open policy management or open source policy/permission engines such as Spice DB allow developers to manage authorization in a separate service.
Event driven
Developers want the applications they are building to be dynamic. Applications typically include functions such as user invitations, role assignments, or using third-party data sources -- all of which should be managed in real time. Without this ability, the ability to make authorization decisions is significantly reduced.
This requires developers to design the authorization layer as event-driven. They wanted to create a reality where every time an event occurred that affected authorization, it was immediately passed through the system to ensure that the authorization layer knew about it and kept in sync with the application and any associated third-party data services.
In an ideal world, in order to achieve this, the developer will authorization data from the application data (because not all the data associated with the application and authorization, and vice versa), to create a lean model in the authorized layer, and then through real-time events make it keep pace with applications and other sources.
For example, open policy Management is an open source project that can make open policy management event driven. This enables developers to respond to policy and data changes, push real-time updates to their agents, and bring open policies to the speed required by real-time applications.
Background integration of stakeholders
The authorization layer is part of the product itself, and in a product-centric enterprise, there are various stakeholders who need to be able to connect to the access control experience. Along with developers, these include DevOps, product managers, security, compliance, sales, marketing, and so on. When you build the authorization layer, you want to provide control and interfaces to these different stakeholders through the back end systems. This requires consideration of the needs of different stakeholders from the access control interface to the product from the outset. It should please everyone.
Customer interface
In a similar way to thinking about stakeholder requirements, developers also need to think about end users/customers. Authorization is not only about managing the product, but also about the end user of the product. For example, if users need access to their own audit logs (as almost every B2B application user does), they should be able to easily see what is being done in the product. Recognizing this requirement ahead of time requires building an authorization layer that locks down different interfaces that meet the end user's needs.
GitOps
A separate microservice was created to manage permissions and provide updates to it in an event-driven manner. How do you now manage these changes, application versions, apply checks and balances, and ensure that the code and data for microservices meet the requirements and requirements? The answer is GitOps.
Using GitOps lets developers create a pull request for each release change. Then, as developers update the product and its access control capabilities, they can use the new code to drive submissions, pass the necessary tests and checks, and apply it to the authorization layer.
The future of cloud native permissions
As complexity increases and customer and security requirements continue to emerge, it is critical to build access control for products in a way that is ready for the future and does not require extensive refactoring or rewriting. Create a separate microservice for authorization, design it to be event-driven, provide control and interface to a variety of stakeholders and customers, and use GitOps to enable developers to create as future-oriented a product as possible, and prevent them from having to rebuild the authorization layer multiple times, regardless of the requirements.
No comments