Mapping Business Requirements to Authorization Policy for Aviation | Cerbos
Mapping business requirements to authorization policy for aviation
Introduction
What unites an aircraft, AI-driven systems, pilots, and millions of passengers?
They all operate within one of the most regulated and complex ecosystems in the world, the aviation sector. In this environment, every action taken must be explicitly allowed by policy, carefully controlled, and fully audited for reporting. Behind the scenes, authorization systems are quietly at work enforcing these rules, keeping aviation safe, compliant, and moving.
An unauthorized software upgrade or data entry has the potential to delay flights and impact thousands of lives. It can mean a family member missing a much awaited wedding, a father missing his son's in-person graduation ceremony, or a daughter losing the chance to say a final goodbye at her mother's funeral. All of these are one-time life events, that can hardly be reorganized.
These examples showcase just how critical proper authorization is. So, what are the common authorization challenges facing the aviation industry?
- Role explosion. Traditional aviation companies have existed for a while, and there is a real possibility of roles being mismanaged over time, or simply getting bloated due to changing aviation business needs. Mapping roles accurately to functions and what needs to be done is really complex, and often falls short in accounting for contextual changes.
- Sensitive data. Flight reservations can sometimes include highly sensitive passenger information. A passenger with wheelchair assistance requested would often have accompanying medical details. Access to this type of information may require explicit passenger consent or additional approvals to ensure it is handled appropriately and with care.
- Maintenance mistakes. Maintenance errors can have a direct impact on flight schedules and the profitability of the company. Often incorrect authorizations, such as ordering wrong quantities or unsuitable part types for maintenance, can delay repairs and stall aircraft at the hangar longer than planned.
- Audit. Aviation is one of the most highly regulated industries in the world, and airlines are consistently required to maintain detailed audit trails of all activities by all personnel.
Together, these challenges highlight a common theme along the way. The authorization decisions in aviation are not simple and depend on who is acting, what they are trying to do, and the context in which the action occurs. If we hard-code these rules into applications or manage them in isolated systems, the management of policies becomes really challenging and difficult to manage over time.
Enter the centralized authorization system, Cerbos. Systems like Cerbos are key in keeping the systems controlled, compliant, and working the way people have come to expect from aviation systems.
RBAC and ABAC
Before we begin, let's get this sorted. How do we decide between RBAC (role-based access control), ABAC (attribute-based access control) for defining authorization policies?
The answer lies in the context of the systems and organizational processes you are working with. Consider the following:
- Are the roles such as pilots, flight ops, etc., well defined, well assigned, and accurately map to responsibilities?
- Are there contextual elements at play when deciding ALLOW or DENY, like changing weather patterns that impact flight scheduling?
- Do access decisions need to account for resource attributes like the sensitivity of data? For example, accessing a flight reservation containing passenger medical information may require additional approvals or passenger consents.
There is no doubt that access decisions in modern times are highly reliant on contextual parameters, especially in aviation. If that's the case, we lean towards ABAC. But if we have a role-based system that is well-maintained and accurately reflects access decisions in the organization, then we lean towards RBAC. In reality, however, the answer lies somewhere in the middle. Using a hybrid approach gets the best of both worlds. For more help in deciding, please check out the RBAC vs ABAC discussion blog.
Discovery
We begin the journey with the discovery phase. Imagine a fictitious airline company named Santas Airlines, implementing the Cerbos authorization system across their aviation systems, covering flight schedules, ticketing, logistics, maintenance, and personnel records.
Architecture
We analyse all the systems where the authorization system would integrate, and identify what would be the best deployment model to be adopted. Cerbos Policy Decision Point supports the following:
- A service model involves a centralized Cerbos PDP cluster that application instances call for access decisions, acting as a single point for policy management.
- A sidecar model deploys the PDP alongside each application instance, enabling low-latency decisions.
- In Kubernetes or node-based environments, a DaemonSet model can be used, running a PDP on every node to combine local decision-making with efficient resource usage.
Policy model
During discovery sessions, we interview heads of departments, review organizational charts, study processes, and flight schedules to answer the following questions:
- Who are the system users from each department that interact with aviation systems, such as admin staff, pilots, and maintenance personnel?
- What actions do each of those users take? And what are their associated workflows?
- What are the resources or digital entries targeted by these actions?
At the end of this exercise, we identify the foundational building blocks of an access policy. The following illustration shows sample principals, actions, and resources that may be identified during discovery.
Principals
- Pilot - Responsible for flying the aircraft and ensuring passenger and crew safety during flights.
- Maintenance Personnel - Handles inspections, repairs, and upkeep to keep aircraft in safe working condition.
- Flight Ops Manager - Oversees flight scheduling, crew assignments, and overall operational efficiency.
- Admin Staff - Supports day-to-day operations with documentation, coordination, and office management tasks.
- Maintenance AI agent - An AI agent workload identity that reviews maintenance data of aircraft and predicts parts requirement for the future and orders them from a supplier.
Actions
- view
- edit
- export
- modify
- refund
- update
- view:approve
- order:create
- order:approve
Resources
- Flight Schedules - Detailed plans that outline when and where each flight will operate.
- Flight Tickets - Passenger-issued documents that confirm booking and allow boarding.
- Logistics - The coordination of supplies, equipment, and ground operations needed to keep flights running smoothly.
- Maintenance Logs - Records of inspections, repairs, and technical work done on aircraft.
- Personnel Records - Files containing employment details, qualifications, and history of airline staff.
- MCP Parts Order - MCP Server that hosts the /createOrder API to order aircraft maintenance parts from the supplier.
Policy Matrix
After analysis and discussions, we have decided that we would use a hybrid approach of using RBAC and ABAC for managing authorizations at Santas Airlines. Here's the authorization policy matrix:
RBAC – Personnel Records
| Resource | Action | Pilot | Maint. Personnel | Maint. AI Agent | Flight Ops Manager | Admin Staff |
|---|---|---|---|---|---|---|
| Personnel Records | view | ✓ | ✓ | |||
| Personnel Records | update | ✓ (if in office) |
ABAC – Operational Systems
| Resource | Action | Pilot | Maint. Personnel | Maint. AI Agent | Flight Ops Manager | Admin Staff |
|---|---|---|---|---|---|---|
| Flight Schedules | view | if assign | ✓ | if resource is allowed for auditing | ||
| Flight Schedules | edit | if during planning hours | ||||
| Flight Tickets | view | if assign | ✓ | if during business hours | ||
| Flight Tickets | modify | if departure time > 24 hrs | if during business hours and ticket is confirmed | |||
| Logistics | view | if assign | if type is "flight plan" | ✓ | if depart. matched | |
| Maintenance Logs | view | if assign | if assigned | ✓ |
Build
Cerbos policies are written in YAML, and the policies are declarative in nature, which makes it easy to work with. If you are in an enterprise setting, consider getting started with the Cerbos Hub, which is packed with enterprise-friendly features. If you are in the early stages of evaluation and want to test out policies, get started with Cerbos Playground, a sandboxed environment to build and test policies quickly.
Below is the sample RBAC policy defined based on the above matrix:
Flight Ops Manager Role
---
apiVersion: api.cerbos.dev/v1
rolePolicy:
role: "flight_ops_manager"
scope: "aviation.hr"
rules:
- resource: personnel_record
allowActions:
- view
Admin Staff Role
---
apiVersion: api.cerbos.dev/v1
rolePolicy:
role: "admin_staff"
scope: "aviation.hr"
rules:
- resource: personnel_record
allowActions:
- view
- update
Similarly, the derived roles and policies follow...
Test
Once your policies are defined, it is important to ensure they are fit for purpose and free of gaps. Try out the tools in Cerbos Playground and Cerbos Hub to test policies interactively and to write comprehensive automated tests.
Conclusion
Authorization is the invisible framework that works in the background to keep all of the aviation systems running smoothly. It is crucial to apply extra due diligence before selecting the authorization system. In this blog, we demonstrated how Cerbos can be applied in an aviation context, deployed centrally, sidecar, or via a daemon set approach.