ABAC API Service (Service Mesh)
Problem to Solve
Authorization problems are the number one security weakness that impacts APIs today. 4/10 weaknesses in the OWASP API Top 10 are authorization flaws:
| # | Risk | Description |
|---|---|---|
| 1 | API1:2023 - Broken Object Level Authorization | APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user. |
| 3 | API3:2023 - Broken Object Property Level Authorization | This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties. |
| 5 | API5:2023 - Broken Function Level Authorization | Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions. |
| 6 | API6:2023 - Unrestricted Access to Sensitive Business Flows | APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs. |
Authorization weaknesses are incredibly prevalent today in part because teams developing APIs may not have the skills or knowledge to include sufficient limitations, and in part because it is very difficult to test for authorization failures. Traditionally adding authorization logic to code makes it difficult for anyone other than a developer to understand the logic and makes it more difficult to maintain the code. Traditional strategies haven't worked sufficiently, which is why so many API breaches can be traced back to authorization failures.
Service Meshes add a control plane, which can be used to provide better authentication and authorization controls. According to NIST,
This makes it possible for a central team to mandate and manage application-level security across the entire organization, delegating to
individual application teams only to specify what permissions are required for each application’s actions... This makes it cheaper to operate an organization’s authentication and authorization systems securely and reliably... The service mesh is most widely used today with containerized applications but can be extended into other environments, such as stateful applications.
Proposal
Incorporate a YAML-based ABAC service mesh into the GitLab platform, which would help:
- Address 3-4 of the OWASP API Top 10 risks for APIs
- Security teams manage authorization policies that can reduce the likelihood of APIs being vulnerable to authorization security flaws
- Centralize and standardize API authorization for an organization
- create human-readable auth policies
- enable both technical and non-technical team members to manage authorization policies
- eliminate the need for auth rules to be translated between languages in polygot dev shops
- shift security further left as APIs are being developed
Some examples of service meshes that could potentially be incorporated include:
Customers can of course use a service mesh without GitLab's help, but by incorporating this capability within GitLab, we can provide better usability in areas such as:
- Link to security policies--require service mesh policies for all projects?
- Security dashboard visibility
- Audit log visibility
- Enabling security teams to more easily configure service mesh auth policies
Scope
Must Have
- Auth policies written in YAML in GitLab UI.
- After policy is deployed, API call is made to auth service (possibly OS version of Cerbos?) , policy decision gets made (allow/deny).